Potwierdź adres – przykłady

W tym dokumencie opisano kilka rzeczywistych scenariuszy, w których interfejs Address Validation API dostarcza sygnały odpowiedzi dla adresów, które wymagają od systemu zachowania potwierdzenia. Poniższe przykłady mają charakter poglądowy i nie są wyczerpujące. Aby dowiedzieć się więcej, zapoznaj się z omówieniem przepływu pracy w sekcji Tworzenie logiki weryfikacji.

Typowe przykłady: potwierdzenie

Poniższy przykład ilustruje przypadek obszarów metropolitalnych z podobnymi nazwami ulic. Załóżmy, że użytkownik chce wpisać adres budynku D Google w Kirkland w stanie Waszyngton w Stanach Zjednoczonych. Jednak zamiast miasta Kirkland przez pomyłkę wpisuje Seattle.

Wpisany adres Region
Building D, 451 7th Avenue South, Seattle, WA 98033, USA US

Werdykt dotyczący zastąpionych danych

W przykładzie poniżej wyróżniono ważne sygnały z werdyktu.

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

Poziom szczegółowości PREMISE_PROXIMITY wskazuje przybliżony adres na poziomie budynku, ale nie jest tak szczegółowy jak SUB_PREMISE, czyli poziom szczegółowości podany w danych wejściowych. Odpowiedź zawiera też zarówno niepotwierdzone, jak i zastąpione komponenty, więc kombinacja ta kwalifikuje się do kategorii potwierdzone.

Zapytanie dotyczące komponentów adresu ujawnia te obszary problematyczne:

{
  "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"
    ]

W tym przypadku interfejs Address Validation API znalazł adres zbliżony do podanego w Seattle i zastąpił kod pocztowy, czyli komponent wyższego poziomu, aby dopasować go do adresu w Seattle. Może to być prawidłowy zamiennik, ale biorąc pod uwagę fakt, że komponenty nie zostały potwierdzone, warto upewnić się, że użytkownik zamierza wpisać adres w Seattle, a nie w innym miejscu, np. w Kirkland.

Przykłady przypadków skrajnych: potwierdzenie

Poniższe przykłady ilustrują te typy przypadków skrajnych:

Drobne wnioski, które SĄ potwierdzone

W połączeniu z potwierdzonymi danymi o bardziej szczegółowym poziomie interfejs API może nadal wyciągnąć prawidłowe wnioski, jeśli w danych wejściowych brakuje tylko jednego komponentu następujących typów:

  • Miasto
  • Stan
  • Kod pocztowy
  • Kraj

Na przykład klient podaje prawidłowy adres ulicy restauracji McDonald's w Springfield w stanie Massachusetts, ale zapomina wpisać miasto i podaje kod pocztowy bez 4-cyfrowego rozszerzenia.

Wpisany adres Region
1402 Allen St, MA 01118 US

Werdykt dotyczący brakującego miasta

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

W sytuacjach, gdy interfejs Address Validation API wnioskuje o komponentach wyższego poziomu w celu wygenerowania adresu dostawy, możesz mieć większą pewność, że dane z systemu są prawidłowe. Dzieje się tak, ponieważ komponenty wywnioskowane, które reprezentują szeroki region geograficzny, są łatwiej dopasowywane do potwierdzonych komponentów adresu, które są bardziej szczegółowe. Nawet w krajach, w których nazwy miast się powtarzają, np. Springfield w Stanach Zjednoczonych, inne elementy w połączeniu z nazwą miasta mogą tworzyć unikalny adres.

W naszym przykładzie skanowanie wszystkich komponentów adresu pokazuje, że każdy z nich jest potwierdzony, co oznacza, że jest zgodny z danymi przechowywanymi przez interfejs Address Validation API, a usługa wnioskuje też o 2 komponentach wyższego poziomu.

{
  "componentName": {
    "text": "Springfield",
    "languageCode": "en"
  },
  "componentType": "locality",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
},
{
  "componentName": {
    "text": "1806"
  },
  "componentType": "postal_code_suffix",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
}

Nieoczekiwany komponent adresu NIE został potwierdzony

Ten scenariusz pokazuje, jak ważne jest sprawdzanie, kiedy komponenty nie są potwierdzone. Jeśli komponent adresu jest nieoczekiwany, interfejs Address Validation API usuwa go z danych wyjściowych. W takich przypadkach możesz zaakceptować adres lub poprosić klienta o jego ponowne potwierdzenie, w zależności od poziomu ryzyka i pewności.

Na przykład adres może pochodzić z regionu, w którym klienci często wpisują nieszkodliwe informacje ignorowane przez urząd pocztowy. W takim przypadku możesz zaakceptować adres. Jednak w niektórych przypadkach niepotwierdzony komponent może nie być tym, czego chce klient.

Wpisany adres Region
1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry, Francja Francja

Nie potwierdzono werdyktu dotyczącego nieoczekiwanego komponentu adresu

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

Oprócz werdyktu z niepotwierdzonymi komponentami interfejs Address Validation API zwraca ten sformatowany adres:

"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",

Skanowanie w poszukiwaniu niepotwierdzonych komponentów pokazuje, że interfejs API usunął la caritat 2 ze zwróconego adresu:

{
  "componentName": {
    "text": "la caritat 2",
    "languageCode": "fr"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

Nieoczekiwany komponent adresu, który JEST potwierdzony

Ten przykład ilustruje uwzględnienie hrabstwa w Wielkiej Brytanii w podanym adresie, co jest powszechną praktyką. Nie jest to jednak wymagane przez brytyjski urząd pocztowy i jest zasadniczo ignorowane. Zobacz postoffice.co.uk i How to address UK and international mail.

W związku z tym, gdy klient podaje hrabstwo w adresie w Wielkiej Brytanii, usługa ocenia to jako nieoczekiwane dane wejściowe.

Wpisany adres Region
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP Wielka Brytania

Werdykt dotyczący nieoczekiwanego komponentu adresu, który JEST potwierdzony

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

W tym przypadku address_complete ma wartość false, a analiza komponentu adresu ujawnia nieoczekiwaną flagę.

{
  "componentName": {
    "text": "Gloucestershire",
    "languageCode": "en"
  },
  "componentType": "administrative_area_level_2",
  "confirmationLevel": "CONFIRMED",
  "unexpected": true
}

Gloucestershire jest prawidłowym hrabstwem dla podanego adresu, ale sam adres jest nieprawidłowo sformatowany. Pamiętaj, że interfejs Address Validation API ocenia też informacje pod kątem prawidłowego formatowania.