In diesem Dokument werden einige reale Szenarien beschrieben, in denen die Address Validation API Antwortsignale liefert, die in Ihrem System ein fix-Verhalten rechtfertigen. Beispielworkflows im Abschnitt Validierungslogik erstellen
Häufige Beispiele: Korrektur
In diesem Abschnitt werden häufige Beispiele beschrieben, in denen die Address Validation API Antwortsignale liefert, die auf Adressinformationen von geringerer Qualität hinweisen.
Stadt und Postleitzahl fehlen
In diesem Beispiel ist nur die Straßenadresse angegeben, nicht aber der Ort oder die Postleitzahl.
| Eingegebene Adresse | Region |
|---|---|
| 21 45th Street | USA |
Entscheidung bei fehlender Stadt und Postleitzahl
Im folgenden Beispiel werden die wichtigen Signale aus der Antwort hervorgehoben.
{
"inputGranularity": "PREMISE",
"validationGranularity": "OTHER",
"geocodeGranularity": "OTHER",
"hasUnconfirmedComponents": true,
"possibleNextAction": "FIX"
}
Die possibleNextAction gibt einen ersten Hinweis darauf, dass die Adresse möglicherweise nicht zustellbar ist. Die anderen hervorgehobenen Komponenten unterstützen diese Möglichkeit ebenfalls. Sie können also 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. Dabei werden einige wichtige Daten wie Ort und Postleitzahl ausgelassen.
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 possibleNextAction einen ersten Hinweis darauf, dass die Adresse möglicherweise nicht zustellbar ist. Außerdem ist die validationGranularity ROUTE, was auf eine Übereinstimmung mit der Straße hinweist, aber nicht genügend Informationen enthält, um zum Grundstück zu gelangen. Außerdem fehlt das Attribut addressComplete im Ergebnis. Daher ist es false. Eine weitere Abfrage des address-Objekts ergibt einen fehlenden Komponententyp:
"missingComponentTypes": [
"street_number"
]
Beispiele für Grenzfälle: Korrektur
Ob Sie eine Adresse korrigieren, bestätigen oder akzeptieren, hängt von Ihrem jeweiligen Unternehmen ab. Die folgenden Beispiele veranschaulichen Szenarien, die nicht unbedingt in eine bestimmte Kategorie fallen.
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 bei nicht bestätigter Hausnummer
Im folgenden Beispiel werden die wichtigen Signale hervorgehoben.
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete" : true,
"hasUnconfirmedComponents": true,
"possibleNextAction": "ACCEPT"
}
Es lohnt sich, die Kombination aus einer Validierungsgranularität nur für die Schätzung auf Standortebene zusammen mit nicht bestätigten Komponenten zu untersuchen. Bei einer Abfrage der Property addressComponents werden die folgenden nicht bestätigten componentType angezeigt:
{
"componentName": {
"text": "84",
"languageCode": "en"
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
}
Hier ist die confirmation_level der 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 weiterhin gültig sein könnten.
Untergeordnete Prämisse fehlt
In diesem Szenario fehlt bei einer Adresse nur eine untergeordnete Einheit, z. B. eine Apartment- oder Abteilungsnummer. Andernfalls kann die Address Validation API die Adresse vollständig validieren. Wie bei jeder fehlenden Adresskomponente ist die addressComplete false und daher bei der manuellen Überprüfung des Urteils nicht vorhanden.
Ein Beispiel: Ein Kunde gibt eine gültige Adresse für das Büro des Stadtassessors von San Francisco ein, vergisst aber die Zimmernummer.
| Eingegebene Adresse | Region |
|---|---|
| 1 Doctor Carlton B. Goodlett Place, San Francisco, CA 94102, USA | USA |
Urteil für fehlende untergeordnete Prämisse
In diesem Beispiel wird das Attribut addressComplete im Ergebnis nicht angezeigt. Daher ist es false. Daher wissen Sie, dass mindestens ein Adressenelement unerwartet, nicht aufgelöst oder nicht vorhanden ist.
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"hasInferredComponents": true,
"possibleNextAction": "CONFIRM_ADD_SUBPREMISES"
}
Eine address-Anfrage ergibt Folgendes:
"missingComponentTypes": [
"subpremise"
]
Bei weiterer Nachfrage liefert die USPS-Datenbank den dpvConfirmation-Code D, der ebenfalls auf eine fehlende untergeordnete Adresseinheit hinweist.