Eine Zapier- oder Make-Automatisierung auf einen neuen Geokodierungs-Host migrieren
No-Code-Automatisierungen mit einem Geokodierungsschritt brauchen einen anderen Migrationsansatz als eigener Code. So gehen Sie bei diesem Wechsel vor.
Unterschiede im Antwortschema während einer Migration behandeln
Selbst der sorgfältigste Ersatzanbieter unterscheidet sich in mindestens ein paar kleinen Punkten vom ursprünglichen, und diese Unterschiede zu finden, bevor sie in der Produktion auftauchen, ist eine grundlegend andere Aufgabe, als sie zu entdecken, nachdem ein Kunde einen Fehler gemeldet hat. Ein strukturierter Ansatz für den Schemavergleich findet die meisten dieser Unterschiede früh, günstig und ohne Aufregung.
Ein sinnvoller Ausgangspunkt ist die Unterscheidung zwischen drei Kategorien von Unterschieden, da jede eine andere Reaktion erfordert:
Unterschiede beim Vorhandensein von Feldern. Ein Feld, das Ihr Code ausliest, kann in der Antwort des einen Anbieters vorhanden sein und in der eines anderen fehlen oder nur unter bestimmten Bedingungen vorkommen. Diese Kategorie lässt sich am leichtesten durch einen statischen Vergleich erkennen: Nehmen Sie von jedem Anbieter eine Beispielantwort für dieselbe Eingabe und vergleichen Sie die Feldlisten direkt.
Unterschiede bei Feldtyp oder Format. Derselbe inhaltliche Wert kann unterschiedlich dargestellt sein: eine Koordinate als zwei separate numerische Felder statt als eine kombinierte Zeichenkette, ein Konfidenzwert als Zahl zwischen 0 und 1 statt als Kategorie („high“, „medium“, „low“) oder ein Zeitstempel in einem völlig anderen Format. Um diese zu erkennen, müssen Sie die tatsächlichen Werte lesen, nicht nur die Feldnamen.
Semantische Unterschiede bei identischen Feldnamen. Das ist die schwierigste Kategorie: Zwei Anbieter verwenden genau denselben Feldnamen, meinen damit aber subtil Unterschiedliches, etwa ein Feld „accuracy“, das der eine Anbieter anhand der Übereinstimmung von Adressbestandteilen bewertet und der andere nach einer völlig anderen internen Methodik. Ein Vergleich allein anhand der Feldnamen erkennt das nicht. Dafür müssen Sie verstehen, was ein Wert in jedem System tatsächlich darstellt, meist indem Sie die Dokumentation beider Anbieter sorgfältig lesen, statt anzunehmen, dass ein gemeinsamer Name eine gemeinsame Bedeutung hat.
Ein praktischer Ablauf: Nehmen Sie eine repräsentative Stichprobe echter historischer Anfragen, die idealerweise mindestens Ihre häufigsten Anfragemuster und Ihre bekannten kniffligen Sonderfälle abdeckt, führen Sie sie gegen den alten und den neuen Anbieter aus und vergleichen Sie die Ergebnisse systematisch, statt nur einige Beispiele mit bloßem Auge zu prüfen. Diesen Vergleich zu automatisieren, selbst als einfaches Skript, das jeden strukturellen oder erheblichen Wertunterschied markiert, lohnt den Einrichtungsaufwand bei allem, was über eine sehr kleine Integration hinausgeht.
Die Kompatibilitäts-Hosts von My Geocode sind gezielt darauf ausgelegt, die ersten beiden Kategorien von Unterschieden für den jeweils nachgebildeten Anbieter zu minimieren. Sie entsprechen beim Vorhandensein und Format der Felder exakt dem Original, abgesehen von den Texten zu Urheberrecht, Nutzungsbedingungen und Datenschutz, was pro Host unter /docs/compatibility/ dokumentiert ist. Damit bleibt die dritte Kategorie, semantische Unterschiede unter einem gemeinsamen Feldnamen, das Wichtigste, was Sie auch bei Verwendung eines Kompatibilitäts-Hosts direkt testen sollten, denn eine Übereinstimmung im Format garantiert nie vollständig eine Übereinstimmung in der zugrunde liegenden Methodik.
Echte Zeit für diese Vergleichsarbeit einzuplanen, bevor eine Migration als abgeschlossen gilt, statt einen erfolgreichen Test mit einer Handvoll gängiger Adressen als ausreichend zu betrachten, ist einer der zuverlässigeren Wege, die Art subtiler Datenqualitätsprobleme zu vermeiden, die Wochen braucht, um bemerkt zu werden, und noch länger, um auf ihre eigentliche Ursache zurückgeführt zu werden.