Wer ein Checkout-Formular über einen gespeicherten Browsereintrag automatisch ausfüllt oder eine Adresse aus einer alten E-Mail kopiert, landet manchmal bei einer Postleitzahl von einem Ort in Kombination mit dem Stadtnamen eines anderen. Das ist ein leicht passierender Fehler, der ebenso leicht übersehen wird, wenn man ein ausgefülltes Formular vor dem Absenden nur kurz überfliegt. Ein Onlineshop, der physische Waren versendet, fand genau diese Abweichung als Ursache hinter einem stetigen, geringen Strom fehlgeleiteter oder verspäteter Lieferungen, jede für sich klein, zusammen aber ein echter Kostenfaktor durch erneuten Versand und verärgerte Kunden.
Die Lösung war ein Abgleich, der beim Checkout automatisch lief, bevor eine Bestellung bestätigt wurde. Die im Formular eingegebene Postleitzahl ging an /v1/postcode, das auflöst, welchem Ort diese Postleitzahl tatsächlich entspricht. Der Shop verglich den aufgelösten Ort mit der Stadt und Region, die der Kunde im selben Formular ebenfalls eingegeben hatte. Wo beide eindeutig nicht übereinstimmten, ließ der Checkout die Bestellung nicht einfach durch, um die Abweichung erst zu bemerken, wenn eine Lieferung an den falschen Ort ging, sondern hielt mit einem einfachen Hinweis an, der den Kunden bat, Postleitzahl und Stadt vor dem Fortfahren zu überprüfen.
Der Shop schickte außerdem die vollständige eingegebene Adresse als zweite Ebene durch /v1/forward, denn eine Adresse kann den Abgleich von Postleitzahl und Stadt bestehen und trotzdem an anderer Stelle ein echtes Problem haben, etwa eine Straße, die unter diesem Namen nicht existiert, oder eine Hausnummer außerhalb des plausiblen Bereichs für diese Straße. Die vom Geokodierungsaufruf zurückgegebene Treffersicherheit gab dem Checkout ein zweites Signal, das neben dem Postleitzahlenvergleich berücksichtigt wurde, und eindeutig schlechte Treffer wurden für denselben kurzen Bestätigungshinweis markiert.
Der Shop entschied bewusst, wie viel zusätzliche Reibung das erzeugen durfte. Die meisten Bestellungen bestanden beide Prüfungen sofort und liefen ohne jede sichtbare Änderung durch den Checkout, denn die überwiegende Mehrheit der Kunden gibt ihre eigene Adresse beim ersten Mal richtig ein. Nur die kleinere Zahl von Bestellungen mit einer echten Abweichung sah den Bestätigungshinweis, und selbst dann brauchte ein Kunde nur wenige Sekunden, um die Angaben zu prüfen und zu korrigieren oder zu bestätigen, dass die Adresse wie eingegeben tatsächlich stimmte, denn gelegentlich konnte auch eine ungewöhnliche, aber legitime Adresse die Prüfung auslösen, ohne tatsächlich falsch zu sein.
Eine solche Prüfung macht sich gerade deshalb bezahlt, weil es so viel weniger kostet, eine Abweichung vor dem Versand zu erkennen, als eine Bestellung, die bereits an den falschen Ort verschickt wurde: ein erneuter Versand, dazu eine verspätete oder verlorene ursprüngliche Lieferung und oft ein verärgerter Kunde, der nun seltener wieder bestellt. Den Fehler in den wenigen Sekunden vor der Bestellung zu beheben statt in den Tagen, die es dauert, ein Versandproblem im Nachhinein zu entdecken und zu korrigieren, senkte diese Kosten von erheblich auf nahezu null.
Jede Bestellung löste eine Postleitzahlprüfung und eine Adressprüfung aus, eine Last, die direkt mit dem Verkaufsvolumen wuchs und für einen Shop mittlerer Größe den größten Teil des Jahres innerhalb des kostenlosen Tageskontingents blieb, während Prepaid-Guthaben geschäftigere Zeiten abdeckte, ohne dass dafür vorab besondere Planung nötig war.
Die Dokumentation für beide Endpunkte finden Sie unter /docs/postal-code-lookup/ und /docs/forward-geocoding/, und die allgemeine Fehlerbehandlung beider Endpunkte ist unter /docs/errors/ beschrieben.