Publier à neuf heures du matin fonctionne bien pour un seul fuseau horaire et mal pour tous les autres. Une marque média dont l'audience est répartie sur cinq continents programmait tout selon l'heure de son siège, si bien qu'une part importante de son public voyait chaque publication soit à la première heure le matin, soit en pleine journée de travail, soit bien après minuit, en grande partie au hasard selon l'endroit où chacun vivait.
L'équipe disposait déjà de données de localisation approximatives sur son audience, tirées de la provenance de l'engagement, au niveau de la ville et du pays, et recueillies dans les journaux du serveur plutôt que par un script de suivi. Il lui fallait convertir ces données de localisation en une heure locale réelle autour de laquelle programmer, car un pays comme le Brésil ou les États-Unis peut s'étendre sur plusieurs fuseaux horaires, et les décisions de publication prises au niveau du pays restaient souvent fausses pour certaines villes de ce pays.
Pour chaque grand groupe d'audience, l'équipe a déterminé une coordonnée représentative et l'a envoyée à /v1/timezone, qui renvoie le nom de fuseau horaire IANA et le décalage UTC actuel pour ce point. Comme l'endpoint accepte un moment précis pour lequel calculer le décalage, et pas seulement l'heure actuelle, l'équipe pouvait planifier une semaine entière de publications et obtenir le bon décalage pour chaque jour, même lors d'un passage à l'heure d'été ou d'hiver, au lieu de supposer un décalage fixe qui se serait désynchronisé en cours de planning.
Avec une heure locale exacte pour chaque segment d'audience, le calendrier de publication a cessé d'être un planning unique pour en devenir plusieurs, décalés de sorte qu'un contenu atteigne chaque région pendant ses propres heures de fort engagement, au lieu que tout parte d'un planning maître unique construit autour de l'heure du siège. La marque n'a pas eu besoin de publier davantage de contenu pour en voir le bénéfice. Le même volume de publications, bien programmé, a touché une plus grande partie de l'audience au moment où les gens regardaient réellement leur fil.
L'équipe a aussi utilisé la même recherche pour un problème plus modeste mais persistant : indiquer correctement l'heure des événements et des annonces de diffusion en direct. Un lancement annoncé à « 8 PM » sans fuseau horaire avait provoqué pendant des années un flot régulier de réponses perplexes. Associer le fuseau horaire local déterminé à chaque annonce programmée, et laisser la plateforme l'afficher correctement selon les réglages de chaque spectateur, a supprimé une source de confusion évitable, petite mais constante.
Rien de tout cela n'a exigé de suivre des abonnés individuels ou leurs appareils. Les données de localisation provenaient de tendances d'engagement agrégées, côté serveur, dont la marque disposait déjà, et la recherche de fuseau horaire elle-même ne s'exécutait que quelques fois par semaine, une fois par groupe d'audience, un volume si faible qu'il comptait à peine face au quota gratuit quotidien inclus avec la clé du compte.
Choisir les bonnes heures de publication est un petit changement à l'effet cumulatif, puisque chaque publication en profite au lieu de nécessiter une correction ponctuelle. La documentation de l'endpoint, y compris la façon de transmettre un moment précis, se trouve sur /docs/timezone-lookup/.