Opracuj logikę weryfikacji

W tym dokumencie opisano proces tworzenia systemu sprawdzania adresów, aby obsługuje różne odpowiedzi z interfejsu Address Validation API. Wyjaśniamy, jak stworzyć logikę, która pozwoli prawidłowo korzystać z odpowiedzi oraz badać inne sygnały. oraz kiedy i jak prosić klientów o dodatkowe informacje.

Ogólnie odpowiedź interfejsu API określa te sposoby, w jakie system powinien obsługa adresu:

• handyman Napraw – adres jest niskiej jakości. Powinna pojawić się prośba o podanie dodatkowych informacji.
• edit Potwierdź – adres jest wysokiej jakości, ale nie niż w przypadku wprowadzania adresu. Możesz zapytać o z potwierdzeniem.
• check Akceptuj – adres jest wysokiej jakości. Dostępne opcje zaakceptuj podany adres.

Przeznaczenie klucza

Ten dokument pomoże Ci zmodyfikować system, aby jak najlepiej analizować odpowiedź interfejsu API oraz określać kolejne działania, które należy podjąć w przypadku podanych adresów. Poniżej pseudokod ilustruje możliwy przepływ.

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

Dokładna logika zależy od konkretnej sytuacji – zobacz Wskazówki dotyczące implementacji. . Możesz również skorzystać z naszej implementacji kodu typu open source, który znajduje się w rozszerzonej bibliotece komponentów.

Omówienie przepływu pracy

W tabeli poniżej znajdziesz podsumowanie 2 działań wykonywanych w systemie:

1. Przepływ pracy do użycia oparty na rozwiązaniu problemu, który należy potwierdzić i zaakceptować.
2. Pierwszy sygnał, który należy sprawdzić w odpowiedzi. Sygnały pochodzą z właściwości verdict i nie są jedynymi sygnałów, które należy sprawdzić, ale podaj też początkowy wskaźnik adresu. jakości. Każdy typ zachowania odpowiada sekcji w tym dokumencie i opisywania kolejnych sygnałów, które warto zbadać.

Implementacja – wskazówki

Podczas projektowania reakcji systemu na sygnały z interfejsu Address Validation API: poniższe zalecenia pomogą Ci uzyskać skuteczniejszą odpowiedź model atrybucji. Są to jednak tylko zalecenia, pamiętaj więc, należy wdrożyć ją zgodnie z modelem biznesowym.

Poprawianie adresu

Popraw adres, jeśli wyniki wyraźnie wskazują, że adres nie należy do prawdziwych które można zrealizować. System może następnie poprosić klienta o podanie informacje, po czym należy ponownie rozpocząć przepływ pracy, aby otrzymać adresu.

Napraw sygnały

Interfejs API weryfikacji adresu dostarcza szereg sygnałów wskazujących, czy powinien być naprawiony.

1. Szczegółowość weryfikacji i brakujące komponenty

Te dwa sygnały najlepiej wskazują problemy z adresem:

• Gdy pole validationGranularity ma wartość OTHER, system powinien przeanalizuj sygnały komponentów adresu, aby dowiedzieć się, gdzie występuje błąd i sposób jego rozwiązania.
• Za każdym razem, gdy przetworzony obiekt address zwraca missingComponentTypes, system powinien sprawdzić ten komponent. Brakujące komponenty powodują też, że adres jest niekompletny i nie można go dostarczyć.

2. Inne sygnały

Interfejs Address Validation API dostarcza też inne sygnały, które pomagają diagnozować konkretne problemy:

3. Sygnały adresowe w Stanach Zjednoczonych

Niektóre pola dotyczące tylko adresów w Stanach Zjednoczonych dają przydatny sygnał, że jest niemożliwe do dostarczenia i należy go naprawić. W przypadku adresu, który wymaga podania powinien pojawić się następujący komunikat:

Więcej informacji o dpvConfirmation: Obsługa adresów w Stanach Zjednoczonych.

Przykłady poprawek adresów

Potwierdź adres

Potwierdzasz adres, gdy wynik wskazuje, że interfejs Address Validation API wywnioskował(a) lub wprowadził(a) zmiany w odniesieniu do komponentów w celu wygenerowania weryfikowany adres. W takich przypadkach masz adres dostawy, ale wolisz z większą pewnością, że wynikowy adres jest tym, którego zamierzyła funkcja klienta.

Aby zapewnić klientowi prawidłowe prompty, za pomocą Twojej funkcji logicznej komponenty oznaczone przez usługę w celu określenia działania lub flagi interfejsu API. zastosowano do komponentu, np. inferred, replaced lub spellCorrected. Zobacz AddressComponent w dokumentacji.

Potwierdzanie sygnałów

Interfejs API weryfikacji adresu dostarcza szereg sygnałów wskazujących, czy adres powinien zostać potwierdzony.

1. Szczegółowość walidacji

Dopuszczalna jest wartość validationGranularity o wartości ROUTE lub wyższej, ale: Metody PREMISE lub SUBPREMISE zapewniają lepszy sygnał dotyczący możliwości dostarczenia zamówienia.

2. Inne sygnały

Przy podejmowaniu decyzji o potwierdzeniu adresu u klienta który pozwala określić, które elementy należy zbadać:

3. Sygnały adresowe w Stanach Zjednoczonych

Niektóre pola dotyczące tylko adresów w Stanach Zjednoczonych wskazują, że kod powinien potwierdzić szczegóły z klientem. Może być spełniony jeden z tych warunków:

Przykładowe potwierdzanie adresów

Akceptowanie adresu

Akceptujesz adres, gdy decyzja daje wysoki stopień pewności, że adres można dostarczyć i można go użyć bez dalszej interakcji z klientem w kolejnych procesach.

Akceptuj sygnały

Interfejs API weryfikacji adresu dostarcza szereg sygnałów wskazujących, czy adres powinien zostać potwierdzony.

1. Szczegółowość walidacji

Dopuszczalna jest wartość validationGranularity o wartości PREMISE lub większa, ale w niektórych przypadkach ROUTE nadal wskazuje adres, który można dostarczyć.

2. Inne sygnały

Ocena wysokiej jakości adresu powinna też zawierać:

• Brak zastąpionych danych. W tym przypadku: hasReplacedComponents: FALSE.
• Brak wykrytych komponentów. W tym przypadku: hasInferredComponents: FALSE.

3. Sygnały adresowe w Stanach Zjednoczonych

Niektóre pola dotyczące adresów w Stanach Zjednoczonych wskazują na adres wysokiej jakości które można dostarczyć. Akceptowane adresy w Stanach Zjednoczonych powinny być widoczne :

Przykłady adresów akceptowanych