Przetwarzanie adresów przy dużej liczbie adresów za pomocą interfejsu Address Validation API

Cel

Jako programista często pracujesz ze zbiorami danych zawierającymi adresy klientów, mogą mieć niską jakość. Musisz się upewnić, że adresy są poprawne przypadki użycia, od weryfikacji identyfikatora klienta po dostawę.

Weryfikacja adresu API pochodzi z usługi Google Maps Platform, której możesz użyć do zweryfikowania adresu. Pamiętaj jednak, że tylko przetwarza tylko jeden adres naraz. W tym dokumencie omówimy, jak korzystać weryfikacji adresów na dużą skalę w różnych scenariuszach, od testowania interfejsów API na jednorazową i cykliczną weryfikację adresu.

Przypadki użycia

Teraz zajmiemy się przypadkami użycia, w których weryfikacja adresów (duża ilość) przydatne.

Testowanie

Często chcesz przetestować interfejs Address Validation API, uruchamiając tysiące adresów. Być może masz adresy w pliku wartości rozdzielane przecinkami i chcesz, aby sprawdzić jakość adresów.

Jednorazowa weryfikacja adresów

Podczas wprowadzania do interfejsu Address Validation API chcesz sprawdzić poprawność z bazą adresów i bazą danych użytkowników.

Cykliczna weryfikacja adresów

W wielu sytuacjach konieczne jest cykliczne sprawdzanie adresów:

  • Możesz mieć zaplanowane zadania polegające na sprawdzaniu adresów pod kątem przechwyconych szczegółów w ciągu dnia, np. rejestracje klientów, szczegóły zamówień, dostawę harmonogramy.
  • Możesz otrzymywać zrzuty danych zawierające adresy z różnych działów, np. od sprzedaży po marketing. Nowy dział otrzymujący w przypadku adresów IP często chce się je zweryfikować przed użyciem.
  • Adresy możesz zbierać podczas ankiet i promocji, a w późniejszym czasie w chwili ich aktualizacji w systemie online. Chcesz sprawdzić, czy adresy to poprawnie podczas wpisywania ich w systemie.

Szczegółowa analiza techniczna

Na potrzeby tego dokumentu zakładamy, że:

  • Wywołujesz interfejs Address Validation API przy użyciu adresów od klienta baza danych (np. baza danych z danymi klienta)
  • Flagi poprawności możesz buforować w odniesieniu do poszczególnych adresów w bazie danych.
  • Flagi ważności są pobierane z interfejsu Address Validation API, gdy loguje się dany klient.
.

Pamięć podręczna na potrzeby środowiska produkcyjnego

Korzystając z interfejsu Address Validation API, często chcesz zapisywać w pamięci podręcznej część w odpowiedzi z wywołania interfejsu API. Chociaż nasze Warunki Limit usługi jakie dane można przechowywać w pamięci podręcznej, wszelkie dane, które można przechowywać w pamięci podręcznej z interfejsu Address Validation API; muszą być zapisane w pamięci podręcznej na koncie użytkownika. Oznacza to, że w bazie danych adresu lub metadanych adresu muszą być przechowywane w pamięci podręcznej z adresem e-mail użytkownika lub inny podstawowy dokument tożsamości.

W przypadku walidacji adresów dla dużych ilości buforowanie danych musi być zgodne z Interfejs API do weryfikacji adresu – specyficzna dla usługi Warunki, opisane w Sekcji 11.3. Te informacje pozwolą Ci określić, sprawdzić, czy adres użytkownika jest nieprawidłowy. W takim przypadku pojawia się do poprawionego adresu podczas następnej interakcji z aplikacji.

  • Dane z komponentu AddressComponent obiekt
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

Jeśli chcesz zapisać w pamięci podręcznej jakiekolwiek informacje o rzeczywistym adresie, dane mogą być umieszczane w pamięci podręcznej wyłącznie za zgodą użytkownika. Dzięki temu użytkownicy wiedzą, wie, dlaczego konkretna usługa przechowuje swój adres, i zgadza się na warunki udostępniania swojego adresu.

Przykładem zgody użytkownika może być bezpośrednia interakcja z adresem e-commerce na stronie płatności. Zgodnie z zasadami będą przesyłane w pamięci podręcznej przetworzyć adres w celu wysyłki paczki.

Za zgodą użytkownika możesz zapisać w pamięci podręcznej interfejs formattedAddress i inne kluczowe komponenty z odpowiedzi. Jednak w trybie bez interfejsu graficznego użytkownik nie może podać Google, ponieważ weryfikacja adresu odbywa się na poziomie backendu. Dlatego w takiej sytuacji możesz przechowywać w pamięci podręcznej bardzo ograniczone informacje.

Zrozumienie odpowiedzi

Jeśli odpowiedź interfejsu Address Validation API zawiera poniższe znaczniki, możesz mieć pewność, że dane wejściowe mają odpowiednią jakość:

  • Znacznik addressComplete w wyniku obiekt to true,
  • validationGranularity w wyniku obiekt to PREMISE lub SUB_PREMISE
  • Brak komponentu AddressComponent. są oznaczone jako:
    • Inferred(Uwaga: inferred=truemoże wystąpić, gdy: addressComplete=true).
    • spellCorrected
    • replaced
    • unexpected i
  • confirmationLevel: Poziom potwierdzenia na stronie AddressComponent jest ustawiona na CONFIRMEDlubUNCONFIRMED_BUT_PLAUSIBLE

