Popraw adres – przykłady

W tym dokumencie opisujemy kilka rzeczywistych scenariuszy, w których interfejs Address Validation API zwraca sygnały odpowiedzi, które mogą wymagać poprawki w działaniu systemu. Więcej informacji znajdziesz w sekcji Przykładowe przepływy pracy w artykule Tworzenie logiki weryfikacji.

Typowe przykłady: poprawka

W tej sekcji opisujemy typowe przykłady, w których interfejs Address Validation API zwraca sygnały odpowiedzi wskazujące na niższą jakość informacji o adresie.

Brak miasta i kodu pocztowego

Ten przykład ilustruje wpis zawierający tylko adres ulicy, bez miasta ani kodu pocztowego.

Decyzja w sprawie braku miasta i kodu pocztowego

Przykład poniżej podkreśla ważne sygnały z odpowiedzi.

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true,
  "possibleNextAction": "FIX"
}

possibleNextAction wskazuje, że dostarczenie pod ten adres może być niemożliwe. Pozostałe wyróżnione komponenty również obsługują tę możliwość, więc możesz wysłać zapytanie do addressComponents, aby dowiedzieć się więcej:

{
  "componentName": {
    "text": "21",
    "languageCode": "en"
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
  "componentName": {
    "text": "45 40th street",
    "languageCode": "en"
  },
  "componentType": "route",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
  "componentName": {
    "text": "United States",
    "languageCode": "en"
  },
  "componentType": "country",
  "confirmationLevel": "CONFIRMED"
}

Address Validation API zwraca tylko kraj (Stany Zjednoczone) jako CONFIRMED. Zwraca wszystkie inne komponenty adresu jako UNCONFIRMED_BUT_PLAUSIBLE, z ważnymi pominięciami w danych, takimi jak miejscowość i kod pocztowy.

Brak numeru domu

W tym przykładzie brakuje numeru domu.

Werdykt dotyczący braku numeru domu

{
    "inputGranularity": "PREMISE_PROXIMITY",
    "validationGranularity": "ROUTE",
    "geocodeGranularity": "ROUTE",
    "possibleNextAction": "FIX"
}

Po raz kolejny symbol possibleNextAction wskazuje, że adres może być nieprawidłowy. Ponadto validationGranularity jest ROUTE, co oznacza dopasowanie do ulicy, ale nie ma wystarczających informacji, aby dotrzeć do lokalu. Dodatkowo w werdykcie brakuje właściwości addressComplete, więc jest ona false. Dalsze zapytanie dotyczące obiektu address ujawnia brakujący typ komponentu:

"missingComponentTypes": [
        "street_number"
      ]

Przykłady przypadków granicznych: poprawki

W niektórych sytuacjach to, czy poprawisz, potwierdzisz czy zaakceptujesz adres, zależy od konkretnego scenariusza biznesowego. Przykłady poniżej ilustrują sytuacje, które niekoniecznie należą do żadnej z kategorii poprawek.

Niepotwierdzony numer domu

W tym przypadku interfejs Address Validation API nie może potwierdzić podanego numeru ulicy, ale wskazuje, że adres jest kompletny.

Werdykt w przypadku niepotwierdzonego numeru ulicy

W przykładzie poniżej podkreślono ważne sygnały.

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete" : true,
  "hasUnconfirmedComponents": true,
  "possibleNextAction": "ACCEPT"
}

Warto sprawdzić połączenie szczegółowości weryfikacji tylko z przybliżeniem na poziomie lokalu z niepotwierdzonymi komponentami. Zapytanie dotyczące właściwości addressComponents pokazuje te niepotwierdzone componentType:

{
  "componentName": {
    "text": "84",
    "languageCode": "en"
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
}

W tym przypadku confirmation_level street_number jest ustawiona na UNCONFIRMED_BUT_PLAUSIBLE. Niepotwierdzony oznacza, że usługa nie może dopasować numeru domu 84 w swoim zbiorze danych, a prawdopodobny oznacza, że dane komponentu mogą być nadal prawidłowe.

Brak podlokalizacji

Ten scenariusz opisuje adres, w którym brakuje tylko podrzędnego elementu adresu, np. numeru mieszkania lub działu. W przeciwnym razie interfejs Address Validation API może w pełni zweryfikować adres. Podobnie jak w przypadku braku dowolnego komponentu adresu, wartość addressComplete to false, więc nie jest ona widoczna podczas ręcznego sprawdzania oceny.

Załóżmy, że klient wpisuje prawidłowy adres biura rzeczoznawcy w San Francisco, ale pomija numer pokoju.

Decyzja w sprawie braku lokalu

W tym przykładzie wynik nie zawiera właściwości addressComplete, więc jest false. Dzięki temu wiesz, że co najmniej 1 element adresu jest nieoczekiwany, nierozwiązany lub nie występuje.

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

Zapytanie address ujawnia te informacje:

"missingComponentTypes": [
        "subpremise"
      ]

Po dalszym sprawdzeniu danych USPS okazuje się, że kod dpvConfirmationD również wskazuje na brak podrzędnego lokalu.