Wybieranie rozwiązania do weryfikacji adresu

Schemat blokowy przedstawiający ogólny przegląd kroków testowania.

Cel

Weryfikacja adresu jest przydatna w wielu przypadkach użycia. Warto wziąć pod uwagę kluczowe aspekty, które wykraczają poza samą jakość wyników testów. Na przykład: całościowy widok zgodnych produktów w ścieżce użytkownika, np. w usługach autouzupełniania miejscMapach, dostępność regionalna oraz zaufanie i niezawodność w przypadku firm.

Gdy przejdziesz do etapu oceny interfejsu Address Validation API, skorzystaj z tych wskazówek podczas testowania.

Cele tego testu to:

  1. Sprawdź, czy interfejs Address Validation API jest odpowiedni w Twoim przypadku.
  2. Sprawdź, jak interfejs Address Validation API spełnia wymagania Twoich rozwiązań, np.:
    • określanie adresów o dobrej jakości;
    • Ostrzeganie o danych wejściowych niskiej jakości.
    • wprowadzanie poprawek do danych adresowych, w tym wniosków, zamian i korekty pisowni;
    • podanie sformatowanego adresu dostawy;
    • Alerty dotyczące brakujących lub nieprawidłowych danych o lokalu (tylko w USA).
  3. Upewnij się, że wdrożenie interfejsu API przyniesie Ci wymierne korzyści.

Po przeprowadzeniu testu będziesz w stanie odpowiedzieć na powyższe pytania i określić, czy interfejs API jest odpowiedni dla Twojej firmy.

Przygotowywanie danych

Test powinien być przeprowadzony na próbce istniejących danych adresowych. Nie wybieraj ręcznie danych do testu, ale wybieraj losowe próbki, które są reprezentatywne dla obszarów geograficznych, na których prowadzisz działalność. Oznacza to, że jeśli prowadzisz działalność zarówno w Stanach Zjednoczonych, jak i w Wielkiej Brytanii, ale 70% Twojej działalności przypada na Wielką Brytanię, a 30% – na Stany Zjednoczone, próbka powinna odzwierciedlać ten podział.

Używaj adresów z miejsca rejestracji. Jeśli na przykład planujesz wdrożyć weryfikację adresu w procesie płatności w sklepie internetowym, używaj adresów wprowadzonych przez klientów w formularzu przed jakimkolwiek przetwarzaniem, które może zostać zastąpione przez wdrożenie interfejsu Address Validation API.

Przygotuj próbkę danych zawierającą około 5000–10 000 rekordów.

Wywoływanie interfejsu API

Warunek wstępny: dowiedz się, jak wysłać prośbę o weryfikację adresu.

Po przygotowaniu danych musisz uruchomić każdy rekord adresu w interfejsie API.

Więcej informacji o wywoływaniu interfejsu API znajdziesz w dokumentacji interfejsu Address Validation API. Mamy też artykuł opisujący sprawdzone metody korzystania z interfejsu Address Validation API do przetwarzania dużej liczby adresów.

Wynikiem tego kroku powinny być dane wyjściowe z interfejsu API dla każdego rekordu adresu. Następnie możesz przeanalizować wyniki, aby określić, czy interfejs API jest odpowiedni do Twojego przypadku użycia. Możesz to zrobić za pomocą arkusza kalkulacyjnego, bazy danych lub innego narzędzia.

Sprawdzanie wyników

Wymagania wstępne: dowiedz się, jak obsługiwać odpowiedź weryfikacyjną, zwłaszcza koncepcję poprawiania, potwierdzania i akceptowania.

W tej sekcji omówimy scenariusze wyjściowe, które możesz analizować, aby ocenić przydatność rozwiązania.

Omówienie kluczowych pól interfejsu API omówionych w tym dokumencie

Dane odpowiedzi

Co to jest?

Jak ocenić

Jak to pomaga?

verdict.inputGranularity

Opisuje szczegółowość danych wejściowych adresu.

SUB_PREMISE

ZAŁOŻENIE

PREMISE_PROXIMITY

BLOKUJ

TRASA

INNA ODPOWIEDŹ

Określa, czy adres wejściowy zawiera wystarczającą ilość danych, aby potencjalnie był prawidłowy.

verdict.validationGranularity

Opisuje ogólną weryfikację danych wyjściowych adresu.

SUB_PREMISE

ZAŁOŻENIE

PREMISE_PROXIMITY

BLOKUJ

TRASA

INNA ODPOWIEDŹ

Umożliwia określenie ogólnej jakości adresu w danych wyjściowych z interfejsu API.

