Opracuj logikę weryfikacji

W tym dokumencie opisano proces tworzenia systemu sprawdzania adresu do obsługi różnych odpowiedzi z interfejsu Address Verificationation API. Dowiesz się z niego, jak tworzyć logikę w celu prawidłowego korzystania z odpowiedzi, analizować inne sygnały interfejsu API oraz kiedy i jak prosić klientów o dodatkowe informacje.

Ogólnie rzecz biorąc, odpowiedź interfejsu API określa te sposoby obsługi adresu przez system:

• handyman Rozwiąż problem – adres jest niskiej jakości. Powinien pojawić się prośba o podanie dodatkowych informacji.
• edit Potwierdź – adres jest wysokiej jakości, ale zmienił się w stosunku do adresu wejściowego. Możesz zobaczyć prośbę o potwierdzenie.
• check Akceptuj – adres jest wysokiej jakości. Możesz zaakceptować podany adres.

Przeznaczenie klucza

Ten dokument pomoże Ci zmodyfikować system tak, aby jak najlepiej analizować odpowiedź interfejsu API i określić następne działania, które należy podjąć z podanymi adresami. Poniższy 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 Twojej sytuacji – więcej informacji znajdziesz we wskazówkach dotyczących implementacji. Możesz też skorzystać z naszej implementacji tego typu open source dostępnej w rozszerzonej bibliotece komponentów.

Omówienie przepływu pracy

Tabela poniżej zawiera podsumowanie 2 działań wykonywanych w Twoim systemie:

1. Przepływ pracy, którego należy użyć w zależności od zastosowanej poprawki, potwierdzenia i akceptacji działania.
2. Pierwsze sygnały, które należy sprawdzić w odpowiedzi. Opisane tu sygnały pochodzą z właściwości verdict i nie są jedynymi sygnałami, które należy sprawdzić, ale stanowią wstępny wskaźnik jakości adresu. Każdy typ zachowania odpowiada sekcji w tym dokumencie z opisem kolejnych sygnałów, które być może musisz zbadać.

Działanie systemu
handyman Popraw adres	Odpowiedź z verdict wskazuje, że brakuje ważnych informacji, które należy podać. Adres zwracany przez interfejs Address Verificationation API może mieć nieodpowiednią jakość. Przepływ pracy W razie potrzeby sprawdź komponenty adresu. Proś klienta o rozwiązanie problemów. Poproś o weryfikację zaktualizowanego adresu. (Opcjonalnie) Wyślij żądanie do punktu końcowego opinii dla interfejsu API. Zobacz Obsługa zaktualizowanych adresów. Kontynuuj z adresem. Sygnały dotyczące decyzji Występuje dowolny z tych warunków: Ustawiono validationGranularity na OTHER. Zobacz wartości szczegółowości. addressComplete to false.
edit Potwierdź adres	Odpowiedź z verdict wskazuje adres do dostarczenia, ale wprowadzono zmiany w pierwotnych danych wejściowych: wywnioskowano dane, w przypadku których poprawiono 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. Zobacz Obsługa zaktualizowanych adresów. Kontynuuj z adresem. Poprawki nie są wymagane: (Opcjonalnie) Wyślij żądanie do punktu końcowego opinii dla interfejsu API. Zobacz Obsługa zaktualizowanych adresów. Kontynuuj z adresem. Sygnały dotyczące decyzji Obowiązują wszystkie te warunki: validationGranularity zawiera wartość ROUTE lub lepszą. Zobacz wartości szczegółowości. addressComplete to true. Pole hasInferredComponents ma wartość true LUB pole hasReplacedComponents ma wartość true.
check Zaakceptuj adres	Odpowiedź interfejsu Address Review API dotycząca jakości wskazuje na doskonałą jakość adresu. Przepływ pracy Kontynuuj ze zwróconym adresem. Sygnały dotyczące decyzji Obowiązują wszystkie te warunki: validationGranularity zawiera wartość PREMISE lub lepszą. Zobacz wartości szczegółowości. addressComplete to true. Nie ma żadnych wywnioskowanych ani zastąpionych komponentów.

Implementacja – wskazówki

Podczas projektowania sposobu, w jaki system reaguje na sygnały z interfejsu Address Verificationation API, skorzystaj z podanych niżej zaleceń, które pomogą Ci utworzyć skuteczniejszy model odpowiedzi. Są to jednak tylko zalecenia, więc pamiętaj, że Twoja implementacja powinna pasować do Twojego modelu biznesowego.

	Wskazówki	Szczegóły
Poziom ryzyka	Weź pod uwagę poziom tolerancji w Twojej sytuacji, gdy znajdziesz równowagę między prośbami o poprawienie danych a akceptacją wpisanego adresu.	Interfejs Address Review API zwraca różne sygnały, które możesz uwzględnić na swoim poziomie ryzyka, aby zoptymalizować proces weryfikacji. Jeśli na przykład adres ma niepotwierdzony numer domu, możesz go zaakceptować. Jeśli natomiast Twoja działalność wymaga większej precyzji adresu, możesz wyświetlić prośbę o to użytkownikowi. Przykłady treści, które mogą należeć do jednej z tych kategorii, znajdziesz w sekcji Niepotwierdzony numer ulicy i numer domu spoza Stanów Zjednoczonych w artykule Akceptowany adres – przykłady.
Akceptuj adresy	Warto zezwolić systemowi na zaakceptowanie oryginalnego wpisu, jeśli klient nie odpowie na prompty.	W takich przypadkach klient mógł wpisać adres, którego nie ma w systemie, na przykład adres związany z nową budową.
Przesyłanie opinii	Wysyłając ponownie prośbę o weryfikację adresu, możesz też wysłać ją do punktu końcowego provideValidationFeedback.	Dzięki temu Google wie, jak potraktowaliśmy Twoją ostateczną odpowiedź. Zobacz Obsługa zaktualizowanych adresów.

