Opracuj logikę weryfikacji

W tym dokumencie opisujemy proces tworzenia systemu sprawdzania adresów, który obsługuje różne odpowiedzi z interfejsu Address Validation API. Dowiesz się z niego, jak tworzyć logikę, aby prawidłowo korzystać z odpowiedzi, jak badać 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 jest wysokiej jakości, ale zawiera zmiany w porównaniu z adresem podanym we wpisie. Może pojawić się prośba o potwierdzenie.
  • Zaakceptuj – 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żej przedstawiono pseudokod ilustrujący możliwy przepływ danych.

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 tutaj sygnały pochodzą z usługi 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, w której opisano dodatkowe sygnały, które mogą wymagać sprawdzenia.
Zachowanie systemu
Popraw adres

Odpowiedź z verdict wskazuje, że brakuje ważnych informacji, które należy podać. Adres zwrócony przez interfejs Address Validation API może nie być nadający się do wysyłki.

Przepływ pracy

  1. W razie potrzeby sprawdź elementy adresu.
  2. Poproś klienta o naprawienie problemów z adresem.
  3. Poproś o weryfikację zaktualizowanego adresu.
  4. (Opcjonalnie) Prześlij żądanie do punktu końcowego opinii interfejsu API. Zobacz Obsługa zaktualizowanych adresów.
  5. Przejdź do adresu.

Sygnały dotyczące wyroku

Każda z tych sytuacji:
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

  1. Korekty:
    1. W razie potrzeby sprawdź elementy adresu.
    2. Poproś o weryfikację zaktualizowanego adresu.
    3. (Opcjonalnie) Prześlij żądanie do punktu końcowego opinii interfejsu API. Zobacz Obsługa zaktualizowanych adresów.
    4. Przejdź do adresu.
  2. Nie wymagają poprawek:
    1. (Opcjonalnie) Prześlij żądanie do punktu końcowego opinii interfejsu API. Zobacz Obsługa zaktualizowanych adresów.
    2. 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ść trueLUB pole 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 dotyczące wyroku

Wszystkie z tych stwierdzeń są prawdziwe:

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ę, czy wyświetlić prośbę o poprawienie adresu, czy zaakceptować adres w takiej formie, w jakiej 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 krajach innych niż Stany Zjednoczone w artykule Akceptowane adresy – 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.
Przesyłanie 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ź. Zobacz Obsługa zaktualizowanych adresów.

Poprawianie adresu

Popraw adres, gdy wyniki wyraźnie wskazują, że nie można go dostarczyć. Twój system może poprosić klienta o podanie niezbędnych informacji, a następnie ponownie uruchomić przepływ pracy, aby uzyskać adres dostawy.

Poprawianie sygnałów

Interfejs API weryfikacji adresów udostępnia kilka sygnałów, które informują, czy adres wymaga poprawienia.

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 dotyczące adresu 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:

dpvConfirmation Może to być N, D lub pusty.

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

Przykłady poprawiania adresów

Potwierdzanie adresu

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 klient wskazał.

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.

Potwierdź sygnały

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 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, werdykt zawiera też 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 uzyskane 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. Dotyczy to jednej z tych sytuacji:

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.

Przykłady adresów do potwierdzenia

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

Werdykt dotyczący adresu o wysokiej jakości powinien zawierać te informacje:

  • 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ę. W przypadku akceptowalnego adresu w Stanach Zjednoczonych powinieneś zobaczyć:

dpvConfirmation Y

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

Przykłady adresów do zaakceptowania

Wstecz
Podstawowe odpowiedzi