Validierungslogik erstellen

In diesem Dokument wird ein Prozess zum Erstellen eines Systems zur Adressprüfung beschrieben, mit dem eine Vielzahl von Antworten von der Address Validation API verarbeitet werden kann. Es wird erläutert, wie Sie Ihre Logik so erstellen, dass die Antwort korrekt verwendet wird, wie Sie andere Signale von der API untersuchen und wann und wie Sie Ihre Kunden um weitere Informationen bitten.

Im Allgemeinen bestimmt die API-Antwort, wie Ihr System eine Adresse verarbeiten soll:

• Korrigieren: Die Adresse ist von geringer Qualität. Sie sollten um weitere Informationen bitten.
• Bestätigen : Die Adresse ist von hoher Qualität, wurde aber gegenüber der Eingabeadresse geändert. Möglicherweise müssen Sie eine Bestätigung anfordern.
• Akzeptieren : Die Adresse ist von hoher Qualität. Sie können die angegebene Adresse akzeptieren.

Schlüsselzweck

In diesem Dokument erfahren Sie, wie Sie Ihr System so ändern, dass die API-Antwort optimal analysiert und die nächsten Schritte mit den angegebenen Adressen bestimmt werden können. Der folgende Pseudocode veranschaulicht einen möglichen Ablauf.

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

Die genaue Logik hängt von Ihrer Situation ab. Weitere Informationen finden Sie im Implementierungsleitfaden . Sie können auch unsere Open-Source-Implementierung dieser Logik verwenden, die in der Extended Component Library enthalten ist.

Workflowübersicht

In der folgenden Tabelle sind zwei Aktionen für Ihr System zusammengefasst:

1. Der zu verwendende Workflow basiert auf dem Verhalten „Korrigieren“, „Bestätigen“ und „Akzeptieren“.
2. Die ersten Signale, die in der Antwort geprüft werden müssen. Die hier beschriebenen Signale stammen aus dem Attribut verdict und sind nicht die einzigen Signale, die geprüft werden müssen. Sie geben aber einen ersten Hinweis auf die Qualität der Adresse. Jeder Verhaltenstyp entspricht einem Abschnitt in diesem Dokument, in dem weitere Signale beschrieben werden, die Sie möglicherweise auch untersuchen müssen.

Systemverhalten
Adresse korrigieren	Die Antwort von verdict enthält wichtige fehlende Informationen, die angegeben werden sollten. Die von der API zurückgegebene Adresse ist möglicherweise nicht zustellbar. Workflow Untersuchen Sie bei Bedarf die Adresskomponenten. Fordern Sie den Kunden auf, Adressprobleme zu beheben. Fordern Sie die Validierung der aktualisierten Adresse an. Fahren Sie mit der Adresse fort. Signale für das Ergebnis Eine der folgenden Bedingungen ist erfüllt: validationGranularity ist auf OTHER gesetzt. addressComplete ist false.
Adresse bestätigen	Die Antwort von verdict gibt eine zustellbare Adresse an, aber es wurden Änderungen an der ursprünglichen Eingabe vorgenommen: Es wurden Daten abgeleitet, die entweder rechtschreibkorrigiert oder bestätigungsfähig sind. Workflow Korrekturen erforderlich: Untersuchen Sie bei Bedarf die Adresskomponenten. Fordern Sie die Validierung der aktualisierten Adresse an. Fahren Sie mit der Adresse fort. Keine Korrekturen erforderlich: Fahren Sie mit der Adresse fort. Signale für das Ergebnis Alle der folgenden Bedingungen sind erfüllt: validationGranularity enthält ROUTE addressComplete ist true. hasInferredComponents Feld ist true ODER hasReplacedComponents Feld ist true.
Adresse akzeptieren	Die Antwort der Address Validation API gibt eine Adresse von ausgezeichneter Qualität an. Workflow Fahren Sie mit der zurückgegebenen Adresse fort. Signale für das Ergebnis Alle der folgenden Bedingungen sind erfüllt: validationGranularity enthält PREMISE oder besser. addressComplete ist true. Keine abgeleiteten oder ersetzten Komponenten.

Implementierungsleitfaden

