Adresse bestätigen – Beispiele

In diesem Dokument wird eine Reihe von realen Szenarien beschrieben, in denen die Address Validation API Antwortsignale für Adressen bereitstellt, die eine Bestätigung Ihres Systems erfordern. Weitere Informationen finden Sie unter Workflowübersicht im Artikel Validierungslogik erstellen.

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

Gängige Beispiele: bestätigen

Das folgende Beispiel zeigt Großräume mit ähnlichen Straßennamen. Angenommen, ein Nutzer möchte die Adresse für Google-Gebäude D in Kirkland, Washington, USA eingeben. Statt Kirkland als Stadt geben sie jedoch versehentlich Seattle ein.

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

Ergebnis für ersetzte Daten

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

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

Der PREMISE_PROXIMITY gibt die Nähe einer Adresse auf Gebäudeebene an, ist jedoch nicht so detailliert wie SUB_PREMISE. Dies ist der bei der Eingabe angegebene Detaillierungsgrad. Die Antwort enthält auch sowohl nicht bestätigte als auch ersetzte Komponenten, sodass die Kombination dies in die Kategorie confirm übernimmt.

Eine Abfrage der Adresskomponenten zeigt die folgenden Problembereiche an:

{
  "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 enge Annäherung an die angegebene Adresse in Seattle gefunden und die Postleitzahl, eine übergeordnete Komponente, ersetzt und in eine Seattle-Adresse aufgelöst. Dies könnte ein gültiger Ersatz sein, aber aufgrund der Tatsache, dass die Komponenten nicht bestätigt wurden, ist es sinnvoll, dafür zu sorgen, dass der Nutzer eine Adresse in Seattle eingeben möchte und nichts anderes, wie beispielsweise Kirkland.

Tipp :Prüfen Sie die richtige Adresse in der Demo und verwenden Sie 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.

Grenzfall-Beispiele: bestätigen

Die folgenden Beispiele veranschaulichen die folgenden Grenzfalltypen:

• Kleinere Inferenzen, die durch ARE bestätigt wurden. Die Address Validation API leitet entweder das Land, die Postleitzahl oder den Bundesstaat ab, alles andere wird jedoch angegeben und bestätigt. Die Kombination aus Detaillierungsgrad und Bestätigungsstufe sorgt dafür, dass für eine geringfügige Inferenz keine Bestätigungsaktion erforderlich ist.
• Unerwartete Adresskomponente NICHT bestätigt. Nicht bestätigte Adresskomponenten werden zur Risikostufe der Adresse hinzugefügt. Dies könnte eine Bestätigung erfordern.
• Unerwartete Adresskomponente, die IST bestätigt: Die Komponente ist für eine korrekte Adresse nicht unbedingt erforderlich und die Address Validation API entfernt sie aus der Ausgabe. Bei Formatierungsproblemen ist im Allgemeinen keine Bestätigung erforderlich.

Geringfügige Rückschlüsse, die ARE bestätigt haben

In Kombination mit bestätigten Daten detaillierterer Ebene kann die API trotzdem eine korrekte Ableitung erstellen, falls in der Eingabe nur eine Komponente der folgenden Typen fehlt:

• Stadt
• Status
• 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 vierstellige Erweiterung an.

Eingegebene Adresse	Region
1402 Allen St, MA 01118, USA	USA

Urteil wegen fehlender Stadt

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

In Situationen, in denen die Address Validation API übergeordnete Komponenten ableitet, um eine Lieferadresse zu generieren, können Sie mit größerer Sicherheit darauf vertrauen, dass die Daten aus dem System korrekt sind. Dies liegt daran, dass abgeleitete Komponenten, die eine breite geografische Region repräsentieren, leichter mit bestätigten Adresskomponenten abgeglichen werden, 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 damit eine eindeutige Adresse liefern.

Im obigen Beispiel zeigt ein Scan aller Adresskomponenten, dass jede Komponente bestätigt ist, was 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 einen ausreichenden bestätigten Detaillierungsgrad sowie eine Bestätigung abgeleiteter Komponenten, dass Ihre Logik diese als gültig akzeptieren könnte, ohne den Kunden danach fragen zu müssen.

Unerwartete Adresskomponente NICHT bestätigt

Dieses Szenario verdeutlicht, wie wichtig es ist, zu überprüfen, wenn 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 dem Kunden noch einmal bestätigen, je nach Risikoniveau und Konfidenzniveau.

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

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

Ergebnis für unerwartete Adresskomponente nicht bestätigt

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

Zusätzlich zum Ergebnis 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 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 der Unterortsteil, 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, dies mit dem Kunden abzuklären. An dieser Stelle ignorieren Sie das Entfernen oder bestätigen es.

Unerwartete Adresskomponente, die IST bestätigt

Dieses Beispiel zeigt, dass ein County im Vereinigten Königreich in die angegebene Adresse aufgenommen wird, was eine 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 unter E-Mail-Adresse im Vereinigten Königreich und Ausland.

Wenn ein Kunde einen Landkreis mit einer Adresse im Vereinigten Königreich angibt, wertet der Dienst dies als unerwartete Eingabe aus.

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

Ergebnis für unerwartete Adresskomponente, das IST bestätigt

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

Hier wird address_complete als falsch ausgewertet 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:

• Die Daten wurden als korrekt bestätigt. Damit wird angegeben, dass die Komponente der richtige Landkreis ist, der die Adresse enthält.
• Unerwartete Eingabe: Gibt an, dass eine Komponente für die korrekte Formatierung der Adresse nicht erforderlich ist.

Obwohl Gloucestershire der richtige Landkreis für die eingegebene Adresse ist, ist die Adresse selbst nicht richtig formatiert. Denken Sie daran, dass die Address Validation API Informationen auch auf ihre korrekte Formatierung auswertet.

Maßnahme:Für dieses Szenario wird empfohlen, dieses Signal zu ignorieren und die Adresse zu akzeptieren.