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 in Ihrem System das Verhalten bestätigen erfordern. Die Beispiele hier dienen zur 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 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. Statt 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 zu 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 wird sie der Kategorie bestätigen zugeordnet.

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 wie die angegebene Adresse in Seattle gefunden und die Postleitzahl, eine Komponente auf höherer Ebene, ersetzt, um eine Adresse in Seattle zu erhalten. Dies kann ein gültiger Ersatz sein. Da jedoch Komponenten nicht bestätigt wurden, ist es sinnvoll, zu prüfen, ob der Nutzer tatsächlich eine Adresse in Seattle eingeben möchte und nicht etwas anderes, z. B. Kirkland.

Tipp: Prüfen Sie die richtige Adresse in der Demo, verwenden Sie 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 wurden. Die Address Validation API leitet entweder das Land, die Postleitzahl oder das Bundesland ab. Alles andere wird sowohl angegeben als auch bestätigt. Die Kombination aus Granularität und Bestätigungsstufe führt zu einer geringfügigen Schlussfolgerung, die nicht unbedingt eine Bestätigungsaktion erfordert.
• Unerwartete Adresskomponente, die NICHT bestätigt wurde. Nicht bestätigte Adresskomponenten erhöhen das Risikoniveau der Adresse. In diesem Fall ist möglicherweise eine Bestätigung erforderlich.
• 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 in der Regel keine Bestätigung.

Geringfügige Schlussfolgerungen, die bestätigt wurden

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 mit dem Städtenamen eine eindeutige Adresse ergeben.

In unserem Beispiel zeigt eine Überprüfung aller Adresskomponenten, dass jede Komponente bestätigt wurde. 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, sie zu bestätigen.

Unerwartete Adresskomponente, die NICHT bestätigt wurde

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 vom Kunden bestätigen lassen, 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 wurde

{
  "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 wurden, ist es sinnvoll, sie vom Kunden bestätigen zu lassen. An diesem Punkt können Sie das Entfernen entweder ignorieren oder bestätigen.

Unerwartete Adresskomponente, die bestätigt wurde

Dieses Beispiel veranschaulicht die Aufnahme 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 wurde

{
   "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 korrekte 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.