In diesem Dokument werden einige reale Szenarien beschrieben, in denen die Address Validation API Antwortsignale liefert, die ein Korrekturverhalten Ihres Systems erfordern könnten. Weitere Informationen finden Sie unter Workflow-Übersicht im Artikel Bestätigungslogik erstellen.
Häufige Beispiele: fix
In diesem Abschnitt werden häufige Beispiele beschrieben, in denen die Address Validation API Antwortsignale für qualitativ minderwertige Adressinformationen liefert.
Stadt und Postleitzahl fehlen
In diesem Beispiel ist nur die Straße ohne Ort oder Postleitzahl angegeben.
| Eingegebene Adresse | Region |
|---|---|
| 21 45 40th Street | USA |
Entscheidung bei fehlender Stadt und Postleitzahl
Im folgenden Beispiel sind die wichtigen Signale aus der Antwort hervorgehoben.
{
"inputGranularity": "PREMISE",
"validationGranularity": "OTHER",
"geocodeGranularity": "OTHER",
"hasUnconfirmedComponents": true,
"possibleNextAction": "FIX"
}
Das possibleNextAction ist ein erster Hinweis darauf, dass die Adresse möglicherweise nicht erreichbar ist. Auch die anderen hervorgehobenen Komponenten unterstützen diese Möglichkeit. Sie können die addressComponents abfragen, um mehr zu erfahren:
{
"componentName": {
"text": "21",
"languageCode": "en"
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
"componentName": {
"text": "45 40th street",
"languageCode": "en"
},
"componentType": "route",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
"componentName": {
"text": "United States",
"languageCode": "en"
},
"componentType": "country",
"confirmationLevel": "CONFIRMED"
}
Die Address Validation API gibt nur das Land (USA) als CONFIRMED zurück.
Alle anderen Adresskomponenten werden als UNCONFIRMED_BUT_PLAUSIBLE zurückgegeben, wobei einige wichtige Daten fehlen, z. B. Ort und Postleitzahl.
Hausnummer fehlt
In diesem Beispiel fehlt eine Hausnummer.
| Eingegebene Adresse | Region |
|---|---|
| Buckingham Palace Road, SW1W 9TQ London | UK |
Entscheidung bei fehlender Hausnummer
{
"inputGranularity": "PREMISE_PROXIMITY",
"validationGranularity": "ROUTE",
"geocodeGranularity": "ROUTE",
"possibleNextAction": "FIX"
}
Auch hier gibt der possibleNextAction einen ersten Hinweis darauf, dass die Adresse möglicherweise nicht erreichbar ist. Außerdem ist validationGranularity ROUTE, was auf eine Übereinstimmung mit der Straße hinweist, aber nicht auf ausreichende Informationen, um zur Unterkunft zu gelangen. Außerdem fehlt die Property addressComplete im Urteil. Daher ist sie false. Eine weitere Abfrage des address-Objekts zeigt einen fehlenden Komponententyp auf:
"missingComponentTypes": [
"street_number"
]
Beispiele für Grenzfälle: Korrektur
In einigen Fällen hängt es von Ihrem spezifischen Geschäftsszenario ab, ob Sie eine Adresse korrigieren, bestätigen oder akzeptieren. Die folgenden Beispiele veranschaulichen Szenarien, die nicht unbedingt in eine Kategorie fallen, die sich beheben lässt.
Nicht bestätigte Hausnummer
In diesem Szenario kann die Address Validation API die angegebene Hausnummer nicht bestätigen, gibt aber an, dass die Adresse vollständig ist.
| Eingegebene Adresse | Region |
|---|---|
| 84 Buckingham Palace Road, SW1W 9TQ, London | UK |
Entscheidung für nicht bestätigte Hausnummer
Im folgenden Beispiel sind die wichtigsten Signale hervorgehoben.
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete" : true,
"hasUnconfirmedComponents": true,
"possibleNextAction": "ACCEPT"
}
Es lohnt sich, die Kombination einer Validierungsgranularität nur auf der Grundlage von Näherungen auf Standortebene mit unbestätigten Komponenten zu untersuchen. Eine Abfrage der Property addressComponents zeigt die folgenden nicht bestätigten componentType an:
{
"componentName": {
"text": "84",
"languageCode": "en"
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
}
Hier ist die confirmation_level des street_number auf UNCONFIRMED_BUT_PLAUSIBLE festgelegt. Nicht bestätigt bedeutet, dass der Dienst die Hausnummer 84 in seinem Datensatz nicht finden kann. Plausibel bedeutet, dass die Komponentendaten trotzdem gültig sein könnten.
Untergeordnete Örtlichkeit fehlt
In diesem Szenario fehlt bei einer Adresse nur eine untergeordnete Örtlichkeit, z. B. eine Wohnungs- oder Abteilungsnummer. Andernfalls kann die Address Validation API die Adresse vollständig überprüfen. Wie bei fehlenden Adresskomponenten ist addressComplete = false und daher bei der manuellen Überprüfung des Urteils nicht vorhanden.
Angenommen, ein Kunde gibt eine gültige Adresse für das Finanzamt von San Francisco ein, lässt aber die Raumnummer aus.
| Eingegebene Adresse | Region |
|---|---|
| 1 Doctor Carlton B Goodlett Place, San Francisco, CA 94102, USA | USA |
Entscheidung für fehlende untergeordnete Örtlichkeit
In diesem Beispiel wird im Urteil die addressComplete-Eigenschaft nicht angezeigt. Daher ist sie false. Sie wissen also, dass mindestens ein Adresselement unerwartet, nicht aufgelöst oder fehlt.
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"hasInferredComponents": true,
"possibleNextAction": "CONFIRM_ADD_SUBPREMISES"
}
Eine address-Abfrage ergibt Folgendes:
"missingComponentTypes": [
"subpremise"
]
Bei weiterer Prüfung wird in den USPS-Daten ein dpvConfirmation-Code von D angezeigt, der ebenfalls auf eine fehlende untergeordnete Örtlichkeit hinweist.