Opracuj logikę weryfikacji

Z tego dokumentu dowiesz się, jak tworzyć system sprawdzania adresów, który będzie obsługiwać różne odpowiedzi z Address Validation API. Dowiesz się z niego, jak tworzyć logikę, aby prawidłowo korzystać z odpowiedzi, jak analizować inne sygnały z interfejsu API oraz kiedy i jak prosić klientów o dodatkowe informacje.

Ogólnie odpowiedź interfejsu API określa, w jaki sposób system powinien obsługiwać adres:

• Rozwiązanie: adres jest niskiej jakości. Powinieneś poprosić o dodatkowe informacje.
• Potwierdź – adres ma wysoką jakość, ale został zmieniony z podanego adresu. Może pojawić się prośba o potwierdzenie.
• Akceptuj – adres jest wysokiej jakości. Możesz zaakceptować podany adres.

Przeznaczenie klucza

Ten dokument pomoże Ci zmodyfikować system, aby najlepiej analizować odpowiedź interfejsu API i określać kolejne działania dotyczące podanych adresów. 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 sytuacji. Więcej informacji znajdziesz w instrukcjach implementacji. Możesz też użyć naszej implementacji tej logiki w ramach biblioteki Extended Component Library.

Omówienie przepływu pracy

Tabela poniżej zawiera podsumowanie 2 działań dotyczących Twojego systemu:

1. Przepływ pracy do użycia na podstawie zachowania naprawiania, potwierdzania i akceptowania.
2. Pierwszym sygnałem do sprawdzenia jest odpowiedź. Opisane tu sygnały pochodzą z usługi verdict i nie są jedynymi sygnałami, które należy sprawdzić, ale stanowią początkowy wskaźnik jakości adresu. Każdy typ zachowania odpowiada sekcji w tym dokumencie, w której opisano dodatkowe sygnały, które mogą wymagać sprawdzenia.

Zachowanie systemu
Popraw adres	Odpowiedź z verdict wskazuje ważne brakujące informacje, które należy podać. Adres zwracany przez interfejs Address Validation API może mieć niską jakość. Przepływ pracy W razie potrzeby sprawdź komponenty adresu. Poproś klienta o naprawienie problemów z adresem. Poproś o weryfikację zaktualizowanego adresu. (Opcjonalnie) Wyślij żądanie do punktu końcowego opinii dla interfejsu API. Zobacz Obsługa zaktualizowanych adresów. Przejdź do adresu. Sygnały dotyczące wyroku Każda z tych sytuacji: Ustawiono validationGranularity na OTHER. Zobacz wartości szczegółowości. addressComplete to false.
Potwierdź adres	Odpowiedź z verdict wskazuje adres, do którego można wysłać wiadomość, ale wprowadziła zmiany w początkowym wejściu: dane są albo poprawione pod kątem pisowni, albo można je potwierdzić. Przepływ pracy Korekty: W razie potrzeby sprawdź elementy adresu. Poproś o weryfikację zaktualizowanego adresu. (Opcjonalnie) Prześlij żądanie do punktu końcowego opinii interfejsu API. Zobacz Obsługa zaktualizowanych adresów. Przejdź do adresu. Nie wymagają poprawek: (Opcjonalnie) Prześlij żądanie do punktu końcowego opinii interfejsu API. Zobacz Obsługa zaktualizowanych adresów. Przejdź do adresu. Sygnały dotyczące wyroku Wszystkie z tych stwierdzeń są prawdziwe: validationGranularity zawiera ROUTE lub lepszą wersję. Zobacz wartości poziomów szczegółowości. addressComplete to true. Pole hasInferredComponents ma wartość trueLUBpole hasReplacedComponents ma wartość true.
Akceptowanie adresu	Odpowiedź interfejsu Address Validation API wskazuje, że adres jest wysokiej jakości. Przepływ pracy Przejdź do adresu zwrotnego. Sygnały oceny Wszystkie z tych stwierdzeń są prawdziwe: validationGranularity zawiera PREMISE lub lepszą wersję. Zobacz wartości poziomu szczegółowości. addressComplete to true. Nie wywnioskowano ani nie zastąpiono żadnych komponentów.

