Adresse bestätigen – Beispiele

Dieses Produkt oder diese Funktion ist eine Vorabversion (pre-GA). Pre-GA-Produkte und ‑Features werden eventuell nur eingeschränkt unterstützt. Außerdem sind Änderungen an diesen Produkten und Features möglicherweise nicht mit anderen pre-GA-Versionen kompatibel. Pre-GA-Angebote sind durch die dienstspezifischen Nutzungsbedingungen für die Google Maps Platform abgedeckt. Weitere Informationen finden Sie in den Beschreibungen der Einführungsphasen.

In diesem Dokument werden eine Reihe von realen Szenarien beschrieben, in denen die Address Validation API Antwortsignale für Adressen liefert, die ein confirm-Verhalten Ihres Systems rechtfertigen. 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.

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.

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 Urteil hervorgehoben.

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

Die PREMISE_PROXIMITY-Granularität gibt die Näherung einer Adresse auf Gebäudeebene an, ist aber nicht so detailliert wie SUB_PREMISE, die bei der Eingabe angegeben wird. Die Antwort enthält auch nicht bestätigte und ersetzte Komponenten. Daher fällt die Kombination in die Kategorie confirm.

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, ersetzt, um eine Adresse in Seattle zu erhalten. Das könnte ein gültiger Ersatz sein. Da aber auch die Komponenten nicht bestätigt wurden, ist es sinnvoll, den Nutzer zu fragen, ob er wirklich eine Adresse in Seattle und nicht etwa in Kirkland eingeben möchte.

Tipp :Die korrekte Adresse finden Sie in der Demo. Verwenden Sie 451 7th Avenue South, Kirkland, WA 98033, um die Antwort für die ursprünglich vorgesehene Adresse zu sehen.

Aktion:Bestätigen Sie die Adresseingabe mit dem Kunden.

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.

Eingegebene Adresse	Region
1402 Allen St, MA 01118	USA

Entscheidung bei fehlender Stadt

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

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
}

Aktion:Akzeptieren. Adressen wie diese bieten genügend bestätigte Granularität sowie eine Bestätigung der abgeleiteten Komponenten, sodass Ihre Logik sie als gültig akzeptieren könnte, ohne den Kunden aufzufordern, sie zu bestätigen.

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.

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 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 Unterlokalität, die auf ein Wohngebiet oder ein Viertel hinweisen 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 abzuklären. An diesem Punkt können Sie die Entfernung entweder ignorieren oder bestätigen.

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.

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

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

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

Hier ergibt address_complete den Wert „false“ 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. Das bedeutet Folgendes:

• Als korrekte Daten bestätigt: Dies weist darauf hin, dass die Komponente das richtige County ist, in dem sich die Adresse befindet.
• Unerwartet als Eingabe. Gibt eine Komponente an, die für die richtige Formatierung der Adresse nicht erforderlich ist.

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.

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