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 miejsc i Mapach, 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:
- Sprawdź, czy interfejs Address Validation API jest odpowiedni w Twoim przypadku.
- 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).
- 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
zawieraPREMISE
lub lepsze.verdict.addressComplete
totrue
.- 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 naOTHER
lubROUTE
w zależności od poziomu ryzyka.verdict.addressComplete
tofalse
.
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 missingComponentTypes
i unconfirmedComponentTypes
.
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
lubspellCorrected
ustawione natrue
w dowolnym z tychaddressComponents
.verdict.hasInferredComponents
lubverdict.hasReplacedComponents
ustawione natrue
.
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
zawierasubpremise
missingComponentTypes
zawierasubpremise
- W obiekcie UspsData:
dpvConfirmation
toD
(brak podlokalizacji)dpvConfirmation
toS
(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:
- Dokumentacja dla deweloperów dotycząca interfejsu Address Validation API
- Przetwarzanie dużej liczby adresów za pomocą interfejsu Address Validation API
- Weryfikacja adresu podczas płatności w e-commerce
Współtwórcy
Henrik Valve | Inżynier ds. DevX