Una newsletter enviada a las 7 AM, hora de la sede, llega a la bandeja de entrada de algunos suscriptores a una hora razonable de primera mañana y a la de otros bastante después de medianoche, enterrada para cuando se despiertan y revisan el correo. Un editor que enviaba una newsletter diaria a una base internacional de suscriptores tenía exactamente este problema sin darse cuenta de cuánto le estaba costando en tasa de apertura, ya que la diferencia aparecía en los datos como un vago patrón regional y no como una causa única, evidente y explicable.
El editor ya tenía datos de ubicación aproximados de la mayoría de los suscriptores, recogidos en el registro a partir de un campo de ubicación o deducidos de la dirección IP de registro mediante /v1/ip, resueltos en país y ciudad. Lo que le faltaba era una forma de convertir esa ubicación en una decisión real sobre la hora de envío, porque saber que un suscriptor está en un país concreto no es lo mismo que conocer la zona horaria correcta con la que programar, sobre todo en países grandes que abarcan varias zonas.
Para la ubicación resuelta de cada suscriptor, el sistema de envío del editor consultaba el nombre de zona horaria IANA mediante /v1/timezone y lo guardaba en el registro del suscriptor en lugar de consultarlo de nuevo en cada envío. Con una zona horaria real asociada a cada suscriptor, la plataforma de envío podía escalonar la entrega para que la newsletter llegara aproximadamente a la misma hora local para todos, sin importar cuántas zonas horarias abarcara la base total de suscriptores, en lugar de disparar todas las copias a la vez desde una única hora programada.
La tasa de apertura mejoró de forma medible en las regiones que antes recibían la newsletter a una hora local poco conveniente, la prueba más clara de que el enfoque original de una sola hora de envío había estado restando interacción en silencio precisamente en los mercados más alejados de la hora de la sede, los que probablemente menos se habrían detectado como un problema sin medirlo directamente.
El editor usó el nombre IANA guardado en lugar de un desfase fijo precisamente para que el cálculo de la hora de envío siguiera siendo correcto con los cambios de horario de verano sin necesidad de actualizaciones manuales, un detalle fácil de pasar por alto que habría hecho que las horas de envío, cuidadosamente ajustadas, se desalinearan dos veces al año en cada región afectada si se hubiera guardado un desfase en bruto.
Se trataba de una única consulta por suscriptor y no de un coste por envío, ya que la zona horaria de un suscriptor rara vez cambia y no había motivo para resolverla de nuevo en cada número de la newsletter. Eso mantuvo bajo el volumen total de solicitudes en relación con la base de suscriptores del editor, muy dentro de la cuota diaria gratuita incluso contando el goteo constante de nuevos registros que necesitaban su propia primera consulta.
La hora de envío es una de las palancas más olvidadas del email marketing precisamente porque una única cifra media de tasa de apertura oculta lo distinto que rinde según la región, y la solución, una vez que la causa de fondo se hace visible, es un cambio técnico sencillo y no un problema de contenido o de línea de asunto que el equipo podría haber pasado tiempo persiguiendo.
La documentación de ambos endpoints está en /docs/ipv4-lookup/ y /docs/timezone-lookup/.