Uma newsletter enviada às 7 da manhã no horário da sede chega à caixa de entrada de alguns assinantes em um horário razoável do início da manhã e à de outros bem depois da meia-noite, soterrada quando eles acordam e verificam o email. Uma editora que enviava uma newsletter diária para uma base internacional de assinantes tinha exatamente esse problema sem perceber o quanto isso estava custando em taxas de abertura, já que a diferença aparecia nos dados como um padrão regional vago, e não como uma causa única, óbvia e explicável.
A editora já tinha dados de localização aproximada da maioria dos assinantes, coletados no cadastro a partir de um campo de localização ou inferidos do endereço IP do cadastro por meio de /v1/ip, resolvidos em país e cidade. O que faltava era uma forma de transformar essa localização em uma decisão real de horário de envio, já que saber que um assinante estava em determinado país não é o mesmo que saber o fuso horário correto para agendar, principalmente em países maiores que abrangem vários fusos.
Para a localização resolvida de cada assinante, o sistema de envio da editora consultava o nome de fuso horário IANA por meio de /v1/timezone e o armazenava no registro do assinante, em vez de consultá-lo de novo a cada envio. Com um fuso horário real associado a cada assinante, a plataforma de envio podia escalonar a entrega para que a newsletter chegasse mais ou menos no mesmo horário local para todos, independentemente de quantos fusos horários a base total de assinantes abrangia, em vez de disparar todas as cópias de uma vez a partir de um único horário agendado.
As taxas de abertura melhoraram de forma mensurável nas regiões que antes recebiam a newsletter em um horário local inconveniente, a evidência mais clara de que a abordagem original de horário de envio único vinha custando engajamento silenciosamente justamente nos mercados mais distantes do horário da sede, aqueles que provavelmente seriam os menos notados como problema sem uma medição direta.
A editora usou o nome IANA armazenado em vez de um deslocamento fixo justamente para que o cálculo do horário de envio continuasse correto durante as mudanças de horário de verão sem precisar de atualizações manuais, um detalhe fácil de ignorar que teria feito os horários de envio cuidadosamente ajustados saírem do alinhamento duas vezes por ano em todas as regiões afetadas se um deslocamento bruto tivesse sido armazenado no lugar.
Tratava-se de uma consulta única por assinante, e não de um custo por envio, já que o fuso horário de um assinante raramente muda e não havia motivo para resolvê-lo de novo a cada edição da newsletter. Isso manteve o volume total de requisições baixo em relação à base de assinantes da editora, bem dentro da cota gratuita diária, mesmo considerando um fluxo constante de novos cadastros que precisavam da sua própria primeira consulta.
O horário de envio é uma das alavancas mais negligenciadas do email marketing justamente porque um único número médio de taxa de abertura esconde o quanto o desempenho varia por região. A correção, quando a causa subjacente fica visível, é uma mudança técnica simples, e não um problema de conteúdo ou de linha de assunto que a equipe poderia ter passado tempo perseguindo.
A documentação dos dois endpoints está em /docs/ipv4-lookup/ e /docs/timezone-lookup/.
Um código postal e uma cidade que não batem em um formulário de pedido parecem um pequeno erro de digitação até virarem uma entrega enviada para uma região totalmente diferente do país.
Uma empresa de logística queria um alerta simples no momento em que um caminhão de entregas entrasse ou saísse do local de um cliente específico, sem construir ou licenciar uma plataforma completa de rastreamento de frota.
Uma ferramenta de colaboração queria que os colegas de equipe vissem, de relance, onde um colega estava e mais ou menos que horas eram para ele, sem que ninguém precisasse digitar isso no perfil.