In diesem Dokument werden verschiedene reale Szenarien beschrieben, in denen die Address Validation API Antwortsignale für Adressen bereitstellt, für die ein Confirm-Verhalten des Systems erforderlich ist. Weitere Informationen finden Sie unter Validierungslogik erstellen in der Workflowübersicht.
Gängige Beispiele: bestätigen
Im folgenden Beispiel sehen Sie Großräume mit ähnlichen Straßennamen. Angenommen, ein Nutzer möchte die Adresse für Google Building D in Kirkland, WA, USA eingeben. Statt Kirkland jedoch als Stadt anzugeben, fährt er ungewollt Seattle ein.
| Eingegebene Adresse | Region |
|---|---|
| Building D, 451 7th Avenue South, Seattle, WA 98033, USA | USA |
Ergebnis für ersetzte Daten
Das folgende Beispiel unterstreicht die wichtigen Signale aus der Antwort.
{
"inputGranularity": "SUB_PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete": true,
"hasUnconfirmedComponents": true
"hasReplacedComponents": true
}
PREMISE_PROXIMITY gibt die Nähe einer Adresse auf Gebäudeebene an, ist aber nicht so detailliert wie SUB_PREMISE, da dies der Detaillierungsgrad der Eingabe ist.
Die Antwort enthält auch nicht bestätigte und ersetzte Komponenten. Daher wird dies durch die Kombination in die Kategorie confirm aufgenommen.
Eine Abfrage der Adresskomponenten zeigt die folgenden Bedenken auf:
{
"componentName": {
"text": "451",
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
"componentName": {
"text": "98104",
},
"componentType": "postal_code",
"confirmationLevel": "CONFIRMED",
"replaced": true
}
...
{
"componentName": {
"text": "Building D",
"language_code": "en"
},
"componentType": "subpremise",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......
"unconfirmedComponentTypes": [
"street_number",
"subpremise"
]
In diesem Fall hat die Address Validation API eine nahe Annäherung an die angegebene Adresse in Seattle gefunden und die Postleitzahl, eine übergeordnete Komponente, ersetzt, um diese zu einer Seattle-Adresse aufzulösen. Dies könnte ein gültiger Ersatz sein, aber da die Komponenten nicht bestätigt wurden, ist es sinnvoll, dafür zu sorgen, dass der Nutzer eine Adresse in Seattle eingeben möchte und nicht etwas anderes, z. B. Kirkland.
Grenzfallbeispiele: Bestätigen
Die folgenden Beispiele veranschaulichen die folgenden Grenzfalltypen:
- Geringfügige Rückschlüsse, die bestätigt SIND. Die Address Validation API leitet entweder das Land, die Postleitzahl oder den Bundesstaat ab. Alles andere wird jedoch sowohl angegeben als auch bestätigt. Die Kombination aus Detaillierungsgrad und Bestätigungsstufe sorgt für eine geringfügige Inferenz, die keine Bestätigung erfordert.
- Unerwartete Adresskomponente NICHT bestätigt. Nicht bestätigte Adresskomponenten erhöhen die Risikostufe der Adresse. Dies könnte eine Bestätigung rechtfertigen.
- Unerwartete Adresskomponente, die bestätigt ist: Die Komponente ist für eine korrekte Adresse nicht unbedingt erforderlich und wird von der Address Validation API aus der Ausgabe entfernt. Formatierungsprobleme rechtfertigen im Allgemeinen keine Bestätigung.
Geringfügige Rückschlüsse, die bestätigt wurden
In Kombination mit bestätigten Daten auf einer höheren Ebene kann die API trotzdem eine korrekte Inferenz vornehmen, wenn in der Eingabe nur eine Komponente der folgenden Typen fehlt:
- Stadt
- Status
- Postleitzahl
- Land
Beispiel: Ein Kunde gibt eine gültige Adresse für ein McDonald's-Restaurant in Springfield, Massachusetts, an, vergisst aber, die Stadt einzugeben, und gibt eine Postleitzahl ohne 4-stellige Erweiterung an.
| Eingegebene Adresse | Region |
|---|---|
| 1402 Allen St, MA 01118 | USA |
Ergebnis aufgrund fehlender Stadt
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"addressComplete": true,
"hasInferredComponents": true
}
In Situationen, in denen die Address Validation API übergeordnete Komponenten ableitet, um eine zu liefernde Adresse zu erzeugen, können Sie mit größerer Sicherheit darauf vertrauen, dass die Daten aus dem System korrekt sind. Das liegt daran, dass abgeleitete Komponenten, die eine große geografische Region repräsentieren, leichter mit bestätigten Adresskomponenten abgeglichen werden können, die detaillierter sind. Auch in Ländern, in denen Städtenamen wiederholt werden, z. B. in Springfield in den USA, können die anderen Komponenten, die damit kombiniert werden, eine eindeutige Adresse ergeben.
In unserem Beispiel oben zeigt ein Scan aller Adresskomponenten, dass jede Komponente bestätigt ist, d. h. mit den von der Address Validation API gespeicherten Daten übereinstimmt, und dass der Dienst außerdem zwei übergeordnete Komponenten ableitet.
{
"componentName": {
"text": "Springfield",
"languageCode": "en"
},
"componentType": "locality",
"confirmationLevel": "CONFIRMED",
"inferred": true
},
{
"componentName": {
"text": "1806"
},
"componentType": "postal_code_suffix",
"confirmationLevel": "CONFIRMED",
"inferred": true
}
Unerwartete Adresskomponente NICHT bestätigt
Dieses Szenario veranschaulicht, wie wichtig es ist, zu prüfen, wenn Komponenten nicht bestätigt sind. Wenn eine Adresskomponente unerwartet ist, wird sie von der Address Validation API aus der Ausgabe entfernt. In diesen Fällen können Sie die Adresse je nach Risiko- und Konfidenzniveau entweder annehmen oder noch einmal mit dem Kunden bestätigen.
Beispiel: Eine Adresse stammt aus einer Region, in der Kunden häufig harmlose Informationen eingeben, die von der Postbehörde ignoriert werden. In diesem Fall würden Sie die Adresse akzeptieren. In einigen Fällen entspricht jedoch eine nicht bestätigte Komponente dem Kunden möglicherweise nicht.
| Eingegebene Adresse | Region |
|---|---|
| 1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry | Frankreich |
Ergebnis für unerwartete Adresskomponente nicht bestätigt
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true
}
Zusätzlich zu einem Ergebnis mit nicht bestätigten Komponenten gibt die Address Validation API die folgende formatierte Adresse zurück:
"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",
Ein Scan nach nicht bestätigten Komponenten zeigt, dass die API la caritat 2 aus der zurückgegebenen Adresse entfernt hat:
{
"componentName": {
"text": "la caritat 2",
"languageCode": "fr"
},
"componentType": "sublocality_level_1",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
"unexpected": true
}
Unerwartete Adresskomponente, die bestätigt wird
In diesem Beispiel wird ein Landkreis im Vereinigten Königreich in die angegebene Adresse aufgenommen, was gängige Praxis ist. Dies ist jedoch keine Anforderung der britischen Postbehörde und wird im Wesentlichen ignoriert. Weitere Informationen finden Sie unter postoffice.co.uk und Adressieren von Postsendungen im Vereinigten Königreich und im Ausland.
Wenn ein Kunde einen Landkreis mit einer Adresse im Vereinigten Königreich angibt, wertet der Dienst dies als unerwartete Eingabe.
| Eingegebene Adresse | Region |
|---|---|
| 33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | UK |
Ergebnis für unerwartete Adresskomponente, die bestätigt ist
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
Hier wird address_complete mit „false“ ausgewertet und eine Analyse der Adresskomponente ergibt ein unerwartetes Flag.
{
"componentName": {
"text": "Gloucestershire",
"languageCode": "en"
},
"componentType": "administrative_area_level_2",
"confirmationLevel": "CONFIRMED",
"unexpected": true
}
Obwohl Gloucestershire der richtige Landkreis für die eingegebene Adresse ist, ist die Adresse selbst falsch formatiert. Beachten Sie, dass die Address Validation API auch Informationen auf ihre korrekte Formatierung auswertet.