Wskazówki dotyczące implementacji

Podczas projektowania sposobu, w jaki Twój system reaguje na sygnały z interfejsu Address Validation API, te zalecenia mogą pomóc Ci stworzyć skuteczniejszy model odpowiedzi. Pamiętaj jednak, że są to tylko rekomendacje, a ich wdrożenie powinno być dostosowane do Twojego modelu biznesowego.

	Wskazówki	Szczegóły
Poziom ryzyka	Uwzględnij poziom tolerancji w swojej sytuacji, gdy będziesz podejmować decyzję między wyświetlaniem promptów dotyczących poprawek a akceptacją adresu w takim stanie, w jakim został wpisany.	Interfejs API weryfikacji adresu zwraca różne sygnały, które możesz uwzględnić w poziomie ryzyka, aby zoptymalizować proces weryfikacji. Jeśli na przykład adres ma niezweryfikowany numer ulicy, nadal możesz go zaakceptować. Jeśli jednak Twoja firma wymaga większej dokładności adresu, możesz poprosić użytkownika o jego podanie. Przykład, który może pasować do obu kategorii, znajdziesz w sekcji Niepotwierdzony numer ulicy w kraju spoza Stanów Zjednoczonych w artykule Akceptowany adres – przykłady.
Akceptowanie adresów	Jeśli klient nie odpowiada na prompty, warto pozwolić systemowi zaakceptować pierwotne dane.	W takich przypadkach klient może podać adres, którego nie ma w systemie, np. adres nowej budowy.
Przekazywanie opinii	Gdy ponownie wyślesz prośbę o weryfikację adresu, możesz też wysłać prośbę do punktu końcowego provideValidationFeedback.	Dzięki temu Google będzie wiedzieć, jak ostatecznie potraktowano Twoją ostateczną odpowiedź. Zapoznaj się z sekcją Obsługa zaktualizowanych adresów.

Wypróbuj wersję demonstracyjną W dalszej części tego dokumentu znajdziesz różne przykłady, które pomogą Ci zrozumieć omówiony powyżej proces naprawy, potwierdzenia i zaakceptowania. Wyniki z tych przykładów możesz sprawdzić, wpisując je w demo interfejsu Address Validation API.

Poprawianie adresu

Popraw adres, gdy wyniki wyraźnie wskazują, że nie można go dostarczyć. System może poprosić klienta o podanie niezbędnych informacji, a potem ponownie uruchomić przepływ pracy, aby uzyskać adres do dostarczenia.

Uwaga: jeśli w przypadku tego samego adresu wielokrotnie wysyłasz żądania do interfejsu Address Validation API, możesz wywołać metodę provideValidationFeedback, aby poinformować o wyniku. Zobacz artykuł Praca z adresami w Stanach Zjednoczonych.

Napraw sygnały

Interfejs Address Validation API dostarcza wiele sygnałów, które informują, czy adres należy poprawić.

1. Dokładność weryfikacji i brakujące komponenty

Te 2 sygnały najlepiej wskazują adres, który może być problematyczny:

• Gdy pole validationGranularity ma wartość OTHER, system powinien zbadać sygnały komponentu adresu, aby dowiedzieć się więcej o tym, gdzie wystąpił błąd i jak go naprawić.
• Za każdym razem, gdy przetworzony obiekt address zwraca pole missingComponentTypes, Twój system powinien sprawdzić ten komponent. Brakujące elementy powodują, że adres jest niekompletny i niemożliwy do dostarczenia.

2. Inne sygnały

Interfejs API weryfikacji adresów dostarcza też inne sygnały, które pomagają zdiagnozować konkretne problemy:

Podejrzane komponenty	Jeśli enumeracja poziomu potwierdzenia dla komponentu to UNCOMFIRMED_AND_SUSPICIOUS, prawdopodobnie komponent jest 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 Stanach Zjednoczonych

Niektóre pola, które mają zastosowanie tylko do adresów w Stanach Zjednoczonych, dostarczają przydatnego sygnału, że adres nie może zostać dostarczony i należy go poprawić. W przypadku adresu, który wymaga naprawy, zobaczysz ten komunikat:

