Adresse bestätigen – Beispiele

In diesem Dokument werden einige reale Szenarien beschrieben, in denen die Address Validation API Antwortsignale für Adressen liefert, die ein Bestätigungsverhalten von Ihrem System erfordern. Weitere Informationen finden Sie unter Workflow-Übersicht im Artikel Bestätigungslogik erstellen.

Hinweis: Die folgenden Beispiele dienen der Veranschaulichung, sind aber nicht vollständig.

Gängige Beispiele: bestätigen

Das folgende Beispiel zeigt den Fall von Ballungsräumen mit ähnlichen Straßennamen. Angenommen, ein Nutzer möchte die Adresse für das Google-Gebäude D in Kirkland, Washington, USA eingeben. Anstatt Kirkland als Ort gibt er jedoch versehentlich Seattle ein.

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

Entscheidung für ersetzte Daten

Im Beispiel unten sind die wichtigen Signale aus der Antwort hervorgehoben.

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

PREMISE_PROXIMITY gibt die Näherung einer Adresse auf Gebäudeebene an, ist aber nicht so detailliert wie SUB_PREMISE, die bei der Eingabe angegebene Detaillierungsebene. Die Antwort enthält sowohl nicht bestätigte als auch ersetzte Komponenten. Daher wird die Anfrage der Kategorie confirm (bestätigen) zugeordnet.

Eine Abfrage der Adresskomponenten zeigt die folgenden Probleme 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 Adresse gefunden, die der angegebenen Adresse in Seattle sehr ähnlich ist. Die Postleitzahl, eine Komponente höherer Ebene, wurde ersetzt, um eine Adresse in Seattle zu ermitteln. Dies könnte ein gültiger Ersatz sein. Da die Komponenten jedoch nicht bestätigt wurden, ist es sinnvoll, sich zu vergewissern, dass der Nutzer eine Adresse in Seattle und nicht in einer anderen Stadt wie Kirkland eingeben möchte.

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

Aktion:Bestätige die Adresse mit dem Kunden.

Beispiele für Grenzfälle: bestätigen

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

• Minderwertige Schlussfolgerungen, die BESTÄTIGT sind Die Address Validation API leitet entweder das Land, die Postleitzahl oder den Bundesstaat ab. Alles andere wird angegeben und bestätigt. Die Kombination aus Detaillierungsgrad und Bestätigungsebene führt zu einer geringfügigen Inferenz, für die nicht unbedingt eine Bestätigungsaktion erforderlich ist.
• Unerwartete Adresskomponente NICHT bestätigt. Nicht bestätigte Adresskomponenten erhöhen das Risikoniveau der Adresse. Das sollte bestätigt werden.
• 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 erfordern in der Regel keine Bestätigung.

Gesicherte kleinere Schlussfolgerungen

In Kombination mit bestätigten Daten auf einer detaillierteren Ebene kann die API auch dann eine korrekte Inferenz treffen, wenn in der Eingabe nur eine Komponente der folgenden Typen fehlt:

• Stadt
• Status
• Postleitzahl
• Land

Ein Kunde gibt beispielsweise eine gültige Adresse 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

Entscheidung für fehlende Stadt

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

Wenn die Address Validation API Komponenten höherer Ebene ableitet, um eine zustellbare Adresse zu erstellen, können Sie mit größerer Sicherheit davon ausgehen, dass die Daten aus dem System korrekt sind. Das liegt daran, dass abgeleitete Komponenten, die ein großes geografisches Gebiet repräsentieren, leichter mit bestätigten Adresskomponenten abgeglichen werden können, die detaillierter sind. Selbst in Ländern, in denen sich Ortsnamen wiederholen, z. B. Springfield in den USA, können die anderen Komponenten zusammen eine eindeutige Adresse ergeben.

In unserem Beispiel oben zeigt ein Scan aller Adresskomponenten, dass jede Komponente bestätigt ist, d. h., sie stimmt mit den von der Address Validation API gespeicherten Daten überein und der Dienst leitet auch zwei Komponenten der höheren Ebene ab.

{
  "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 ausreichende bestätigte Detaillierung sowie eine Bestätigung der abgeleiteten Komponenten, sodass Ihre Logik diese als gültig akzeptieren kann, ohne den Kunden um eine Bestätigung bitten zu müssen.

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 Vertrauensniveau entweder akzeptieren oder noch einmal mit dem Kunden bestätigen.

Eine Adresse kann beispielsweise aus einer Region stammen, in der Kunden oft harmlose Informationen eingeben, die von der Post ignoriert werden. In diesem Fall akzeptieren Sie die Adresse. In einigen Fällen entspricht eine nicht bestätigte Komponente jedoch möglicherweise nicht den Wünschen des Kunden.

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

Entscheidung für unerwartete Adresskomponente nicht bestätigt

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

Zusätzlich zu einem Urteil 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 unbestä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 untergeordnete Ortsangabe, die einen Wohnbezirk oder ein Viertel angeben kann, möglicherweise korrekt, wird aber von der Postbehörde ignoriert. Da diese Informationen jedoch nicht von der Address Validation API bestätigt werden, ist es sinnvoll, sie mit dem Kunden zu bestätigen. Sie können die Entfernung ignorieren oder bestätigen.

Unerwartete Adressenkomponente, die BESTÄTIGT ist

In diesem Beispiel ist ein County im Vereinigten Königreich in der angegebenen Adresse enthalten, was üblich ist. Dies ist jedoch keine Anforderung der britischen Post und wird im Grunde ignoriert. Weitere Informationen finden Sie unter postoffice.co.uk und Adressierung von Briefen im Vereinigten Königreich und international.

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

Eingegebene Adresse	Region
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP	UK

Entscheidung für unerwartete Adresskomponente, die BESTÄTIGT ist

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

Hier ergibt address_complete den Wert „falsch“ und eine Analyse der Adresskomponente zeigt 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. Das bedeutet Folgendes:

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

Gloucestershire ist der richtige Landkreis für die eingegebene Adresse, die Adresse selbst ist jedoch falsch formatiert. Wie Sie wissen, prüft die Address Validation API auch, ob die Informationen richtig formatiert sind.

Aktion:In diesem Szenario wird empfohlen, dieses Signal zu ignorieren und die Adresse zu akzeptieren.