Potwierdź adres – przykłady

W tym dokumencie opisujemy kilka rzeczywistych scenariuszy, w których interfejs Address Validation API zwraca sygnały odpowiedzi dotyczące adresów wymagających od systemu zachowania confirm. Przykłady są ilustracyjne, ale nie wyczerpujące. Więcej informacji znajdziesz w sekcji Omówienie przepływu pracy w artykule Tworzenie logiki weryfikacji.

Typowe przykłady: confirm

Poniższy przykład ilustruje przypadek obszarów metropolitalnych o podobnych nazwach ulic. Załóżmy, że użytkownik chce wpisać adres budynku D Google w Kirkland w stanie Waszyngton w Stanach Zjednoczonych. Zamiast Kirkland jako miasta przypadkowo wpisuje Seattle.

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

Werdykt dotyczący zastąpionych danych

Poniższy przykład podkreśla ważne sygnały z werdyktu.

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

Poziom PREMISE_PROXIMITY szczegółowości wskazuje przybliżenie adresu 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ż komponenty niepotwierdzone i zastąpione, więc ich połączenie powoduje, że adres kwalifikuje się do kategorii confirm.

Zapytanie o komponenty adresu ujawnia te obszary problemowe:

{
  "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ł przybliżony adres do podanego adresu w Seattle i zastąpił kod pocztowy, czyli komponent wyższego poziomu , aby uzyskać adres w Seattle. Może to być prawidłowe zastąpienie, ale wraz z faktem, że komponenty nie zostały potwierdzone, warto upewnić się, że użytkownik chce wpisać adres w Seattle, a nie np. w Kirkland.

Przykłady przypadków brzegowych: confirm

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

Drobne wnioski, które zostały potwierdzone

W połączeniu z potwierdzonymi danymi o większej szczegółowości interfejs API może nadal wyciągać prawidłowe wnioski, jeśli w danych wejściowych brakuje tylko 1 komponentu z tych 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 komponenty wyższego poziomu, aby uzyskać adres dostawy, możesz mieć większą pewność, że dane z systemu są prawidłowe. Wynika to z faktu, że wnioskowane komponenty, które reprezentują duży region geograficzny, są łatwiej dopasowywane do potwierdzonych komponentów adresu o większej szczegółowości. Nawet w krajach, w których nazwy miast się powtarzają, np. w Stanach Zjednoczonych, inne komponenty w połączeniu z nimi mogą tworzyć unikalny adres.

W naszym przykładzie skan wszystkich komponentów adresu pokazuje, że każdy komponent jest potwierdzony, co oznacza, że pasuje do danych przechowywanych przez interfejs Address Validation API, a usługa wnioskuje też 2 komponenty 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, który NIE został potwierdzony

Ten scenariusz ilustruje, 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 ponownie potwierdzić go z klientem, w zależności od poziomu ryzyka i poziomu ufności.

Na przykład adres może pochodzić z regionu, w którym klienci często wpisują nieszkodliwe informacje ignorowane przez pocztę. W takim przypadku zaakceptujesz adres. W niektórych przypadkach niepotwierdzony komponent może jednak nie być tym, czego oczekuje klient.

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

Werdykt dotyczący nieoczekiwanego komponentu adresu, który nie został potwierdzony

{
  "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ął z zwróconego adresu la caritat 2:

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

Nieoczekiwany komponent adresu, który został potwierdzony

Ten przykład ilustruje uwzględnienie w podanym adresie hrabstwa w Wielkiej Brytanii, co jest powszechną praktyką. Nie jest to jednak wymagane przez pocztę w Wielkiej Brytanii i jest zasadniczo ignorowane. Więcej informacji znajdziesz na stronach postoffice.co.uk i How to address UK and international mail.

W rezultacie, gdy klient poda hrabstwo w adresie w Wielkiej Brytanii, usługa uzna to za nieoczekiwane dane wejściowe.

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

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

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

W tym przypadku wartość address_complete to false, a analiza komponentu adresu ujawnia nieoczekiwany flagę.

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

Gloucestershire to prawidłowe hrabstwo dla wpisanego adresu, ale sam adres jest nieprawidłowo sformatowany. Pamiętaj, że interfejs Address Validation API sprawdza też, czy informacje są prawidłowo sformatowane.