Jeśli odpowiedź interfejsu API nie zawiera powyższych znaczników, adres wejściowy prawdopodobnie był niskiej jakości. Możesz buforować flagi w bazie danych, aby odzwierciedlić że. Flagi w pamięci podręcznej wskazują, że cały adres jest niskiej jakości, a bardziej szczegółowe flagi, takie jak Poprawiono pisownię, wskazują konkretny typ i rozwiązać problem z jakością. Przy następnej interakcji klienta z oznaczonym adresem niskiej jakości, możesz wywołać interfejs Address Validation API za pomocą adresu. Interfejs API do weryfikacji adresu zwróci poprawny adres, które można wyświetlić za pomocą prompta interfejsu użytkownika. Gdy klient zaakceptuje sformatowany adres możesz zapisać w pamięci podręcznej te elementy z odpowiedzi:

  • formattedAddress
  • postalAddress
  • addressComponent componentNameslub
  • UspsData standardizedAddress

Wdrażanie weryfikacji adresu bez interfejsu graficznego

Na podstawie powyższej dyskusji:

  • Często trzeba zapisać część odpowiedzi w pamięci podręcznej w pamięci podręcznej Interfejs API weryfikacji do celów biznesowych.
  • Jednak Warunki Usługa w Google Maps Platform ogranicza zakres danych, które można przechowywać w pamięci podręcznej.

W następnej sekcji omówimy dwuetapowy proces dopasowywania reklam przestrzegania Warunków korzystania z usługi i wdrożenia dużej liczby adresów.

Krok 1.

W pierwszym kroku przyjrzymy się, jak wdrożyć adres o dużym natężeniu ruchu. z istniejącego potoku danych. Dzięki temu możesz: przechowywać określone pola z odpowiedzi interfejsu Address Validation API w Warunkach korzystania z w sposób zgodny z przepisami dotyczącymi usług.

Diagram A. Poniższy schemat przedstawia, jak można ulepszyć potok danych korzystając z logiki dużej walidacji adresów.

alt_text

Zgodnie z Warunkami korzystania z usługi możesz przechowywać w pamięci podręcznej te dane addressComponent:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

Dlatego na tym etapie implementacji zapiszemy powyższe elementy w pamięci podręcznej. z wartością UserID.

Aby dowiedzieć się więcej o rzeczywistych danych, .

Krok 2.

W kroku 1 zebraliśmy opinie, że niektóre adresy w wejściowym zbiorze danych mogą nie są wysokiej jakości. W następnym kroku użyjemy oznaczonych adresów i przedstaw je użytkownikowi i uzyskaj jego zgodę na poprawienie adresu.

Schemat B: przedstawia pełną integrację użytkownika. proces uzyskiwania zgody może wyglądać tak:

alt_text

  1. Gdy użytkownik się loguje, najpierw sprawdź, czy masz w pamięci podręcznej jakieś flagi weryfikacji w Twoim systemie.
  2. Jeśli dostępne są flagi, należy udostępnić użytkownikowi interfejs, który pozwala skorygować zaktualizować swój adres.
  3. Możesz ponownie wywołać interfejs Address Validation API, używając zaktualizowanej lub zapisanej w pamięci podręcznej i pokazać użytkownikowi poprawny adres w celu potwierdzenia.
  4. Jeśli adres ma dobrą jakość, interfejs Address Validation API zwraca błąd formattedAddress
  5. Możesz zaprezentować ten adres użytkownikowi, jeśli zostały wprowadzone poprawki lub zaakceptować dyskretnie, jeśli nie będzie żadnych poprawek.
  6. Gdy użytkownik wyrazi zgodę, możesz buforować formattedAddress w bazie danych.
.

Podsumowanie

Duża weryfikacja adresów to typowy przypadek użycia w wielu zastosowaniach. W tym dokumencie podjęto próbę zademonstrowania niektórych scenariuszy oraz wzoru wdrożenia takiego rozwiązania zgodnego z Mapami Google Warunki korzystania z Platformy.

Napisaliśmy również referencyjną implementację adresu do dużych ilości danych Weryfikacja jako biblioteka open source na GitHubie. Na początek zapoznaj się z informacjami podczas dużej weryfikacji adresów. Przeczytaj też artykuł na temat korzystania z biblioteki w różnych sytuacjach.

Następne kroki

Pobierz dokument Usprawnij proces płatności, dostawy i operacji dzięki niezawodnym adresom Dokument i przejdź do sekcji Usprawnianie procesu płatności, dostawy i operacji za pomocą Adresu Weryfikacja Webinar.

Sugerujemy dodatkowe artykuły:

Współtwórcy

Ten artykuł jest prowadzony przez Google. Poniżsi współtwórcy są autorami tych treści.
Główni autorzy:

Henrik Valve | Inżynier ds. rozwiązań
Thomas Anglaret | Rozwiązania Inżynier
Sarthak Ganguly | Rozwiązania Inżynier