Ein Newsletter, der um 7 Uhr Zeit der Zentrale verschickt wird, landet bei manchen Abonnenten zu einer vernünftigen frühen Morgenstunde im Posteingang und bei anderen weit nach Mitternacht, wo er untergegangen ist, bis sie aufwachen und ihre E-Mails lesen. Ein Verlag mit einem täglichen Newsletter für eine internationale Abonnentenbasis hatte genau dieses Problem, ohne zu ahnen, wie viel es ihn an Öffnungsraten kostete, denn der Unterschied zeigte sich in den Daten als vages regionales Muster und nicht als offensichtliche, eindeutig erklärbare Ursache.
Der Verlag hatte für die meisten Abonnenten bereits ungefähre Standortdaten, die bei der Anmeldung erfasst worden waren, entweder über ein Standortfeld oder abgeleitet aus der IP-Adresse der Anmeldung über /v1/ip, aufgelöst in Land und Stadt. Was fehlte, war ein Weg, diesen Standort in eine konkrete Entscheidung über die Versandzeit umzusetzen, denn zu wissen, dass ein Abonnent in einem bestimmten Land ist, ist nicht dasselbe, wie die richtige Zeitzone für die Planung zu kennen, besonders bei größeren Ländern, die mehrere Zeitzonen umfassen.
Für den aufgelösten Standort jedes Abonnenten fragte das Versandsystem des Verlags den IANA-Zeitzonennamen über /v1/timezone ab und speicherte ihn im Datensatz des Abonnenten, statt ihn bei jedem Versand neu abzufragen. Mit einer echten Zeitzone an jedem Abonnenten konnte die Versandplattform die Zustellung staffeln, sodass der Newsletter bei allen ungefähr zur gleichen lokalen Uhrzeit ankam, unabhängig davon, wie viele Zeitzonen die gesamte Abonnentenbasis umfasste, statt alle Exemplare gleichzeitig zu einem einzigen geplanten Zeitpunkt abzuschicken.
Die Öffnungsraten verbesserten sich messbar in den Regionen, die den Newsletter zuvor zu einer ungünstigen lokalen Uhrzeit erhalten hatten. Das war der deutlichste Beleg dafür, dass der ursprüngliche Ansatz mit einer einzigen Versandzeit still und leise Engagement gekostet hatte, und zwar genau in den Märkten, die am weitesten von der Zeit der Zentrale entfernt lagen, also in denen, deren Problem ohne gezielte Messung wohl am wenigsten aufgefallen wäre.
Der Verlag verwendete bewusst den gespeicherten IANA-Namen statt eines festen Offsets, damit die Berechnung der Versandzeit auch bei Zeitumstellungen korrekt blieb, ohne manuelle Aktualisierungen. Dieses Detail übersieht man leicht, und hätte man stattdessen einen reinen Offset gespeichert, wären die sorgfältig abgestimmten Versandzeiten in jeder betroffenen Region zweimal im Jahr aus dem Takt geraten.
Es handelte sich um eine einmalige Abfrage pro Abonnent und nicht um Kosten pro Versand, denn die Zeitzone eines Abonnenten ändert sich selten, und es gab keinen Grund, sie für jede einzelne Newsletter-Ausgabe neu aufzulösen. Dadurch blieb das gesamte Anfragevolumen im Verhältnis zur Abonnentenbasis des Verlags gering und lag deutlich innerhalb des kostenlosen Tageskontingents, selbst unter Berücksichtigung eines stetigen Zustroms neuer Anmeldungen, die jeweils ihre eigene erste Abfrage brauchten.
Die Versandzeit ist einer der am meisten unterschätzten Hebel im E-Mail-Marketing, gerade weil eine einzige durchschnittliche Öffnungsrate verbirgt, wie unterschiedlich sie je nach Region abschneidet. Sobald die eigentliche Ursache sichtbar ist, ist die Lösung eine unkomplizierte technische Änderung und kein Problem mit Inhalt oder Betreffzeile, dem das Team sonst womöglich Zeit hinterhergejagt hätte.
Die Dokumentation für beide Endpunkte finden Sie unter /docs/ipv4-lookup/ und /docs/timezone-lookup/.