In diesem Dokument wird ein Verfahren zum Erstellen eines Systems zur Adressprüfung beschrieben, das verschiedene Antworten der Address Validation API verarbeiten kann. Darin wird beschrieben, wie Sie die API-Antwort interpretieren, um zu ermitteln, wann und wie Sie Ihre Kunden um weitere Informationen bitten sollten.
Im Allgemeinen bestimmt die API-Antwort, wie Ihr System eine Adresse verarbeiten sollte:
-
Beheben: Die Adresse enthält möglicherweise erhebliche Probleme.
Kunden auffordern, weitere Informationen anzugeben: -
Untergeordnete Gebäude hinzufügen: Möglicherweise fehlt in der Adresse ein untergeordnetes Gebäude.
Kunden auffordern, eine Einheitsnummer hinzuzufügen -
Bestätigen: Die Adresse enthält möglicherweise kleinere Probleme.
Erwäge, den Kunden aufzufordern, die Adresse zu bestätigen. -
Akzeptieren: Die Adresse enthält möglicherweise keine Probleme.
Sie können die Adresse auf eigenes Risiko ohne weitere Aufforderung verwenden.
Schlüsselzweck
In diesem Dokument erfahren Sie, wie Sie Ihr System so anpassen, dass die API-Antwort optimal analysiert und die nächsten Schritte für die angegebenen Adressen ermittelt werden können. Der folgende Pseudocode veranschaulicht einen möglichen Ablauf.
if (verdict.possibleNextAction == FIX)
Prompt the user to fix the address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
Prompt the user to add a unit number.
else if (verdict.possibleNextAction == CONFIRM)
Confirm with the user that the address is correct.
else
Continue with the address returned by the API.
Die genaue Logik hängt von Ihrer Situation ab. Weitere Informationen finden Sie unter Validierungslogik anpassen.
Beispiel-Workflows
In der folgenden Tabelle sind Beispiel-Workflows zusammengefasst, die Sie implementieren können, um Ihren Kunden basierend auf der API-Antwort aufzufordern.
| Systemverhalten | ||
|---|---|---|
| Adresse korrigieren |
Die Antwort von
|
|
| Untergeordnete Räumlichkeiten hinzufügen |
Die Antwort von
|
|
| Adresse bestätigen |
Die Antwort von
|
|
| Adresse akzeptieren |
Die Antwort von
|
|
Validierungslogik anpassen
Sie können die Ergebnisse aus dem Feld verdict.possibleNextAction verwenden, um zu bestimmen, wie Ihr System mit der API-Antwort verfährt. Es kann aber auch sinnvoll sein, benutzerdefinierte Logik zu erstellen, um beispielsweise geschäftsspezifische Anforderungen zu berücksichtigen.
In diesem Abschnitt wird veranschaulicht, wie Sie Ihre eigene benutzerdefinierte Logik entwickeln können, um die API-Antwort zu interpretieren und zu bestimmen, ob und wie Sie Ihren Kunden auffordern möchten. In diesem Abschnitt werden Risikostufen und zusätzliche API-Antwortsignale behandelt, die Sie bei der Anpassung berücksichtigen sollten.
Auch wenn Sie sich bei der Entscheidung über die nächsten Schritte ausschließlich auf die verdict.possibleNextAction verlassen, können Ihnen die unten beschriebenen zusätzlichen Signale helfen, Details zu potenziellen Problemen mit der Adresse zu verstehen.
Risikotoleranz
Die folgenden Empfehlungen können Ihnen helfen, ein effektiveres Reaktionsmodell zu entwickeln, wenn Sie festlegen, wie Ihr System auf Signale der Address Validation API reagiert. Dies sind jedoch nur Empfehlungen. Ihre Implementierung sollte zu Ihrem Geschäftsmodell passen.
| Anleitung | Details | |
|---|---|---|
| Risikostufe |
Berücksichtigen Sie die Toleranzgrenze für Ihre Situation, wenn Sie zwischen dem Auffordern von Korrekturen und dem Akzeptieren der eingegebenen Adresse abwägen. |
Die Address Validation API gibt eine Vielzahl von Signalen zurück, die Sie in Ihr Risikoniveau einbeziehen können, um den Validierungsprozess zu optimieren. Wenn eine Adresse beispielsweise eine nicht bestätigte Hausnummer hat, können Sie sie trotzdem akzeptieren. Wenn für Ihr Unternehmen eine höhere Adressgenauigkeit erforderlich ist, können Sie den Nutzer dazu auffordern. 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, das System die ursprüngliche Eingabe akzeptieren zu lassen, wenn der Kunde nicht auf 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. |
Beispiel für einen risikobewussten Bezahlvorgang
Wenn Sie das Risiko fehlgeschlagener Lieferungen verringern möchten, können Sie Ihre Logik so anpassen, dass Ihre Kunden häufiger aufgefordert werden. Anstatt die im Abschnitt Hauptzweck beschriebene Logik zu verwenden, können Sie beispielsweise die folgende Logik verwenden.
if (verdict.possibleNextAction == FIX or verdict.validationGranularity
== OTHER or verdict.validationGranularity == ROUTE)
Prompt customer to fix their address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
Prompt customer to add a unit number.
else if (verdict.possibleNextAction == CONFIRM or verdict.validationGranularity
== PREMISE_PROXIMITY or verdict.hasSpellCorrectedComponents or
verdict.hasReplacedComponents or verdict.hasInferredComponents)
Prompt customer to confirm their address.
else
Proceed with the returned address.
Beispiel für einen reibungslosen Bezahlvorgang
Wenn Sie die Reibung in Ihrem Checkout-Ablauf verringern möchten, können Sie Ihre Logik so anpassen, dass Ihre Kunden seltener aufgefordert werden. Anstatt die im Abschnitt Hauptzweck beschriebene Logik zu verwenden, können Sie beispielsweise die folgende Logik verwenden.
if (verdict.possibleNextAction == FIX)
Prompt customer to fix their address.
else if (verdict.hasReplacedComponents)
Prompt customer to confirm their address.
else
Proceed with the returned address.
FIX-Signale
Korrigieren Sie eine Adresse, wenn die Ergebnisse eindeutig darauf hinweisen, dass die Adresse möglicherweise nicht zustellbar ist. Ihr System kann den Kunden dann auffordern, die erforderlichen Informationen anzugeben. Anschließend können Sie den Workflow noch einmal ausführen, um eine Zustelladresse zu erhalten.
Die folgenden Felder der Address Validation API-Antwort können zusätzlich zu verdict.possibleNextAction verwendet werden, um festzustellen, ob eine Adresse schwerwiegende Probleme aufweist und welche das sind.
| Granularität der Validierung | Wenn das Enum für die Validierungsgranularität für eine Adresse OTHER ist, ist die Adresse wahrscheinlich falsch.
|
|---|---|
| Fehlende Komponenten | Wenn address.missingComponentTypes nicht leer ist, fehlen in der Adresse wahrscheinlich wichtige Informationen.
|
| Verdächtige Komponenten | Wenn das Enum für die Bestätigungsstufe für eine Komponente UNCONFIRMED_AND_SUSPICIOUS ist, ist die Komponente wahrscheinlich falsch.
|
| Nicht aufgelöste Komponenten | Ein unresolvedToken ist ein Teil der Eingabe, der nicht als gültiger Teil einer Adresse erkannt wird. |
| USPS DPV-Bestätigung | Wenn uspsData.dpvConfirmation entweder N ist oder leer ist, liegt möglicherweise ein Problem mit der Adresse vor. Dieses Feld ist nur für Adressen in den USA verfügbar. Weitere Informationen zu uspsData.dpvConfirmation finden Sie unter Umgang mit Adressen in den USA.
|
Beispiele für die Korrektur von Adressen
CONFIRM_ADD_SUBPREMISES-Signale (nur US-Adressen)
Sie fordern Ihren Kunden auf, die Adresse zu überprüfen und eine Einheitsnummer hinzuzufügen, wenn die Antwort der Address Validation API darauf hinweist, dass in der Adresse möglicherweise eine Unteradresse fehlt. In diesen Fällen ist die Adresse des Gebäudes wahrscheinlich gültig, aber Sie möchten sichergehen, dass die resultierende Adresse die vom Kunden angegebene ist.
Die folgenden Felder der Address Validation API-Antwort können zusätzlich zu verdict.possibleNextAction verwendet werden, um festzustellen, ob bei einer Adresse wahrscheinlich eine Untereinheit fehlt.
Missing subpremise component
|
Wenn das Feld address.missingComponentTypes den Wert subpremise enthält, bedeutet das, dass in der Adresse eine Wohnungsnummer fehlt.
|
|---|---|
| USPS DPV-Bestätigung | Wenn uspsData.dpvConfirmation gleich S ist, wurde die primäre Nummer der Adresse mit einer Adresse in der USPS-Datenbank abgeglichen. Es wurde jedoch erwartet, dass die Adresse auch eine sekundäre Nummer enthält. Dieses Feld ist nur für Adressen in den USA verfügbar. Weitere Informationen zu uspsData.dpvConfirmation finden Sie unter Umgang mit Adressen in den USA.
|
Beispiele für Adressen von untergeordneten Gebäudeteilen hinzufügen
CONFIRM-Signale
Sie bestätigen eine Adresse, wenn das Ergebnis angibt, dass die Address Validation API entweder Änderungen an Adresskomponenten vorgenommen oder diese abgeleitet hat, um eine validierte Adresse zu erstellen. In diesen Fällen haben Sie eine zustellbare Adresse, möchten aber sichergehen, dass die resultierende Adresse die vom Kunden angegebene ist.
Die folgenden Felder der Address Validation API-Antwort können zusätzlich zu verdict.possibleNextAction verwendet werden, um festzustellen, ob eine Adresse kleinere Probleme aufweist und welche das sind.
| Granularität der Validierung | Wenn validationGranularity für eine Adresse ROUTE oder PREMISE_PROXIMITY ist, ist die Adresse möglicherweise falsch.
|
|---|---|
| Abgeleitete Daten | Wenn das Feld hasInferredComponents den Wert true hat, wurde es von der API mit Informationen gefüllt, die aus anderen Adresskomponenten stammen.
|
| Ersetzte Daten | Wenn das Feld hasReplacedComponents den Wert true hat, wurden die eingegebenen Daten von der API durch Daten ersetzt, die die Adresse gültig machen.
|
| Rechtschreibkorrekturen | Wenn das Feld hasSpellCorrectedComponents den Wert true hat, hat die API die Rechtschreibung einiger falsch geschriebener Komponenten korrigiert.
|
ACCEPT-Signale
Sie können eine Adresse akzeptieren, wenn die Antwort der Address Validation API ein hohes Maß an Vertrauen bietet, dass die Adresse zustellbar ist und im nachgelagerten Prozess ohne weitere Kundeninteraktion verwendet werden kann.
Zusätzlich zu verdict.possibleNextAction können die folgenden Felder der Address Validation API-Antwort verwendet werden, um festzustellen, ob eine Adresse von akzeptabler Qualität ist.
| Granularität der Validierung | Ein validationGranularity von PREMISE ist oft akzeptabel, ein Wert von ROUTE kann jedoch weiterhin auf eine lieferbare Adresse hinweisen.
|
|---|---|
| Keine abgeleiteten Daten | Wenn das Feld hasInferredComponents den Wert false hat, wurden keine Komponenten in der Ausgabe abgeleitet.
|
| Keine ersetzten Daten | Wenn das Feld hasReplacedComponents den Wert false hat, wurden keine Eingabedaten ersetzt.
|
| Keine Rechtschreibkorrekturen | Wenn das Feld hasSpellCorrectedComponents den Wert false hat, wurden keine Rechtschreibkorrekturen vorgenommen.
|
| USPS – Bestätigung der DPV | Wenn uspsData.dpvConfirmation gleich Y ist, wurde die Adresse mit einer Adresse in der USPS-Datenbank abgeglichen. Dieses Feld ist nur für Adressen in den USA verfügbar. Weitere Informationen zu uspsData.dpvConfirmation finden Sie unter Umgang mit Adressen in den USA.
|