Wenn Sie festlegen, wie Ihr System auf Signale zur Adressvalidierung reagieren soll, können Ihnen die folgenden Empfehlungen helfen, ein effektiveres Antwortmodell zu erstellen. Dies sind jedoch nur Empfehlungen. Ihre Implementierung sollte zu Ihrem Geschäftsmodell passen.

	Anleitung	Details
Risikostufe	Berücksichtigen Sie die Toleranzstufe für Ihre Situation, wenn Sie zwischen der Aufforderung zur Korrektur und der Akzeptanz der eingegebenen Adresse abwägen.	Die Address Validation API gibt eine Vielzahl von Signalen zurück, die Sie mit Ihrer Risikostufe kombinieren können, um den Validierungsprozess zu optimieren. Wenn eine Adresse beispielsweise eine nicht bestätigte Hausnummer hat, können Sie sie trotzdem akzeptieren. Wenn Ihr Unternehmen jedoch eine höhere Adressgenauigkeit erfordert, können Sie den Nutzer auffordern, die Adresse zu korrigieren. Ein Beispiel, das in beide Kategorien fallen könnte, finden Sie unter Nicht bestätigte Hausnummer außerhalb der USA in Adresse akzeptieren – Beispiele.
Adressen akzeptieren	Es empfiehlt sich, Ihrem System zu erlauben, die ursprüngliche Eingabe zu akzeptieren wenn der Kunde nicht auf die Aufforderungen reagiert.	In diesen Fällen hat der Kunde möglicherweise eine Adresse eingegeben, die nicht im System vorhanden ist, z. B. für einen Neubau.

Demo ansehen. Im Rest dieses Dokuments werden verschiedene Beispiele verwendet, um den oben beschriebenen Prozess „Korrigieren“, „Bestätigen“ und „Akzeptieren“ zu veranschaulichen. Sie können die Ergebnisse dieser Beispiele untersuchen, indem Sie sie in die Demo der Address Validation in der Maps JavaScript API eingeben.

Adresse korrigieren

Korrigieren Sie eine Adresse, wenn die Ergebnisse eindeutig darauf hinweisen, dass die Adresse nicht zustellbar ist. Ihr System kann den Kunden dann auffordern, die erforderlichen Informationen anzugeben. Anschließend können Sie Ihren Workflow noch einmal ausführen, um eine zustellbare Adresse zu erhalten.

Signale für die Korrektur

Die Address Validation API bietet eine Reihe von Signalen, mit denen Sie erkennen können, ob eine Adresse korrigiert werden sollte.

1. Validierungsgranularität und fehlende Komponenten

Diese beiden Signale geben den besten Hinweis auf eine problematische Adresse:

• Wenn das validationGranularity Feld den Wert OTHER hat, sollte Ihr System die Signale der Adresskomponenten untersuchen , um mehr darüber zu erfahren, wo der Fehler aufgetreten ist und wie er behoben werden kann.
• Wenn das nach der Verarbeitung zurückgegebene address Objekt ein missingComponentTypes Feld enthält, sollte Ihr System nach dieser Komponente suchen. Fehlende Komponenten machen eine Adresse auch unvollständig und nicht zustellbar.

2. Sonstige Signale

Die Address Validation API bietet auch die folgenden Signale, mit denen Sie bestimmte Probleme diagnostizieren können:

Verdächtige Komponenten	Wenn die Bestätigungsstufe für eine Komponente UNCOMFIRMED_AND_SUSPICIOUS ist, ist die Komponente wahrscheinlich falsch.
Nicht aufgelöste Komponente	Ein unresolvedToken ist ein Teil der Eingabe, der nicht als gültiger Teil einer Adresse erkannt wird.

3. Signale für Adressen in den USA

Bestimmte Felder, die nur für Adressen in den USA gelten, geben einen nützlichen Hinweis darauf, dass die Adresse nicht zustellbar ist und korrigiert werden sollte. Bei einer Adresse, die korrigiert werden muss, sollten Sie Folgendes sehen:

dpvConfirmation	Entweder N, D oder leer.

Weitere Informationen zu dpvConfirmation finden Sie unter Adressen in den USA verarbeiten.

Beispiele für die Korrektur von Adressen

Adresse bestätigen

