Adresse bestätigen – Beispiele

In diesem Dokument werden eine Reihe von realen Szenarien beschrieben, in denen die Address Validation API Antwortsignale für Adressen liefert, die in Ihrem System möglicherweise das Verhalten confirm rechtfertigen. Beispielworkflows im Abschnitt Validierungslogik erstellen

Häufige 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 geben sie jedoch versehentlich Seattle ein.

Ergebnis für ersetzte Daten

Im folgenden Beispiel werden die wichtigen Signale aus der Antwort hervorgehoben.

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

Die possibleNextAction ist ein erster Hinweis darauf, dass es sich lohnen könnte, die Adresse mit dem Kunden zu bestätigen. Die anderen Signale im Ergebnis liefern weitere Details dazu, was mit der Adresse nicht stimmen könnte. Die PREMISE_PROXIMITY gibt die Annäherung einer Adresse auf Gebäudeebene an, ist aber nicht so detailliert wie SUB_PREMISE, die die auf der Eingabeebene bereitgestellte Granularität ist. Die Antwort enthält auch nicht bestätigte und ersetzte Komponenten.

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 in Seattle gefunden und die Postleitzahl, eine Komponente auf höherer Ebene, durch eine Adresse in Seattle ersetzt. Das könnte ein gültiger Ersatz sein, aber da die Komponenten nicht bestätigt wurden, ist es sinnvoll, sicherzustellen, dass der Nutzer eine Adresse in Seattle und nicht etwa in Kirkland eingeben möchte.

Grenzfälle – Beispiele: Bestätigen

Die folgenden Beispiele veranschaulichen die folgenden Sonderfalltypen:

• Geringfügige Schlussfolgerungen, die BESTÄTIGT werden: Bei der Address Validation API wird entweder das Land, die Postleitzahl oder das Bundesland abgeleitet. Alle anderen Angaben werden sowohl bereitgestellt als auch bestätigt. Durch die Kombination aus Granularität und Bestätigungsstufe ist es möglich, dass für eine untergeordnete Schlussfolgerung keine Bestätigung erforderlich ist.
• Unerwartete Adresskomponente NICHT bestätigt: Nicht bestätigte Adresskomponenten erhöhen das Risikoniveau der Adresse. Möglicherweise ist eine Bestätigung erforderlich.
• 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.

Geringfügige Schlussfolgerungen, die BESTÄTIGT werden

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

• Stadt
• Status
• Postleitzahl
• Land

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

Entscheidung bei fehlender Stadt

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

Wenn die Address Validation API Komponenten auf höherer Ebene ableitet, um eine zustellbare Adresse zu generieren, 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 repräsentieren, leichter mit bestätigten Adresskomponenten abgeglichen werden können, die detaillierter sind. Selbst 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.

Wenn wir unser Beispiel oben verwenden, sehen wir, dass bei einem Scan aller Adresskomponenten jede Komponente bestätigt wird. 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
}

Unerwartete Adresskomponente NICHT bestätigt

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 noch einmal mit dem Kunden bestätigen, je nach Risikostufe und Vertrauensniveau.

Eine Adresse stammt beispielsweise aus einer Region, 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 den Anforderungen des Kunden.

Entscheidung für unerwartete Adresskomponente nicht bestätigt

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

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

"formattedAddress": "59 Cherrydown Avenue, London E4 8DT, UK",

Ein Scan nach nicht bestätigten Komponenten zeigt, dass die API Chingford aus der zurückgegebenen Adresse entfernt hat:

{
  "componentName": {
    "text": "Chingford",
    "languageCode": "en"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

Unerwartete Adresskomponente, die BESTÄTIGT ist

In diesem Beispiel wird eine britische Grafschaft in die angegebene Adresse aufgenommen, was üblich 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 bewertet.

Entscheidung für unerwartete Adresskomponente, die bestätigt WIRD

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

Hier ergibt address_complete den Wert „false“ und eine Analyse der Adresskomponente zeigt ein unerwartetes Flag.

{
  "componentName": {
    "text": "Gloucestershire",
    "languageCode": "en"
  },
  "componentType": "administrative_area_level_2",
  "confirmationLevel": "CONFIRMED",
  "unexpected": true
}

Gloucestershire ist zwar die richtige Grafschaft 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.