Anwendungsfälle

Ein Abonnement je nach Region unterschiedlich bepreisen

Überall denselben Preis zu verlangen, ignoriert, wie unterschiedlich Kaufkraft und Wettbewerb von Markt zu Markt sind. Ein Softwareunternehmen, das ein Abonnementprodukt verkauft, wollte es in einigen Märkten günstiger anbieten und in anderen beim Preis bleiben, eine durchaus verbreitete Strategie. Dafür musste es aber wissen, in welchem Markt sich ein Besucher tatsächlich befand, bevor der Preis überhaupt auf der Seite gerendert wurde.

Direkt zu fragen war die erste Idee und die falsche. Eine Länderauswahl auf einer Preisseite wirkt wie eine Einladung, durch falsche Standortangaben nach der günstigsten Option zu suchen, und sie fügt einer Seite eine Entscheidung hinzu, deren einzige Aufgabe es ist, einen Besucher mit möglichst wenig Reibung zum Checkout-Button zu bringen. Das Unternehmen wollte, dass einfach der richtige Preis erscheint.

Die Lösung lief serverseitig, bevor die Preisseite ausgeliefert wurde. /v1/ip nahm die IP-Adresse des Besuchers entgegen und gab unter anderem ein Länderfeld zurück, anhand dessen die Preisseite auswählte, welche Preistabelle gerendert wurde. Ein Besucher aus einem Markt mit Standardpreis sah den Standardpreis. Ein Besucher aus einem Markt, für den das Unternehmen einen regionalen Preis festgelegt hatte, sah stattdessen diesen Preis, ohne Auswahlfeld, ohne zusätzlichen Klick und ohne sichtbares Anzeichen, dass überhaupt etwas erkannt worden war.

Das Unternehmen behandelte das erkannte Land als Ausgangspunkt statt als feststehende Tatsache, da ein Besucher in einem Firmen-VPN oder auf Auslandsreise einem Markt zugeordnet werden konnte, der nicht zu seiner tatsächlichen Preisberechtigung passte. Statt jemanden hart zu blockieren, erlaubte der Checkout-Ablauf eine Korrektur durch den Support für den seltenen Fall, dass das tatsächliche Rechnungsland eines Kunden nicht zu dem passte, was die IP nahelegte. Das wurde als Ausnahme behandelt und nicht in den Hauptablauf eingebaut, denn ständigen Zweifel für einen Sonderfall, der nur einen kleinen Bruchteil der Besucher betraf, in die Preisseite einzubauen, hätte die Einfachheit zunichtegemacht, die die ganze Änderung bringen sollte.

Ein Detail war wichtig genug, um es dem Finanzteam ausdrücklich mitzuteilen: My Geocode selbst rechnet überall, wo es tätig ist, in EUR ab, ohne eigene regionale Preise über das kostenlose Standardkontingent, das Prepaid-Guthaben und den Unlimited-Schlüssel hinaus. Das ist eine andere Frage als die, ob ein Unternehmen, das die API nutzt, für sein eigenes Produkt regionale Preise einführen möchte, und diese Entscheidung liegt ganz bei dem Unternehmen, das darauf aufbaut. Die Abfrage liefert nur das Ländersignal. Was ein Unternehmen mit diesem Signal macht und wie es seine Preise danach ausrichtet, bleibt seine eigene Entscheidung.

Das Anfragevolumen folgte den Aufrufen der Preisseite, typischerweise ein kleiner Bruchteil des gesamten Website-Traffics, da die meisten Besucher auf der Website eines Softwareunternehmens bei einem bestimmten Besuch nicht aktiv die Preise prüfen. Dadurch blieb die Nutzung den größten Teil des Jahres deutlich innerhalb des kostenlosen Tageskontingents und ging nur in Zeiten ungewöhnlich hohen Traffics auf der Preisseite, etwa rund um eine Produkteinführung, ins Prepaid-Guthaben über.

Gut umgesetzte regionale Preise sollten als Mechanismus unsichtbar und als Ergebnis offensichtlich sein: der richtige Preis, beim ersten Rendern, ohne zusätzlichen Schritt. Die Dokumentation für den Endpunkt finden Sie unter /docs/ipv4-lookup/ und /docs/ipv6-lookup/, die Preisdetails für die API selbst unter /pricing/.