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:

• Napraw – adres jest niskiej jakości. Powinna pojawić się prośba o podanie dodatkowych informacji.
• Potwierdź – adres jest wysokiej jakości, ale nie niż w przypadku wprowadzania adresu. Możesz zapytać o z potwierdzeniem.
• 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ć.

Działanie systemu
Popraw adres	Odpowiedź z verdict wskazuje, że brakuje ważnych informacji które należy podać. Adres zwrócony przez Interfejs API do weryfikacji adresów może mieć niską jakość. Przepływ pracy W razie potrzeby sprawdź komponenty adresu. Poproś klienta o rozwiązanie problemów z adresem. Poproś o weryfikację zaktualizowanego adresu. (Opcjonalnie) Wyślij żądanie do punktu końcowego opinii dla interfejsu API. Zapoznaj się z sekcją Obsługa zaktualizowanych adresów. Kontynuuj z adresem. Sygnały oceny Ma miejsce dowolne z tych warunków: Ustawiono validationGranularity na OTHER. Zobacz szczegółowość . addressComplete jest false.
Potwierdź adres	Odpowiedź z verdict wskazuje, że można dostarczyć ale wprowadził zmiany w pierwotnych danych wejściowych, ustalając dane, które są zapisane z poprawioną pisownią lub dane, które można potwierdzić. Przepływ pracy Wymagane poprawki: W razie potrzeby sprawdź komponenty adresu. Poproś o weryfikację zaktualizowanego adresu. (Opcjonalnie) Wyślij żądanie do punktu końcowego opinii dla interfejsu API. Zapoznaj się z sekcją Obsługa zaktualizowanych adresów. Kontynuuj z adresem. Nie ma potrzeby wprowadzania poprawek: (Opcjonalnie) Wyślij żądanie do punktu końcowego opinii dla interfejsu API. Zapoznaj się z sekcją Obsługa zaktualizowanych adresów. Kontynuuj z adresem. Sygnały oceny Są spełnione wszystkie te warunki: validationGranularity zawiera ROUTE lub lepszy. Zobacz szczegółowość . addressComplete jest true. Pole hasInferredComponents zawiera wartość true LUB Pole hasReplacedComponents zawiera wartość true.
Zaakceptuj adres	Odpowiedź interfejsu Address Validation API wskazuje doskonały adres wysokiej jakości. Przepływ pracy Kontynuuj ze zwróconym adresem. Sygnały oceny Są spełnione wszystkie te warunki: validationGranularity zawiera PREMISE lub lepszy. Zobacz wartości szczegółowości. addressComplete jest true. Nie zostały ustalone lub wymienione komponenty.

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.

	Wskazówki	Szczegóły
Poziom ryzyka	Weź pod uwagę poziom tolerancji w stosunku do sytuacji przy szukaniu równowagi między prośbami poprawek i zaakceptowania adresu.	Interfejs Address Validation API zwraca różne sygnały które możesz uwzględnić w swoim poziomie ryzyka, aby zoptymalizować weryfikację proces tworzenia konta. Jeśli na przykład adres zawiera niepotwierdzony numer domu, możesz akceptowalne. Jeśli natomiast Twoja firma wymaga z większą precyzją adresu, możesz poprosić użytkownika. Przykład: mogą należeć do którejkolwiek z tych kategorii, patrz Niepotwierdzony numer budynku (poza USA). w sekcji Akceptuję adres – przykłady.
Akceptuj adresy	Warto zezwolić systemowi na zaakceptowanie oryginalnego wpisu jeśli klient nie odpowiada na prompty.	W takich przypadkach klient mógł podać adres spoza domeny np. w nowych konstrukcjach.
Przekazywanie opinii	Gdy ponownie poprosisz o weryfikację adresu, możesz wyślij też żądanie do punktu końcowego provideValidationFeedback.	Dzięki temu będziemy wiedzieć, jak ostatecznie podjęto decyzję. Zapoznaj się z sekcją Obsługa zaktualizowanych adresów.

Wypróbuj wersję demonstracyjną W pozostałej części tego dokumentu podano różne przykłady. aby pomóc Ci zrozumieć naprawę błędu, potwierdź i zaakceptuj opisany proces powyżej. Możesz przejrzeć ich wyniki, wpisując je w Prezentacja interfejsu Address Validation API.

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.

Uwaga: jeśli w przypadku tego samego adresu wielokrotnie wysyłasz żądania do interfejsu Address Validation API, możesz zadzwonić do provideValidationFeedback, aby poinformować Cię o wyniku. Zobacz Obsługuj adresy w Stanach Zjednoczonych.

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:

Podejrzane komponenty	Gdy enum poziomu potwierdzenia dla komponentu wynosi UNCOMFIRMED_AND_SUSPICIOUS, prawdopodobnie komponentem jest niepoprawnie.
Komponent nierozwiązany	unresolvedToken; jest częścią danych wejściowych, która nie została rozpoznana jako prawidłowa część adresu.

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:

dpvConfirmation	Pole N, D lub puste.

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.

Uwaga: podejmując decyzję, weź pod uwagę poziom ryzyka aby potwierdzić adres z klientem lub zaakceptować go jako prawidłowy. Dodatkowo: należy ponownie wysłać żądania do interfejsu Address Validation API, za pomocą wywołania do provideValidationFeedback, aby poinformować o wyniku. Patrz sekcja Nick został zaktualizowany adresów

.

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ć:

Dane wywnioskowane	Gdy pole hasInferredComponents ma wartość true, wiesz, że interfejs API wypełnił informacje pozyskane z innego adresu
Zastąpione dane	Gdy pole hasReplacedComponents ma wartość true, wartość Interfejs API zastąpił wpisane dane danymi, które uznał za prawidłowy adres.

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:

dpvConfirmation	S Więcej informacji o dpvConfirmation: Obsługa adresów w Stanach Zjednoczonych.
Odpowiedź z adresem	Zawiera pole missingComponentType o wartości subpremise Uwaga: jeśli pole zawiera typy inne niż subpremise, działanie zostanie przyporządkowane poprawić kategorię adresu. Zobacz pełną listę adresów w dokumentacji dotyczącej geokodowania.

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 :

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

Przykłady adresów akceptowanych