Adresse bestätigen – Beispiele

In diesem Dokument werden verschiedene reale Szenarien beschrieben, in denen die Address Validation API Antwortsignale für Adressen liefert, die ein Bestätigungsverhalten Ihres Systems erfordern. Die Beispiele hier dienen der Veranschaulichung, sind aber nicht vollständig. Weitere Informationen finden Sie unter Workflowübersicht im Abschnitt Validierungslogik erstellen.

Tipp: Öffnen Sie die Address Validation-Demo und probieren Sie die Validierung der Beispieladressen selbst aus.

Typische 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 Google Building D in Kirkland, WA, USA eingeben. Anstatt Kirkland als Stadt einzugeben, geben sie jedoch versehentlich Seattle ein.

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

Urteil für ersetzte Daten

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

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

Die Granularitätsstufe PREMISE_PROXIMITY gibt die Näherung einer Adresse auf Gebäudeebene an, ist aber nicht so detailliert wie SUB_PREMISE, die bei der Eingabe bereitgestellte Granularität. Die Antwort enthält außerdem sowohl unbestätigte als auch ersetzte Komponenten, sodass die Kombination in die Kategorie confirm fällt.

Eine Abfrage der Adresskomponenten zeigt 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 gute Annäherung an die angegebene Adresse in Seattle gefunden und die Postleitzahl, eine übergeordnete Komponente, ersetzt, um eine Adresse in Seattle zu erhalten. Das könnte ein gültiger Ersatz sein. Da die Komponenten jedoch nicht bestätigt wurden, ist es sinnvoll, sicherzustellen, dass der Nutzer eine Adresse in Seattle und nicht in einer anderen Stadt wie 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.

Maßnahme: Bestätige die Adresseingabe mit dem Kunden.

Beispiele für Grenzfälle: Bestätigen

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

• Unbedeutende Schlussfolgerungen, die bestätigt SIND. 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ätigungsstufe führt zu einer geringfügigen Inferenz, die nicht unbedingt eine Bestätigungsaktion erfordert.
• Unerwartete Adresskomponente NICHT bestätigt. Unbestätigte Adresskomponenten erhöhen die Risikostufe der Adresse. Dies könnte eine Bestätigung rechtfertigen.
• Unerwartete Adresskomponente, die bestätigt WURDE. Die Komponente ist für eine korrekte Adresse nicht unbedingt erforderlich und wird von der Address Validation API aus der Ausgabe entfernt. Formatierungsprobleme erfordern im Allgemeinen keine Bestätigung.

Geringfügige Schlussfolgerungen, die bestätigt SIND

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

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 die vierstellige Erweiterung an.

Eingegebene Adresse	Region
1402 Allen St, MA 01118	USA

Urteil für fehlende Stadt

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

Wenn die Address Validation API übergeordnete Komponenten ableitet, um eine zustellbare Adresse zu generieren, können Sie mit höherer Wahrscheinlichkeit davon ausgehen, 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. Selbst in Ländern, in denen Städtenamen mehrfach vorkommen, wie z. B. Springfield in den USA, können die anderen Komponenten in Kombination mit dem Städtenamen eine eindeutige Adresse ergeben.

In unserem obigen Beispiel zeigt eine Prü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 ü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
}

Aktion: Akzeptieren. Adressen wie diese bieten genügend bestätigte Details sowie eine Bestätigung der abgeleiteten Komponenten, sodass Ihre Logik sie als gültig akzeptieren könnte, ohne dass der Kunde dazu aufgefordert werden muss.

Unerwartete Adresskomponente NICHT bestätigt

Dieses Szenario zeigt, wie wichtig es ist, zu prüfen, ob 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 entweder akzeptieren oder sie noch einmal mit dem Kunden bestätigen, je nach Risikostufe und Vertrauensniveau.

Beispielsweise kann eine Adresse 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 ist eine unbestätigte Komponente jedoch möglicherweise nicht das, was der Kunde möchte.

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

Urteil für unerwartete Adresskomponente nicht bestätigt

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

Zusätzlich zu einem Ergebnis mit unbestä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 der Unterort, der 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. An dieser Stelle können Sie die Entfernung entweder ignorieren oder bestätigen.

Unerwartete Adresskomponente, die bestätigt IST

In diesem Beispiel wird eine Grafschaft 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 How to address UK and international mail.

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

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

Urteil für unerwartete Adresskomponente, die bestätigt IST

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

Hier wird address_complete als „false“ ausgewertet und bei der Analyse der Adresskomponente wird ein unerwartetes Flag erkannt.

{
  "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. Das bedeutet, dass die Komponente der richtige Bezirk ist, in dem 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 der richtige Bezirk für die eingegebene Adresse, die Adresse selbst ist jedoch falsch formatiert. Die Address Validation API prüft auch, ob die Informationen richtig formatiert sind.

Empfohlene Maßnahme: In diesem Szenario wird empfohlen, dieses Signal zu ignorieren und die Adresse zu akzeptieren.