Die Nutzung Ihres Schlüssels überwachen, bevor Sie an ein Limit stoßen
Wenn Sie Ihre Kontingent-Header laufend beobachten, wissen Sie, wann ein Limit näher rückt, lange bevor eine Anfrage tatsächlich abgelehnt wird.
Ein Widget mit lokaler Uhrzeit in ein Support-Dashboard einbauen
Ein Support-Mitarbeiter, der entscheidet, ob er einen Kunden jetzt anrufen soll, profitiert davon zu wissen, wie spät es dort tatsächlich ist, wo der Kunde sitzt, und nicht, wie spät es im Büro ist.
Die Zeitzone des Kunden ermitteln
Wenn Sie bereits eine Liefer- oder Rechnungsadresse gespeichert haben, geokodieren Sie sie einmal, um Koordinaten zu erhalten, und übergeben Sie diese Koordinaten dann an /v1/timezone. Wenn Sie nur die IP-Adresse von seinem letzten Besuch haben, liefert der Endpunkt /v1/ip direkt ein Feld timezone, ohne separate Abfrage.
GET /v1/timezone?lat=35.6762&lon=139.6503{
"status": "ok",
"timezone": "Asia/Tokyo",
"utc_offset": "+09:00",
"abbreviation": "JST"
}Wenn weder eine Adresse noch eine IP gespeichert ist
Für einen Lead oder ein Ticket ohne Adresse und ohne erfasste IP gibt es keine verlässliche Koordinate, anhand derer sich eine Zeitzone abfragen ließe, und eine Schätzung anhand einer Ländervorwahl oder einer Spracheinstellung kann dieser Endpunkt nicht für Sie übernehmen. Fragen Sie in diesem Fall direkt nach einer Zeitzone oder einem ungefähren Standort, statt eine Uhr anzuzeigen, die auf einer Vermutung beruht, die mit echter Wahrscheinlichkeit um mehrere Stunden danebenliegt.
Die Uhr darstellen
Speichern Sie die Zeitzonenkennung im Kundendatensatz und berechnen Sie daraus die aktuelle Ortszeit bei jeder Darstellung des Dashboards, statt einen festen Versatz zu speichern, der rund um die Umstellung auf Sommer- oder Winterzeit veraltet. Da die Website kein clientseitiges JavaScript verwendet, stellen Sie die aktuelle Ortszeit beim Laden der Seite serverseitig dar und aktualisieren Sie sie bei jedem Seitenaufruf, statt sie live im Browser weiterlaufen zu lassen.
Eine Abfrage pro Kunde, nicht pro Seitenaufruf
Die Zeitzonenkennung für den Standort eines Kunden ändert sich nicht von Tag zu Tag. Fragen Sie sie daher einmal ab, wenn die Adresse oder IP zum ersten Mal erfasst wird, und speichern Sie die Kennung, statt die API bei jedem Laden des Dashboards aufzurufen. So bleibt diese Funktion bei insgesamt einer Handvoll Anfragen statt einer pro Seitenaufruf, was wichtig ist, wenn ein Support-Team das Dashboard viele Male am Tag öffnet.
Ein Fehler, den Sie vermeiden sollten
Wird der Versatz für einen vergangenen Support-Kontakt anhand der heutigen Zeitzonenabfrage statt anhand des Zeitstempels des Kontakts selbst neu berechnet, kann rund um eine Zeitumstellung die falsche Stunde angezeigt werden. Wenn ein Dashboard anzeigen soll, welche Ortszeit beim Kunden in dem Moment herrschte, als ein früheres Ticket erstellt wurde, übergeben Sie den Zeitstempel dieses Tickets über den Parameter time, statt sich auf den aktuellen Versatz zu verlassen.
Was es kostet
Selbst ohne Zwischenspeicherung der Kennung ist jede Abfrage eine einzelne Anfrage, sodass ein Support-Team jeder vernünftigen Größe bequem in die 2.500 kostenlosen Anfragen pro Tag passt, die in jedem Schlüssel enthalten sind, oder in dasselbe Kontingent, das ohne Schlüssel von einer einzelnen Adresse aus verfügbar ist.
Aktuell halten
Wenn sich die gespeicherte Adresse eines Kunden ändert, aktualisieren Sie gleichzeitig die gespeicherte Zeitzonenkennung, statt eine veraltete Kennung auf unbestimmte Zeit am Datensatz zu belassen. Ein umgezogener Kunde mit einer alten Zeitzonenkennung zeigt so lange die falsche Ortszeit an, bis der Datensatz aktualisiert wird, und zwar unbemerkt, da an der alten Abfrage nichts von selbst fehlschlägt oder einen Fehler meldet.
Eine Uhr mit Ortszeit neben einem Ticket ist eine kleine Ergänzung, die einem Support-Mitarbeiter erspart, vor jedem Anruf Zeitzonen im Kopf umzurechnen. Die Dokumentation zur Zeitzonenabfrage beschreibt die Anfrage vollständig.