Publicar às nove da manhã funciona bem para exatamente um fuso horário e mal para todos os outros. Uma marca de mídia com seguidores espalhados por cinco continentes agendava tudo com base no horário da própria sede, o que fazia uma parcela significativa do público ver cada publicação logo cedo, no meio do expediente ou bem depois da meia-noite, em grande parte ao acaso, dependendo de onde cada pessoa morava.
A equipe já tinha dados aproximados de localização do público, extraídos da origem do engajamento, em nível de cidade e país, coletados dos logs do servidor e não de um script de rastreamento. O que faltava era converter esses dados de localização em um horário local real que servisse de base para o agendamento, já que um país como o Brasil ou os Estados Unidos pode abranger mais de um fuso horário, e decisões de publicação tomadas em nível de país muitas vezes ainda estavam erradas para cidades específicas dentro dele.
Para cada grande grupo de público, a equipe definiu uma coordenada representativa e a enviou para /v1/timezone, que retorna o nome do fuso horário IANA e o deslocamento UTC atual daquele ponto. Como o endpoint aceita um momento específico para calcular o deslocamento, e não apenas o horário atual, a equipe pôde planejar uma semana inteira de publicações e obter o deslocamento correto para cada dia, mesmo durante uma mudança de horário de verão, em vez de presumir um deslocamento fixo que sairia de sincronia no meio da programação.
Com o horário local exato de cada segmento de público em mãos, o calendário de publicações deixou de ser uma única programação e passou a ser várias, escalonadas para que cada conteúdo chegasse a cada região durante os horários de maior engajamento daquela região, em vez de tudo sair de uma programação mestre única baseada no horário da sede. A marca não precisou publicar mais conteúdo para ver o benefício. O mesmo volume de publicações, no horário certo, alcançou uma parte maior do público enquanto as pessoas realmente estavam olhando seus feeds.
A equipe também usou a mesma consulta para algo menor, mas persistente: indicar corretamente os horários de eventos e os anúncios de transmissões ao vivo. Um lançamento anunciado para "8 PM" sem fuso horário indicado gerava havia anos um fluxo constante de respostas confusas. Anexar o fuso horário local resolvido a cada anúncio agendado, e deixar a plataforma exibi-lo corretamente de acordo com as configurações de cada espectador, eliminou uma fonte pequena, mas constante, de confusão evitável.
Nada disso exigiu rastrear seguidores individuais ou seus dispositivos. Os dados de localização vieram de padrões agregados de engajamento, do lado do servidor, que a marca já tinha, e a consulta de fuso horário em si rodava poucas vezes por semana, uma vez por grupo de público, um volume tão pequeno que mal aparecia diante da cota diária gratuita incluída na chave da conta.
Acertar os horários de publicação é uma mudança pequena com efeito cumulativo, já que toda publicação se beneficia dela, sem precisar de uma correção pontual. A documentação do endpoint, incluindo como informar um momento específico, está em /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.