verdict.hasInferredComponents

Sygnalizuje, czy interfejs API wywnioskował komponent.

Prawda/Fałsz

Interfejs API może dodawać brakujące komponenty, w przypadku których może wywnioskować dane. Na przykład brakujący kod stanu.

verdict.hasReplacedComponents

Sygnalizuje, czy interfejs API zastąpił komponent.

Prawda/Fałsz

W niektórych przypadkach interfejs API może zastąpić nieprawidłowe komponenty prawidłowymi danymi.

verdict.addressComplete

Sygnalizuje, czy adres jest kompletny.

Prawda/Fałsz

Jeśli interfejs API stwierdzi, że adres wyjściowy zawiera wszystkie niezbędne komponenty, wartość będzie wynosić „true”.

address.missingComponentTypes

Sygnał ostrzegający, jeśli w adresie brakuje komponentów.

Wartości znajdziesz w tabeli 2.

Wyróżnij brakujące komponenty z niepełnego adresu.

Sprawdzanie prawidłowych adresów

Posortuj dane zwrócone przez interfejs API, aby określić zestaw adresów, które Twój system zaakceptuje jako prawidłowe. Kluczowe sygnały, na które należy zwrócić uwagę w interfejsie API:

  • verdict.validationGranularity zawiera PREMISE lub lepsze.
  • verdict.addressComplete to true.
  • Brak wywnioskowanych lub zastąpionych komponentów.

Więcej informacji znajdziesz w artykule o akceptowaniu adresu.

Wynikiem tego ćwiczenia powinien być podzbiór danych adresowych, które zostałyby zaakceptowane przez Twój system jako prawidłowe. Na tym etapie możesz określić:

  • Czy odsetek akceptacji jest zadowalający?
  • Czy w przypadku korzystania z dotychczasowego procesu weryfikacji adresu współczynnik akceptacji jest równy lub wyższy?

Przykład: prawidłowy adres

Wpisany adres

Region

76 Buckingham Palace Road, Londyn SW1W 9TQ, Wielka Brytania

Wielka Brytania

Efekt

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

Sprawdzanie nieprawidłowych adresów

Ten krok umożliwia ręczne sprawdzenie niektórych danych adresowych, które zostały oznaczone jako nieprawidłowe, i sprawdzenie, czy bez użycia interfejsu Address Validation API nieprawidłowy adres może powodować problemy w dalszej kolejności.

Posortuj dane zwrócone przez interfejs API, aby określić zestaw adresów, które Twój system oznaczy jako nieprawidłowe. Kluczowe sygnały, na które należy zwrócić uwagę w interfejsie API:

  • verdict.validationGranularity ustawione na OTHER lub ROUTE w zależności od poziomu ryzyka.
  • verdict.addressComplete to false.

Więcej informacji znajdziesz w artykule Poprawianie adresu.

Wynikiem tego ćwiczenia powinien być podzbiór danych adresowych, które Twój system oznaczyłby jako nieprawidłowe. Na tym etapie możesz określić, czy nieprawidłowy odsetek jest akceptowalny.

Pamiętaj, że oznaczanie adresów jako nieprawidłowych jest podstawową funkcją interfejsu Address Validation API, a wysoki odsetek adresów oznaczonych jako nieprawidłowe nie musi świadczyć o złej jakości interfejsu API. Interfejs API informuje, że z adresem jest coś nie tak. Może to zwiększyć wydajność Twojej pracy, ponieważ błędy są wykrywane wcześniej, zanim spowodują problemy w dalszej części procesu.

Przykład: nieprawidłowy adres

Wpisany adres

Region

21 45 40th street

USA

Efekt

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

Sprawdzanie brakujących lub niepotwierdzonych komponentów

Na tym etapie można też sprawdzić brakujące lub niepotwierdzone komponenty. Jest to część obiektu Address w odpowiedzi. Te 2 pola to missingComponentTypesunconfirmedComponentTypes.

Użyj tych pól, aby wykryć przyczynę oznaczenia adresu jako nieprawidłowego przez interfejs API i zebrać prawidłowe informacje o adresie, które umożliwią jego weryfikację. W tym celu przekaż do punktu zbierania danych konkretne pola, które są nieprawidłowe. W ten sposób interfejs API dostarcza Ci konkretne informacje o jakości danych.

Przykład: brakujący i niepotwierdzony komponent

Wpisany adres

Region

Fake St, Nowy Jork, NY 10011

USA

Efekt