Sie bestätigen eine Adresse, wenn das Ergebnis darauf hinweist, dass die Address Validation API Adresskomponenten abgeleitet oder geändert hat, um eine validierte Adresse zu erstellen. In diesen Fällen haben Sie eine zustellbare Adresse, möchten aber sicher sein, dass die resultierende Adresse die ist, die der Kunde beabsichtigt hat.

Damit der Kunde die richtige Aufforderung erhält, ermittelt Ihre Logik die vom Dienst gekennzeichneten Komponenten, um zu bestimmen, welche Aktion oder welches Flag die API auf die Komponente angewendet hat, z. B. inferred, replaced oder spellCorrected. Weitere Informationen finden Sie unter AddressComponent in der Referenz.

Hinweis: Berücksichtigen Sie Ihre Risikostufe, wenn Sie entscheiden, ob Sie die Adresse vom Kunden bestätigen lassen oder sie als gültig akzeptieren.

Signale für die Bestätigung

Die Address Validation API bietet eine Reihe von Signalen, mit denen Sie erkennen können, ob eine Adresse bestätigt werden sollte.

1. Validierungsgranularität

Eine validationGranularity von ROUTE oder besser ist akzeptabel, aber entweder PREMISE oder SUBPREMISE geben ein stärkeres Signal für die Zustellbarkeit.

2. Sonstige Signale

Wenn Sie die Adresseneingabe vom Kunden bestätigen lassen möchten, enthält das Ergebnis auch die folgenden Informationen, um zu bestimmen, welche Komponenten untersucht werden müssen:

Abgeleitete Daten	Wenn das hasInferredComponents Feld den Wert true hat, wissen Sie hat die API Informationen ausgefüllt, die sie aus anderen Adresskomponenten abgeleitet hat.
Ersetzte Daten	Wenn das hasReplacedComponents Feld den Wert true hat, hat die API eingegebene Daten durch Daten ersetzt, die sie für die Gültigkeit der Adresse als erforderlich erachtet hat.

3. Signale für Adressen in den USA

Bestimmte Felder, die nur für Adressen in den USA gelten, weisen darauf hin, dass Ihre Logik die Details vom Kunden bestätigen lassen sollte. Eine der folgenden Bedingungen ist erfüllt:

dpvConfirmation	S Weitere Informationen zu dpvConfirmation finden Sie unter Adressen in den USA verarbeiten.
Adressantwort	Enthält missingComponentTypes Feld mit dem Wert von subpremise. Hinweis: Wenn das Feld andere Typen als subpremise enthält, fällt die Aktion in die Kategorie „Adresse korrigieren“. Eine vollständige Liste der Adresstypen finden Sie in der Geocoding-Dokumentation.

Beispiele für die Bestätigung von Adressen

Adresse akzeptieren

Sie akzeptieren eine Adresse, wenn das Ergebnis mit hoher Wahrscheinlichkeit darauf hinweist, dass die Adresse zustellbar ist und im nachgelagerten Prozess ohne weitere Kundeninteraktion verwendet werden kann.

Signale für die Akzeptanz

Die Address Validation API bietet eine Reihe von Signalen, mit denen Sie erkennen können, ob eine Adresse bestätigt werden sollte.

1. Validierungsgranularität

Eine validationGranularity von PREMISE oder besser ist akzeptabel, aber in einigen Fällen weist ROUTE immer noch auf eine zustellbare Adresse hin.

2. Sonstige Signale

Ein Ergebnis für eine Adresse von hoher Qualität sollte auch Folgendes enthalten:

• Keine ersetzten Daten. In diesem Fall ist hasReplacedComponents: FALSE.
• Keine abgeleiteten Komponenten. In diesem Fall ist hasInferredComponents: FALSE.

3. Signale für Adressen in den USA

Bestimmte Felder, die nur für Adressen in den USA gelten, weisen auf eine Adresse von hoher Qualität hin, an die zugestellt werden kann. Bei einer akzeptablen Adresse in den USA sollten Sie Folgendes sehen:

dpvConfirmation	Y Weitere Informationen zu dpvConfirmation finden Sie unter Adressen in den USA verarbeiten.

Beispiele für die Akzeptanz von Adressen