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.
Das Land eines Besuchers für Steuer- und Währungsvorgaben erkennen
Einen neuen Besucher sein Land aus einer langen Dropdown-Liste wählen zu lassen, bevor Sie ihm einen Preis zeigen, ist ein zusätzlicher Schritt, den ein guter Standardwert vollständig überflüssig machen kann.
Den Ländercode ermitteln
Ein einziger Aufruf von /v1/ip mit der Adresse des Besuchers liefert ein Feld country_code im Standardformat ISO 3166-1 Alpha-2, also in dem Format, nach dem die meisten Steuer- und Währungstabellen bereits geschlüsselt sind.
GET /v1/ip?ip=198.51.100.7{
"status": "ok",
"ip": "198.51.100.7",
"version": 4,
"found": true,
"country": "Germany",
"country_code": "DE",
"region": "Berlin",
"city": "Berlin",
"postcode": "10115",
"lat": 52.5200,
"lon": 13.4050,
"timezone": "Europe/Berlin",
"asn": 6789,
"org": "Example Telecom"
}Vom Ländercode zu Steuer und Währung
Ordnen Sie country_code Ihrer eigenen Steuersatztabelle und Währungstabelle zu, genauso wie Sie ein manuell vom Kunden ausgewähltes Land zuordnen würden. Behandeln Sie das aus der IP-Adresse abgeleitete Land als Standardwert und nicht als endgültige Antwort, und lassen Sie den Besucher es ändern, denn ein reisender Kunde oder einer hinter einem VPN entspricht nicht immer dem Rechnungsland, das er tatsächlich braucht.
Wenn die Abfrage kein Ergebnis liefert
Eine Anfrage für eine Adresse ohne hinterlegte Standortdaten liefert found mit dem Wert false statt eines Fehlers, und dafür sollten Sie ausdrücklich vorsorgen. Greifen Sie in diesem Fall auf ein einziges sinnvolles Standardland und eine Standardwährung zurück, statt das Feld leer zu lassen oder zuzulassen, dass ein leerer country_code unbemerkt Ihre Steuerberechnung erreicht.
Wo sich My Geocode selbst unterscheidet
Die Preise von My Geocode selbst laufen weltweit ausschließlich in EUR, unabhängig davon, von wo aus ein Kunde abgerechnet wird. Das ist eine andere Frage als die, was Sie Ihren eigenen Besuchern zeigen. Dort ist es völlig sinnvoll, die angezeigte Währung nach dem erkannten Land zu lokalisieren, selbst wenn Ihr eigenes Backend alles in einer Währung abrechnet, so wie unseres.
Ein Fehler, den Sie vermeiden sollten
Einen Besucher ohne Änderungsmöglichkeit auf das erkannte Land festzulegen ist ein größeres Problem, als gelegentlich einen falschen Standardwert zu setzen. Ein Kunde, der aus einem Hotel im Ausland einkauft oder hinter einem Firmen-VPN sitzt, das in einem anderen Land als seinem tatsächlichen Aufenthaltsort austritt, wird früher oder später auf einen falschen Standardwert stoßen. Zeigen Sie das erkannte Land immer als bearbeitbares Feld an und nicht als festen Wert, der in die Bestellung eingebaut ist.
Kosten der Anfragen
Eine Abfrage pro neuer Besuchersitzung, gecacht für die Dauer dieser Sitzung, ist das sinnvolle Muster. Das ist eine Anfrage pro Sitzung statt pro Seitenaufruf, die auf Ihr Tageskontingent angerechnet wird, womit selbst eine stark besuchte Website deutlich innerhalb der 2.500 kostenlosen Anfragen pro Tag bleibt, die zu jedem Schlüssel gehören oder ganz ohne Schlüssel von einer einzelnen Adresse aus verfügbar sind.
Eine verwandte Anwendung
Dieselbe Antwort enthält auch ein Feld timezone. Ein Checkout-Ablauf, der sowohl eine Standardwährung als auch eine sinnvolle Anzeige der Ortszeit für Bestellbestätigungen möchte, erhält also beides aus einem Aufruf statt aus zwei separaten Abfragen.
Wenn die Standardwährung schon beim ersten Seitenaufruf stimmt, vermeiden Sie einen irritierenden Preiswechsel später im Checkout. Die Dokumentation zur IPv4-Abfrage listet jedes Feld auf, das der Endpunkt zurückgibt.