{
     "inputGranularity": "ROUTE",
     "validationGranularity": "OTHER",
     "geocodeGranularity": "OTHER",
     "hasUnconfirmedComponents": true
}

Brakujące i niepotwierdzone komponenty

"missingComponentTypes": [
    "street_number"
],
"unconfirmedComponentTypes": [
    "route"
]

Sprawdzanie adresów z poprawkami

Interfejs Address Validation API może poprawiać dane wejściowe, przekształcając potencjalnie nieprawidłowy adres w prawidłowe dane adresowe. Jest to jeden ze sposobów, w jaki interfejs API zwiększa wartość, dlatego ważne jest, aby uwzględnić to w teście.

Kluczowe sygnały, na które warto zwrócić uwagę:

  • inferred, replaced lub spellCorrected ustawione na true w dowolnym z tychaddressComponents.
  • verdict.hasInferredComponents lub verdict.hasReplacedComponents ustawione na true.

Więcej informacji znajdziesz w artykule potwierdzanie adresu.

Wynikiem tego ćwiczenia powinien być podzbiór danych adresowych, w którym interfejs API zastosował poprawkę.

Część tych danych można sprawdzić ręcznie, aby określić, czy interfejs API wprowadza poprawki do danych, które zmniejszają problemy w dalszym procesie.

Przykład: adres z korektą

Wpisany adres

Region

76 Bruckingm Palace Road, Londyn SW1W 9TQ

Wielka Brytania

Trasa addressComponent

{
    "componentName": {
        "text": "Buckingham Palace Road",
        "languageCode": "en"
    },
    "componentType": "route",
    "confirmationLevel": "CONFIRMED",
    "spellCorrected": true
}

[Tylko w Stanach Zjednoczonych] Sprawdzanie adresu z brakującymi lub nieprawidłowymi danymi o lokalu

Interfejs Address Validation API może określić, czy w przypadku adresów w Stanach Zjednoczonych brakuje adresu dodatkowego lub czy jest on nieprawidłowy.

Kluczowe sygnały, na które warto zwrócić uwagę:

  • W obiekcie Address:
    • unconfirmedComponentTypes zawiera subpremise
    • missingComponentTypes zawiera subpremise
  • W obiekcie UspsData:
    • dpvConfirmation to D (brak podlokalizacji)
    • dpvConfirmation to S (pomieszczenie niepotwierdzone)

Więcej informacji znajdziesz w sekcji Obsługa adresów w Stanach Zjednoczonych.

Ten test pokaże, czy w danych występuje problem z brakującymi lub nieprawidłowymi informacjami o pomieszczeniach podrzędnych, takimi jak numery mieszkań. Może to powodować problemy w dalszej części procesu, zwłaszcza w przypadku wyświetlania. Interfejs Address Validation API może zwiększyć wartość Twojego procesu, ponieważ wcześniej identyfikuje takie sytuacje, co pozwala Ci wdrożyć działania mające na celu zbieranie poprawionych danych.

Przykład: brak lokalu

Wpisany adres

Region

111 8th Avenue, Manhattan, NY 10011, USA

US

Brak komponentu

"missingComponentTypes": [
    "subpremise"
]

Potwierdzenie DPV danych USPS

"dpvConfirmation": "D"

[Tylko USA] Sprawdzanie adresu standardowego USPS

Interfejs Address Validation API zwraca też znormalizowany adres USPS dla adresów w Stanach Zjednoczonych. Jest to szczególnie ważne, jeśli na etykietach wysyłkowych mają być drukowane adresy w formacie USPS.

Aby wyświetlić te dane i określić, czy są przydatne w Twoim przepływie pracy, możesz sprawdzić pole UspsAddress.

Przykład: znormalizowany adres USPS

"standardizedAddress": {
    "firstAddressLine": "111 8TH AVE FL 11",
    "cityStateZipAddressLine": "NEW YORK NY 10011-5201",
    "city": "NEW YORK",
    "state": "NY",
    "zipCode": "10011",
    "zipCodeExtension": "5201"
}

Podsumowanie

Rozpocznij testowanie – zacznij już dziś testować interfejs Address Validation API, aby mieć pewność, że dane adresowe są dokładne, poprawić wrażenia klientów i usprawnić działanie firmy. Po wykonaniu opisanych powyżej scenariuszy testowych będziesz mieć informacje potrzebne do określenia, czy interfejs Address Validation API przyniesie korzyści w Twoim przepływie pracy.

Sugerowane dalsze lektury:

Współtwórcy

Henrik Valve | Inżynier ds. DevX