Poprawianie adresu

Popraw adres, gdy wyniki wyraźnie wskazują, że adres nie jest możliwa do dostarczenia. System może poprosić klienta o podanie niezbędnych informacji. Następnie możesz ponownie wysłać przepływ pracy, aby uzyskać adres dostawy.

Popraw sygnały

Interfejs Address Verification API udostępnia kilka sygnałów informujących o tym, czy adres należy poprawić.

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

Te 2 sygnały najlepiej wskazują problematyczne adresy:

• Gdy pole validationGranularity ma wartość OTHER, system powinien sprawdzić sygnały komponentów adresu, aby dowiedzieć się, gdzie wystąpił błąd i jak go naprawić.
• Za każdym razem, gdy przetworzony końcowy obiekt address zwraca pole 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 Verification API dostarcza też inne sygnały, które pomagają diagnozować określone problemy:

Podejrzane komponenty	Jeśli wyliczenie poziomu potwierdzenia dla komponentu to UNCOMFIRMED_AND_SUSPICIOUS, prawdopodobnie jest on nieprawidłowy.
Nierozwiązany komponent	unresolvedToken to część danych wejściowych, która nie została rozpoznana jako prawidłowa część adresu.

3. Sygnały adresowe w USA

Niektóre pola, które mają zastosowanie tylko w przypadku adresów w Stanach Zjednoczonych, dostarczają przydatnych informacji o tym, że adres jest niemożliwy do dostarczenia i należy go poprawić. W przypadku adresu, który wymaga poprawienia, zobaczysz ten komunikat:

dpvConfirmation	Pole N, D lub pole puste.

Szczegółowe informacje o dpvConfirmation znajdziesz w sekcji Obsługa adresów w Stanach Zjednoczonych.

Przykładowe poprawianie adresów

Potwierdź adres

Potwierdzisz adres, gdy wynik wskazuje, że interfejs Address Review API wywnioskował lub wprowadził zmiany w adresach komponentów w celu wygenerowania zweryfikowanego adresu. W takich przypadkach masz określony adres dostawy, ale chcesz mieć większą pewność, że wynikowy adres jest tym, który jest zamierzony.

Aby zapewnić klientowi prawidłowe żądanie, Twoja logika wskaże komponenty oznaczone przez usługę w celu określenia, które działanie lub które oznacza interfejs API zastosowany do komponentu, np. inferred, replaced lub spellCorrected. Zobacz AddressComponent w przewodniku.

Potwierdź sygnały

Interfejs Address Verification API dostarcza szereg sygnałów informujących o tym, czy adres należy potwierdzić.

1. Szczegółowość walidacji

validationGranularity o wartości ROUTE lub większej jest akceptowalny, ale wartości PREMISE lub SUBPREMISE zapewniają silniejszy sygnał dotyczący tego, czy treść jest dostarczana.

2. Inne sygnały

Gdy klient zdecyduje się potwierdzić adres e-mail, wynik zawiera też te informacje, które pozwalają określić, które elementy należy zbadać:

Wywnioskowane dane	Gdy pole hasInferredComponents ma wartość true, oznacza to, że interfejs API wpisał informacje zebrane z innych komponentów adresu.
Zastąpione dane	Gdy pole hasReplacedComponents ma wartość true, interfejs API zastąpił wpisane dane danymi, które uznał za prawidłowe.

3. Sygnały adresowe w USA

Niektóre pola dotyczące tylko adresów w Stanach Zjednoczonych wskazują, że Twoja logika powinna potwierdzać szczegóły u klienta. Występuje jedna z tych sytuacji:

dpvConfirmation	S Więcej informacji o dpvConfirmation znajdziesz w sekcji Obsługa adresów w Stanach Zjednoczonych.
Odpowiedź dotycząca adresu	Zawiera pole missingComponentType o wartości subpremise.

Potwierdź przykładowe adresy

Zaakceptuj adres

Akceptujesz adres, gdy wynik daje wysoki stopień pewności, że jest on prawidłowy i można go użyć bez dalszej interakcji z klientem w trakcie dalszego procesu sprzedaży.

Zaakceptuj sygnały

Interfejs Address Verification API dostarcza szereg sygnałów informujących o tym, czy adres należy potwierdzić.

1. Szczegółowość walidacji

Wartość validationGranularity wynosząca co najmniej PREMISE jest akceptowana, 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ć te informacje:

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

3. Sygnały adresowe w USA

Niektóre pola, które mają zastosowanie tylko do adresów w Stanach Zjednoczonych, wskazują wysokiej jakości adres, na który można dostarczyć produkty. Akceptowany adres w USA powinien wyglądać tak:

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

Akceptowanie przykładowych adresów