Une newsletter envoyée à 7 h, heure du siège, arrive dans la boîte de réception de certains abonnés à une heure matinale raisonnable et dans celle d'autres bien après minuit, noyée sous d'autres messages au moment où ils se réveillent et consultent leurs e-mails. Un éditeur qui publiait une newsletter quotidienne pour une base d'abonnés internationale avait exactement ce problème sans se rendre compte de ce qu'il lui coûtait en taux d'ouverture, car l'écart apparaissait dans les données comme une vague tendance régionale plutôt que comme une cause unique, évidente et explicable.
L'éditeur disposait déjà de données de localisation approximatives pour la plupart des abonnés, recueillies à l'inscription soit à partir d'un champ de localisation, soit déduites de l'adresse IP d'inscription via /v1/ip, puis résolues en pays et en ville. Ce qui lui manquait, c'était un moyen de transformer cette localisation en une véritable décision d'heure d'envoi, car savoir qu'un abonné se trouve dans un pays donné ne revient pas à connaître le bon fuseau horaire autour duquel planifier, surtout pour les grands pays qui s'étendent sur plusieurs fuseaux.
Pour la localisation résolue de chaque abonné, le système d'envoi de l'éditeur recherchait le nom de fuseau horaire IANA via /v1/timezone et l'enregistrait dans la fiche de l'abonné au lieu de le rechercher à nouveau à chaque envoi. Avec un vrai fuseau horaire associé à chaque abonné, la plateforme d'envoi pouvait échelonner la distribution pour que la newsletter arrive à peu près à la même heure locale pour tout le monde, quel que soit le nombre de fuseaux horaires couverts par l'ensemble des abonnés, au lieu d'expédier tous les exemplaires en même temps à partir d'une seule heure programmée.
Les taux d'ouverture se sont nettement améliorés dans les régions qui recevaient auparavant la newsletter à une heure locale peu pratique. C'est la preuve la plus claire que l'approche initiale avec une heure d'envoi unique coûtait discrètement de l'engagement précisément sur les marchés les plus éloignés de l'heure du siège, ceux dont le problème avait probablement le moins de chances d'être remarqué sans une mesure directe.
L'éditeur utilisait le nom IANA enregistré plutôt qu'un décalage fixe, justement pour que le calcul de l'heure d'envoi reste correct lors des changements d'heure d'été sans mise à jour manuelle. C'est un détail facile à négliger : si un décalage brut avait été enregistré à la place, les heures d'envoi soigneusement réglées se seraient décalées deux fois par an dans chaque région concernée.
Il s'agissait d'une recherche unique par abonné et non d'un coût par envoi, car le fuseau horaire d'un abonné change rarement et il n'y avait aucune raison de le résoudre à nouveau pour chaque numéro de la newsletter. Le volume total de requêtes restait ainsi faible par rapport à la base d'abonnés de l'éditeur, bien en deçà du quota gratuit quotidien, même en tenant compte du flux régulier de nouvelles inscriptions nécessitant leur propre première recherche.
L'heure d'envoi est l'un des leviers les plus négligés de l'e-mail marketing, précisément parce qu'un taux d'ouverture moyen unique masque à quel point ses performances varient d'une région à l'autre. Une fois la cause sous-jacente visible, la correction est un simple changement technique, et non un problème de contenu ou d'objet que l'équipe aurait sinon pu passer du temps à traquer.
La documentation des deux endpoints se trouve sur /docs/ipv4-lookup/ et /docs/timezone-lookup/.