다시 말하지만 possibleNextAction는 주소로 배송되지 않을 수 있다는 초기 표시를 제공합니다. 또한 validationGranularity는 ROUTE입니다. 이는 거리에 일치하지만 건물에 도달하기에 충분한 정보가 없음을 나타냅니다. 또한 addressComplete 속성이 평결에서 누락되어 있으므로 false입니다. address 객체를 추가로 쿼리하면 누락된 구성요소 유형이 표시됩니다.
"missingComponentTypes": [
"street_number"
]
특이 사례 예: 수정
주소를 수정, 확인 또는 수락할지 여부는 특정 비즈니스 시나리오에 따라 다릅니다. 아래 예는 수정 카테고리에 속하지 않을 수 있는 시나리오를 보여줍니다.
확인되지 않은 번지
이 시나리오에서 Address Validation API는 제공된 번지수를 확인할 수 없지만 주소가 완전하다고 표시합니다.
여기서 street_number의 confirmation_level은 UNCONFIRMED_BUT_PLAUSIBLE로 설정됩니다. 확인되지 않음은 서비스가 데이터 세트에서 84번지 주소를 찾을 수 없음을 의미하고, 가능은 구성요소 데이터가 여전히 유효할 수 있음을 의미합니다.
하위 건물 누락
이 시나리오에서는 아파트나 부서 번호와 같은 하위 건물만 누락된 주소를 설명합니다. 그렇지 않으면 Address Validation API에서 주소를 완전히 검증할 수 있습니다. 주소 구성요소가 누락된 경우와 마찬가지로 addressComplete가 false이므로 판결의 수동 검사에는 표시되지 않습니다.
예를 들어 고객이 샌프란시스코 시 평가관 사무실의 유효한 주소를 입력했지만 입력에서 방 번호를 누락한 경우를 가정해 보겠습니다.
주소 입력됨
지역
1 Doctor Carlton B Goodlett Place, San Francisco, CA 94102
미국
누락된 하위 구역에 대한 평결
이 예시에서 평결에는 addressComplete 속성이 표시되지 않으므로 false입니다. 따라서 하나 이상의 주소 요소가 예상치 못하거나, 해결되지 않았거나, 누락되었음을 알 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-31(UTC)"],[[["\u003cp\u003eThis document provides real-world examples of when the Address Validation API signals that an address needs to be fixed.\u003c/p\u003e\n"],["\u003cp\u003eThe API provides signals such as \u003ccode\u003evalidationGranularity\u003c/code\u003e, \u003ccode\u003econfirmationLevel\u003c/code\u003e, and \u003ccode\u003emissingComponentTypes\u003c/code\u003e to indicate potential issues with an address.\u003c/p\u003e\n"],["\u003cp\u003eCommon fix scenarios include missing city/postal code, missing street number, unconfirmed street number, and missing subpremise.\u003c/p\u003e\n"],["\u003cp\u003eThe recommended action for these scenarios is typically to prompt the user for the missing or unconfirmed information.\u003c/p\u003e\n"],["\u003cp\u003eWhether to fix, confirm, or accept an address can depend on specific business needs and risk tolerance.\u003c/p\u003e\n"]]],["The Address Validation API flags addresses needing correction through response signals. Common issues include missing city/postal codes or street numbers, where the API returns unconfirmed components and suggests user prompts for missing data. Edge cases, like unconfirmed street numbers or missing subpremises, trigger `UNCONFIRMED_BUT_PLAUSIBLE` or missing `addressComplete`, respectively. These scenarios might require user confirmation, depending on delivery risk. Missing subpremises are specifically flagged in the US and prompt a request to the user.\n"],null,["This document describes a number of real-world scenarios where the\nAddress Validation API provides response signals that might warrant a *fix* behavior\nfrom your system. See\n[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 examples: fix\n\nThis section describes common examples where the Address Validation API\nprovides response signals indicating lower quality address information.\n\nMissing city and postal code\n\nThis example illustrates an entry having only the street address, with no city\nor postal code.\n\n| Address entered | Region |\n|-------------------|--------|\n| 21 45 40th street | USA |\n\nVerdict for missing city and postal code\n\nThe example below emphasizes the important signals from the response. \n\n {\n \"inputGranularity\": \"PREMISE\",\n \"validationGranularity\": \"OTHER\",\n \"geocodeGranularity\": \"OTHER\",\n \"hasUnconfirmedComponents\": true,\n \"possibleNextAction\": \"FIX\"\n }\n\nThe `possibleNextAction` provides an initial indication that the address might\nnot be deliverable. The other highlighted components also support this\npossibility, so you can query the `addressComponents` to learn more: \n\n {\n \"componentName\": {\n \"text\": \"21\",\n \"languageCode\": \"en\"\n },\n \"componentType\": \"street_number\",\n \"confirmationLevel\": \"UNCONFIRMED_BUT_PLAUSIBLE\"\n },\n {\n \"componentName\": {\n \"text\": \"45 40th street\",\n \"languageCode\": \"en\"\n },\n \"componentType\": \"route\",\n \"confirmationLevel\": \"UNCONFIRMED_BUT_PLAUSIBLE\"\n },\n {\n \"componentName\": {\n \"text\": \"United States\",\n \"languageCode\": \"en\"\n },\n \"componentType\": \"country\",\n \"confirmationLevel\": \"CONFIRMED\"\n }\n\nThe Address Validation API returns only the country (United States) as `CONFIRMED`.\nIt returns all other address components as `UNCONFIRMED_BUT_PLAUSIBLE`, with\nsome important omissions to the data, such as locality and postal code.\n| **Action:** For this address, you might prompt your user for the missing information.\n\nMissing street number\n\nThis example shows a missing street number.\n\n| Address entered | Region |\n|-----------------------------------------|--------|\n| Buckingham Palace Road, SW1W 9TQ London | UK |\n\nVerdict for missing street number \n\n {\n \"inputGranularity\": \"PREMISE_PROXIMITY\",\n \"validationGranularity\": \"ROUTE\",\n \"geocodeGranularity\": \"ROUTE\",\n \"possibleNextAction\": \"FIX\"\n }\n\nOnce again, the `possibleNextAction` provides an initial indication that the\naddress might not be deliverable. Furthermore, the `validationGranularity` is\n`ROUTE`, which indicates a match to the street, but not enough information to\nget to the premise. Additionally, the `addressComplete` property is missing from\nthe verdict, and therefore it is `false`. A further query of the `address`\nobject reveals a missing component type: \n\n \"missingComponentTypes\": [\n \"street_number\"\n ]\n\n| **Action:** For this address, you might prompt your user for the missing information.\n\nEdge-case examples: fix\n\nIn some situations, whether you fix, confirm, or accept an address\ndepends on your particular business scenario. The examples below illustrate\nscenarios that might not strictly fall into a fix category.\n\nUnconfirmed street number\n\nIn this scenario, the Address Validation API cannot confirm the supplied street\nnumber, yet it indicates that the address is complete.\n\n| Address entered | Region |\n|---------------------------------------------|--------|\n| 84 Buckingham Palace Road, SW1W 9TQ, London | UK |\n\nVerdict for unconfirmed street number\n\nThe example below emphasizes the important signals. \n\n {\n \"inputGranularity\": \"PREMISE\",\n \"validationGranularity\": \"PREMISE_PROXIMITY\",\n \"geocodeGranularity\": \"PREMISE_PROXIMITY\",\n \"addressComplete\" : true,\n \"hasUnconfirmedComponents\": true,\n \"possibleNextAction\": \"ACCEPT\"\n }\n\nIt's worth investigating the combination of a validation granularity only to\npremise-level approximation along with unconfirmed components. A query of the\n`addressComponents` property shows the following unconfirmed `componentType`: \n\n {\n \"componentName\": {\n \"text\": \"84\",\n \"languageCode\": \"en\"\n },\n \"componentType\": \"street_number\",\n \"confirmationLevel\": \"UNCONFIRMED_BUT_PLAUSIBLE\"\n }\n\nHere, the `confirmation_level` of the `street_number` is set to\n`UNCONFIRMED_BUT_PLAUSIBLE`. *Unconfirmed* means that the service cannot match\nthe street number of 84 in its dataset, and *plausible* means that the\ncomponent data could still be valid.\n| **Action:** You can either accept the input as entered, or confirm with the customer to determine if the street number entered was intended or an error. Your response depends on the level of risk associated with your delivery. See [Implementation guidance](/maps/documentation/address-validation/build-validation-logic#implementation_guidance) in **Build your validation logic**.\n\nMissing subpremise\n\nThis scenario describes an address that is only missing a subpremise, such as an\napartment or department number. Otherwise, the Address Validation API can fully\nvalidate the address. As is the case when any address component is missing, the\nthe `addressComplete` is `false` and therefore not present on manual inspection\nof the verdict.\n| **Note:** In some countries, the Address Validation API cannot detect a missing subpremise; while in the US, a missing `SUB_PREMISE` indicates a non-deliverable address.\n\nTo illustrate, suppose a customer enters a valid address for the San Francisco\ncity assessor's office, but misses the room number from the input.\n\n| Address entered | Region |\n|------------------------------------------------------------|--------|\n| 1 Doctor Carlton B Goodlett Place, San Francisco, CA 94102 | USA |\n\nVerdict for missing subpremise\n\nIn this example, the verdict does not display the `addressComplete` property, so\ntherefore it is `false`. Because of this, you know that at least one address\nelement is unexpected, unresolved, or missing. \n\n {\n \"inputGranularity\": \"PREMISE\",\n \"validationGranularity\": \"PREMISE\",\n \"geocodeGranularity\": \"PREMISE\",\n \"hasInferredComponents\": true,\n \"possibleNextAction\": \"CONFIRM_ADD_SUBPREMISES\"\n }\n\nAn `address` query reveals the following: \n\n \"missingComponentTypes\": [\n \"subpremise\"\n ]\n\nUpon further inquiry, the USPS data provides a `dpvConfirmation` code of\n`D`, which also indicates a missing subpremise.\n| **Action:** For this address, you might prompt your user for the missing information."]]