dpvConfirmation	Pole N, D lub puste.

Szczegółowe informacje o dpvConfirmation znajdziesz w artykule Praca z adresami w Stanach Zjednoczonych.

Przykłady poprawiania adresów

Potwierdź adres

Adres jest potwierdzany, gdy interfejs API weryfikacji adresów wywnioskował lub wprowadził zmiany w elementach adresu, aby uzyskać potwierdzony adres. W takich przypadkach masz adres dostawy, ale chcesz mieć pewność, że jest to adres, który podał klient.

Aby wyświetlić klientowi odpowiednie prompty, Twoja logika musi zidentyfikować komponenty oznaczone przez usługę, aby określić, jakie działanie lub flagę interfejs API zastosował w przypadku danego komponentu, np. inferred, replaced lub spellCorrected. Więcej informacji znajdziesz w sekcji AddressComponent.

Uwaga: przy podejmowaniu decyzji, czy potwierdzić adres u klienta, czy uznać go za prawidłowy, weź pod uwagę poziom ryzyka. Dodatkowo, jeśli ponownie wyślesz żądania do interfejsu Address Validation API, możesz wykonać wywołanie do interfejsu provideValidationFeedback, aby wskazać wynik. Zobacz Przetwarzanie zaktualizowanych adresów

.

Potwierdzanie sygnałów

Interfejs Address Validation API dostarcza szereg sygnałów, które informują, czy adres należy potwierdzić.

1. Szczegółowość weryfikacji

Dopuszczalna jest wartość validationGranularity ROUTE lub wyższa, ale PREMISE lub SUBPREMISE zapewniają silniejszy sygnał o możliwości dostarczenia.

2. Inne sygnały

Gdy decydujesz się potwierdzić adres u klienta, werdyk zawiera również te informacje, które pomogą Ci określić, które elementy należy sprawdzić:

Dane wywnioskowane	Gdy pole hasInferredComponents ma wartość true, wiesz, że interfejs API wypełnił informacje zebrane z innych komponentów adresu.
Zastąpione dane	Gdy pole hasReplacedComponents ma wartość true, interfejs API zastępuje wprowadzone dane danymi, które uzna za prawidłowe.

3. sygnały dotyczące adresu w Stanach Zjednoczonych,

Niektóre pola, które dotyczą tylko adresów w Stanach Zjednoczonych, wskazują, że Twoja logika powinna potwierdzić szczegóły z klientem. Wykonaj jedną z tych czynności:

dpvConfirmation	S Szczegółowe informacje o dpvConfirmation znajdziesz w artykule Praca z adresami w Stanach Zjednoczonych.
Odpowiedź na odpowiedź	Zawiera pole missingComponentType z wartością subpremise. Uwaga: jeśli pole zawiera typy inne niż subpremise, działanie zostanie zaliczone do kategorii poprawiania adresu. Pełną listę typów adresów znajdziesz w dokumentacji dotyczącej geokodowania.

Przykładowe potwierdzanie adresów

Akceptowanie adresu

Adres akceptujesz, gdy wynik jest bardzo wiarygodny i potwierdza, że adres jest prawidłowy i można go wykorzystać bez dalszej interakcji z klientem w dalszym procesie.

Akceptowanie sygnałów

Interfejs API weryfikacji adresu udostępnia kilka sygnałów, które informują, czy adres powinien zostać potwierdzony.

1. Szczegółowość weryfikacji

Dopuszczalna jest wartość validationGranularity = PREMISE lub wyższa, ale w niektórych przypadkach wartość ROUTE = ROUTE nadal wskazuje adres, pod który można dostarczyć przesyłkę.

2. Inne sygnały

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

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

3. sygnały dotyczące adresu w Stanach Zjednoczonych,

Niektóre pola, które mają zastosowanie tylko do adresów w Stanach Zjednoczonych, wskazują na adres wysokiej jakości, na który można dostarczyć przesyłkę. Oto informacje o akceptowanym adresie w Stanach Zjednoczonych:

dpvConfirmation	Y Szczegółowe informacje o dpvConfirmation znajdziesz w artykule Praca z adresami w Stanach Zjednoczonych.

Przykłady adresów do zaakceptowania