Untergeordneten Standort zur Adresse hinzufügen – Beispiele (nur USA)
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
In diesem Dokument werden eine Reihe von realen Szenarien beschrieben, in denen die Address Validation API Antwortsignale liefert, die ein add subpremises-Verhalten Ihres Systems rechtfertigen. Diese Signale sind nur für US-Adressen verfügbar.
Beispielworkflows im Abschnitt Validierungslogik erstellen
Häufiges Beispiel: Unteradressen hinzufügen
In diesem Szenario wird eine Adresse veranschaulicht, bei der Ihr System einen Kunden möglicherweise auffordert, der Adresse eine Einheitsnummer hinzuzufügen.
Eingegebene Adresse
Region
1450 Brickell Avenue, Miami, FL 33131-4065, USA
USA
Entscheidung für eine Adresse ohne untergeordnete Räumlichkeiten
Im folgenden Beispiel wird das wichtige Signal hervorgehoben.
Beispiel für einen Grenzfall: Untergeordnete Räumlichkeiten hinzufügen
Im folgenden Beispiel wird eine Situation beschrieben, in der verdict auf Probleme mit der Adressqualität hinweist, die weitere Untersuchungen erfordern. Dieses Beispiel veranschaulicht auch, wie Sie Ihre Logik vom Ergebnis zu den Adresskomponenten übertragen können, um ein umfassenderes Bild zu erhalten und Ihre Systemlogik zu verbessern.
Fehlende untergeordnete Prämissen und abgeleitete und ersetzte Komponenten
In diesem Beispiel wird die Eingabe einer US-Adresse mit einem fehlenden Ort und einer falschen Postleitzahl veranschaulicht.
Eingegebene Adresse
Region
1450 Brickell Avenue, FL 33132-4065
USA
Ergebnis für eine fehlende untergeordnete Prämisse und abgeleitete und ersetzte Komponenten
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-31 (UTC)."],[],[],null,["This document describes a number of real-world scenarios where the\nAddress Validation API provides response signals that warrant an *add subpremises*\nbehavior from your system. These signals are only available for US addresses.\nSee [Example workflows](/maps/documentation/address-validation/build-validation-logic#example-workflows) in\n**Build your validation logic** for context.\n| **Note:** The examples here are illustrative, but don't cover all scenarios.\n\nCommon example: add subpremises\n\nThis scenario illustrates an address in which your system might prompt a\ncustomer to add a unit number to the address.\n\n| Address entered | Region |\n|--------------------------------------------|--------|\n| 1450 Brickell Avenue, Miami, FL 33131-4065 | US |\n\nVerdict for an address missing a subpremises\n\nThe example below highlights the important signal. \n\n {\n \"inputGranularity\": \"PREMISE\",\n \"validationGranularity\": \"PREMISE\",\n \"geocodeGranularity\": \"PREMISE\",\n \"possibleNextAction\": \"CONFIRM_ADD_SUBPREMISES\"\n }\n\n| **Action:** For this address, you might prompt your user to add a unit number.\n\nEdge case example: add subpremises\n\nThe following example covers a situation in which the `verdict` indicates\naddress quality issues that warrant further investigation. This examples also\nillustrates how your logic can travel from the verdict to the address components\nto obtain a more complete picture in order to enhance your system logic.\n\nMissing subpremises and inferred and replaced components\n\nThis example illustrates entry of a US address with a missing locality and an\nincorrect postal code.\n\n| Address entered | Region |\n|-------------------------------------|--------|\n| 1450 Brickell Avenue, FL 33132-4065 | US |\n\nVerdict for a missing subpremises and inferred and replaced components \n\n {\n \"inputGranularity\": \"PREMISE\",\n \"validationGranularity\": \"PREMISE\",\n \"geocodeGranularity\": \"PREMISE\",\n \"hasInferredComponents\": true,\n \"hasReplacedComponents\": true,\n \"possibleNextAction\": \"CONFIRM_ADD_SUBPREMISES\"\n }\n\nFurther investigation of the address components reveals that the locality has\nbeen inferred, and the postal code has been replaced. \n\n {\n \"componentName\": {\n \"text\": \"33131\",\n }\n \"componentType\": \"postal_code\",\n \"confirmationLevel\": \"CONFIRMED\",\n \"replaced\": true\n },\n {\n \"componentName\": {\n \"text\": \"Miami\",\n \"languageCode\": \"en\"\n }\n \"componentType\": \"locality\",\n \"confirmationLevel\": \"CONFIRMED\",\n \"inferred\": true\n }\n\n| **Action:** For this address, you might prompt your user to add a unit number, or prompt them to review the entire address."]]
