Adresse bestätigen – Beispiele

In diesem Dokument werden eine Reihe von Beispielen aus der Praxis beschrieben, in denen die Address Validation API Antwortsignale für Adressen liefert, die ein Bestätigen durch Ihr System erfordern. Die Beispiele sind veranschaulichend, aber nicht vollständig. Weitere Informationen finden Sie unter Workflow-Übersicht im Abschnitt Validierungslogik erstellen.

Tipp: Öffnen Sie die Address Validation-Demo und versuchen Sie, die Beispieladressen selbst zu validieren.

Typische Beispiele: Bestätigen

Das folgende Beispiel veranschaulicht den Fall von Ballungsräumen mit ähnlichen Straßennamen. Angenommen, ein Nutzer möchte die Adresse für Google Building D in Kirkland, WA, USA eingeben. Anstelle von Kirkland als Stadt gibt er jedoch versehentlich Seattle ein.

Eingegebene Adresse	Region
Building D, 451 7th Avenue South, Seattle, WA 98033	USA

Ergebnis für ersetzte Daten

Im folgenden Beispiel werden die wichtigen Signale aus dem Ergebnis hervorgehoben.

{
  "inputGranularity": "SUB_PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete": true,
  "hasUnconfirmedComponents": true
  "hasReplacedComponents": true
}

Die PREMISE_PROXIMITY Granularitätsebene gibt die Nähe einer Adresse auf Gebäudeebene an, ist aber nicht so detailliert wie SUB_PREMISE, die als Granularität für die Eingabe verwendet wird. Die Antwort enthält sowohl nicht bestätigte als auch ersetzte Komponenten. Daher fällt die Kombination in die Kategorie Bestätigen.

Eine Abfrage der Adresskomponenten ergibt die folgenden Problembereiche:

{
  "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 ähnliche Adresse zur angegebenen Adresse in Seattle gefunden und die Postleitzahl, eine Komponente auf höherer Ebene, ersetzt, um eine Seattle -Adresse zu erhalten. Dies könnte ein gültiger Ersatz sein. Zusammen mit der Tatsache, dass Komponenten nicht bestätigt wurden, ist es jedoch sinnvoll, zu prüfen, ob der Nutzer eine Adresse in Seattle und nicht eine andere Adresse, z. B. in Kirkland, eingeben möchte.

Tipp: Prüfen Sie die richtige Adresse in der Demo, mit 451 7th Avenue South, Kirkland, WA 98033 , um die Antwort für die ursprünglich beabsichtigte Adresse zu sehen.

Aktion:Bestätigen Sie die Adresseingabe mit dem Kunden.

Sonderfälle: Bestätigen

Die folgenden Beispiele veranschaulichen die folgenden Arten von Sonderfällen:

• Geringfügige Schlussfolgerungen, die bestätigt werden. Die Address Validation API leitet entweder das Land, die Postleitzahl oder das Bundesland ab, aber alles andere wird sowohl angegeben als auch bestätigt. Die Kombination aus Granularität und Bestätigungsebene führt zu einer geringfügigen Schlussfolgerung, die nicht unbedingt eine Bestätigungsaktion erfordert.
• Unerwartete Adresskomponente, die NICHT bestätigt wird. Nicht bestätigte Adresskomponenten erhöhen das Risikoniveau der Adresse. Dies kann eine Bestätigung erforderlich machen.
• Unerwartete Adresskomponente, die bestätigt wird. Die Komponente ist für eine korrekte Adresse nicht unbedingt erforderlich und wird von der Address Validation API aus der Ausgabe entfernt. Formatierungsprobleme erfordern in der Regel keine Bestätigung.

Geringfügige Schlussfolgerungen, die bestätigt werden

In Kombination mit bestätigten Daten auf einer detaillierteren Ebene kann die API dennoch eine korrekte Schlussfolgerung ziehen, wenn in der Eingabe nur eine Komponente der folgenden Typen fehlt:

• Stadt
• Bundesland
• Postleitzahl
• Land

Ein Kunde gibt beispielsweise eine gültige Straßenadresse für ein McDonald's-Restaurant in Springfield, Massachusetts, an, vergisst aber, die Stadt einzugeben, und gibt eine Postleitzahl ohne die vierstellige Erweiterung an.

Eingegebene Adresse	Region
1402 Allen St, MA 01118	USA

Ergebnis für fehlende Stadt

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true,
  "hasInferredComponents": true
}

