In diesem Dokument wird beschrieben, wie Sie ein System zur Adressprüfung erstellen, um eine Vielzahl von Antworten von der Address Validation API zu verarbeiten. Darin wird erläutert, wie Sie die API-Antwort interpretieren, um zu ermitteln, wann und wie Sie Ihre Kunden um weitere Informationen bitten.
Im Allgemeinen gibt die API-Antwort an, wie Ihr System mit einer Adresse umgehen sollte:
-
Korrigieren: Die Adresse enthält möglicherweise erhebliche Probleme.
Bitten Sie den Kunden, weitere Informationen anzugeben. -
Nebenstelle hinzufügen: Möglicherweise fehlt der Adresse eine Nebenstelle.
Bitten Sie den Kunden, eine Gerätenummer hinzuzufügen. -
Bestätigen: Die Adresse enthält möglicherweise kleinere Probleme.
Bitte den Kunden, die Adresse zu bestätigen. -
Akzeptieren: Die Adresse enthält möglicherweise keine Probleme.
Sie können die Adresse auch ohne weitere Aufforderung verwenden. Das geschieht jedoch auf eigenes Risiko.
Schlüsselzweck
In diesem Dokument erfahren Sie, wie Sie Ihr System so ändern, dass die API-Antwort am besten analysiert und die nächsten Aktionen für die angegebenen Adressen festgelegt 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.
Mögliche Workflows
In der folgenden Tabelle sind mögliche Workflows zusammengefasst, die du implementieren könntest, um deinen Kunden basierend auf der API-Antwort zu bitten,
| Systemverhalten | ||
|---|---|---|
| Adresse korrigieren |
Die Antwort von
|
|
| Untergeordnete Standorte 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 fortfährt. Sie können aber auch benutzerdefinierte Logik erstellen, um beispielsweise geschäftsspezifische Anforderungen zu erfüllen.
In diesem Abschnitt wird veranschaulicht, wie Sie Ihre eigene benutzerdefinierte Logik zur Interpretation der API-Antwort entwickeln können, um zu bestimmen, ob und wie Sie Ihren Kunden auffordern möchten. In diesem Abschnitt werden Risikostufen und zusätzliche API-Antwortsignale beschrieben, 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 erfahren.
Risikotoleranz
Wenn Sie festlegen, wie Ihr System auf Signale von der Address Validation API reagiert, können Ihnen die folgenden Empfehlungen dabei helfen, ein effektiveres Antwortmodell zu erstellen. Dies sind jedoch nur Empfehlungen. Die Implementierung sollte Ihrem Geschäftsmodell entsprechen.
| Anleitung | Details | |
|---|---|---|
| Risikostufe |
Berücksichtigen Sie die Toleranzgrenze für Ihre Situation, wenn Sie entscheiden, ob Sie eine Korrektur vorschlagen oder die Adresse so akzeptieren, wie sie eingegeben wurde. |
Die Address Validation API gibt eine Vielzahl von Signalen zurück, die Sie in Ihr Risikoniveau einbinden 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 hingegen eine genauere Adresse erforderlich ist, können Sie den Nutzer dazu auffordern. Ein Beispiel, das in beide Kategorien fallen könnte, finden Sie unter Nicht in den USA bestätigte Hausnummer im Hilfeartikel Zulässige Adressen – Beispiele. |
| Adressen akzeptieren |
Es empfiehlt sich, dass Ihr System den ursprünglichen Eintrag akzeptiert, wenn der Kunde nicht auf Prompts 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 risikoaverseren Bezahlvorgang
Wenn Sie das Risiko von fehlgeschlagenen Übermittlungen reduzieren 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 den Bezahlvorgang reibungsloser gestalten möchten, können Sie die Logik so anpassen, dass Kunden weniger häufig 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 Zustellung an die Adresse möglicherweise nicht möglich ist. Ihr System kann den Kunden dann auffordern, die erforderlichen Informationen anzugeben. Anschließend können Sie Ihren Workflow noch einmal starten, um eine Lieferadresse zu erhalten.
Die folgenden Felder der Antwort der Address Validation API können zusätzlich zu verdict.possibleNextAction verwendet werden, um festzustellen, ob eine Adresse schwerwiegende Probleme aufweist und welche das sind.
| Detaillierungsebene der Validierung | Wenn die Validierungsgranularität für eine Adresse OTHER ist, ist die Adresse wahrscheinlich falsch.
|
|---|---|
| Fehlende Komponenten | Wenn das Feld address.missingComponentTypes nicht leer ist, fehlen der Adresse wahrscheinlich wichtige Informationen.
|
| Verdächtige Komponenten | Wenn die Bestätigungsebene für eine Komponente UNCONFIRMED_AND_SUSPICIOUS ist, ist die Komponente wahrscheinlich falsch.
|
| Nicht behobene Probleme | Ein unresolvedToken ist ein Teil der Eingabe, der nicht als gültiger Teil einer Adresse erkannt wird. |
| USPS DPV Confirmation | Wenn uspsData.dpvConfirmation entweder N 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 Adressen in den USA verarbeiten.
|
Beispiele für die Korrektur von Adressen
Signale vom Typ CONFIRM_ADD_SUBPREMISES (nur US-Adressen)
Sie bitten Ihren Kunden, die Adresse zu prüfen und gegebenenfalls eine Wohnungsnummer hinzuzufügen, wenn die Antwort der Address Validation API darauf hinweist, dass für die Adresse möglicherweise eine untergeordnete Örtlichkeit fehlt. In diesen Fällen ist die Adresse des Gebäudes wahrscheinlich gültig, Sie möchten aber sicher sein, dass die resultierende Adresse die vom Kunden beabsichtigte ist.
Die folgenden Felder der API-Antwort für die Adressüberprüfung können zusätzlich zu verdict.possibleNextAction verwendet werden, um festzustellen, ob für eine Adresse wahrscheinlich ein untergeordneter Standort fehlt.
Missing subpremise component
|
Wenn das Feld address.missingComponentTypes den Wert subpremise enthält, fehlt der Adresse eine Wohnungsnummer.
|
|---|---|
| USPS DPV Confirmation | Wenn uspsData.dpvConfirmation = S ist, wurde die primäre Nummer der Adresse mit einer Adresse in der USPS-Datenbank abgeglichen. Die Adresse sollte jedoch auch eine sekundäre Nummer enthalten. 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 Nebenstellen hinzufügen
CONFIRM-Signale
Sie bestätigen eine Adresse, wenn das Urteil darauf hinweist, dass die Address Validation API entweder Adressenkomponenten abgeleitet oder geändert hat, um eine bestätigte Adresse zu erstellen. In diesen Fällen haben Sie zwar eine zustellbare Adresse, möchten aber sicher sein, dass es sich bei der resultierenden Adresse um die vom Kunden beabsichtigte Adresse handelt.
Die folgenden Felder der API-Antwort für die Adressüberprüfung können zusätzlich zu verdict.possibleNextAction verwendet werden, um festzustellen, ob eine Adresse kleinere Probleme aufweist und welche das sind.
| Detaillierungsebene 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, wissen Sie, dass die API Informationen aus anderen Adresskomponenten eingefügt hat.
|
| Ersetzte Daten | Wenn das Feld hasReplacedComponents den Wert true hat, hat die API die eingegebenen Daten 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 API-Antwort der Address Validation API mit hoher Wahrscheinlichkeit darauf hinweist, dass die Adresse erreichbar ist und ohne weitere Kundeninteraktion im Downstream-Prozess verwendet werden kann.
Die folgenden Felder der API-Antwort der Adressüberprüfung können zusätzlich zu verdict.possibleNextAction verwendet werden, um festzustellen, ob eine Adresse akzeptabel ist.
| Detaillierungsebene der Validierung | Ein validationGranularity von PREMISE ist oft akzeptabel, auch wenn ein Wert von ROUTE möglicherweise auf eine zustellbare Adresse hinweist.
|
|---|---|
| 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 DPV Confirmation | Wenn uspsData.dpvConfirmation 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.
|