In Situationen, in denen die Address Validation API Komponenten auf höherer Ebene ableitet, um eine lieferbare Adresse zu erstellen, können Sie sich darauf verlassen, dass die Daten aus dem System korrekt sind. Das liegt daran, dass abgeleitete Komponenten, die eine große geografische Region darstellen, leichter mit bestätigten Adresskomponenten abgeglichen werden können, die detaillierter sind. Auch in Ländern, in denen Städtenamen wiederholt werden, z. B. Springfield in den USA, können die anderen Komponenten in Kombination eine eindeutige Adresse ergeben.

In unserem Beispiel oben zeigt eine Überprüfung aller Adresskomponenten, dass jede Komponente bestätigt ist. Das bedeutet, dass sie mit den von der Address Validation API gespeicherten Daten übereinstimmt und dass der Dienst auch zwei Komponenten auf höherer Ebene ableitet.

{
  "componentName": {
    "text": "Springfield",
    "languageCode": "en"
  },
  "componentType": "locality",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
},
{
  "componentName": {
    "text": "1806"
  },
  "componentType": "postal_code_suffix",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
}

Aktion:Akzeptieren. Adressen wie diese bieten eine ausreichend bestätigte Granularität sowie eine Bestätigung der abgeleiteten Komponenten, sodass Ihre Logik sie als gültig akzeptieren kann, ohne den Kunden aufzufordern.

Unerwartete Adresskomponente, die NICHT bestätigt wird

Dieses Szenario veranschaulicht, wie wichtig es ist, zu prüfen, wann Komponenten nicht bestätigt werden. 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 entweder akzeptieren oder sie mit dem Kunden bestätigen, je nach Risikostufe und Konfidenzniveau.

Eine Adresse kann beispielsweise aus einer Region stammen, in der Kunden häufig harmlose Informationen eingeben, die von der Post ignoriert werden. In diesem Fall würden Sie die Adresse akzeptieren. In einigen Fällen entspricht eine nicht bestätigte Komponente jedoch möglicherweise nicht dem, was der Kunde möchte.

Eingegebene Adresse	Region
1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry	Frankreich

Ergebnis für unerwartete Adresskomponente, die nicht bestätigt wird

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "unconfirmedComponents": true
}

Neben einem Ergebnis mit nicht bestätigten Komponenten gibt die Address Validation API auch die folgende formatierte Adresse zurück:

"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",

Eine Suche 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
}

Aktion:Bestätigen. In diesem Fall ist die Unterortschaft, die ein Wohngebiet oder eine Nachbarschaft angeben kann, möglicherweise korrekt, wird aber von der Post ignoriert. Da diese Informationen jedoch **nicht** von der Address Validation API bestätigt werden, ist es sinnvoll, sie mit dem Kunden zu bestätigen. An diesem Punkt können Sie das Entfernen ignorieren oder bestätigen.

Unerwartete Adresskomponente, die bestätigt wird

Dieses Beispiel veranschaulicht die Einbeziehung einer Grafschaft im Vereinigten Königreich in die angegebene Adresse, was üblich ist. Dies ist jedoch keine Anforderung der britischen Post und wird im Wesentlichen ignoriert. Weitere Informationen finden Sie unter postoffice.co.uk und How to address UK and international mail.

Wenn ein Kunde eine Grafschaft in einer Adresse im Vereinigten Königreich angibt, wird dies vom Dienst als unerwartete Eingabe bewertet.

Eingegebene Adresse	Region
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP	Vereinigtes Königreich

Ergebnis für unerwartete Adresskomponente, die bestätigt wird

{
   "inputGranularity": "PREMISE",
   "validationGranularity": "PREMISE",
   "geocodeGranularity": "PREMISE"
}

Hier wird address_complete als „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
}

Diese Komponente ist sowohl unerwartet als auch bestätigt, was Folgendes bedeutet:

• Als korrekte Daten bestätigt. Dies gibt an, dass die Komponente die korrekte Grafschaft ist, in der sich die Adresse befindet.
• Unerwartet als Eingabe. Gibt eine Komponente an, die für die korrekte Formatierung der Adresse nicht erforderlich ist.

Gloucestershire ist zwar die richtige Grafschaft für die eingegebene Adresse, die Adresse selbst ist jedoch nicht richtig formatiert. Die Address Validation API prüft auch, ob die Informationen richtig formatiert sind.

Aktion: In diesem Szenario wird die empfohlene Maßnahme darin bestehen, dieses Signal zu ignorieren und die Adresse zu akzeptieren.