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, które mogą być niskiej jakości. Zadbaj o to, aby adresy były poprawne w przypadku różnych zastosowań – od weryfikacji identyfikatora klienta po dostarczanie dokumentów.

Interfejs API do weryfikacji adresów to usługa Google Maps Platform, która służy do weryfikowania adresu. Jednorazowo przetwarza jednak tylko 1 adres. Z tego dokumentu dowiesz się, jak korzystać z walidacji dużej ilości adresów w różnych scenariuszach, od testowania interfejsów API po jednorazową i cykliczną weryfikację adresów.

Przykłady zastosowań

Teraz poznamy przypadki użycia, w których przydatna jest weryfikacja adresów o dużej liczbie adresów.

Testowanie

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

Jednorazowa weryfikacja adresów

Podczas rozpoczynania pracy z interfejsem Address Verification API chcesz sprawdzić, czy Twoja istniejąca baza danych adresów korzysta z bazy danych użytkowników.

Cykliczna weryfikacja adresów

Istnieje wiele scenariuszy wymagających cyklicznego weryfikowania adresów:

  • Możesz mieć zaplanowane zadania do weryfikacji adresów na potrzeby weryfikacji szczegółów rejestrowanych w ciągu dnia, np. rejestracji klientów, szczegółów zamówień czy harmonogramów dostaw.
  • Możesz otrzymywać zrzuty danych z adresami różnych działów, np. działu sprzedaży po marketing. Nowy dział odbierający adresy często chce je zweryfikować przed użyciem.
  • Możesz zbierać adresy podczas ankiet i różnych promocji, a później aktualizować je w systemie online. Chcesz sprawdzić, czy adresy są prawidłowe, podczas wpisywania ich w systemie.

Szczegółowe informacje techniczne

Na potrzeby tego dokumentu zakładamy, że:

  • Wywołujesz interfejs Address Verificationation API z adresami z bazy danych klienta (np.z bazy danych z informacjami o kliencie).
  • Możesz buforować flagi ważności dla poszczególnych adresów w swojej bazie danych.
  • Flagi ważności są pobierane z interfejsu Address Billingation API, gdy loguje się dany klient.

Pamięć podręczna do użytku produkcyjnego

Podczas korzystania z interfejsu Address Verification API często chcesz zachować w pamięci podręcznej część odpowiedzi z wywołania interfejsu API. Warunki korzystania z usługi ograniczają zakres danych, które można przechowywać w pamięci podręcznej, ale wszelkie dane, które można przechowywać w pamięci podręcznej interfejsu Address Verificationation API, muszą być przechowywane w pamięci podręcznej na koncie użytkownika. Oznacza to, że w bazie danych adres lub metadane adresu muszą być przechowywane w pamięci podręcznej wraz z adresem e-mail użytkownika albo z innym podstawowym identyfikatorem.

W przypadku walidacji adresów dużej ilości danych przechowywanie danych w pamięci podręcznej musi być zgodne z warunkami korzystania z usługi określonymi w sekcji 11.3 interfejsu Address Billing. Na podstawie tych informacji możesz określić, czy adres użytkownika jest nieprawidłowy. W takim przypadku przy kolejnej interakcji z aplikacją poprosimy go o poprawienie adresu.

  • Dane z obiektu AddressComponent
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

Jeśli chcesz przechowywać w pamięci podręcznej jakiekolwiek informacje dotyczące rzeczywistego adresu, musisz je przechowywać w pamięci podręcznej tylko za zgodą użytkownika. Dzięki temu użytkownik wie, dlaczego dana usługa przechowuje jego adres, i akceptuje warunki udostępniania adresu.

Przykładem zgody użytkownika może być bezpośrednia interakcja z formularzem adresu e-commerce na stronie płatności. Musisz rozumieć, że adres będzie buforowany i przetwarzany na potrzeby wysyłki przesyłki.

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

Interpretowanie odpowiedzi

Jeśli odpowiedź interfejsu Address Verification API zawiera te znaczniki, możesz mieć pewność, że adres wejściowy ma wysoką jakość:

  • Znacznik addressComplete w obiekcie Wynik to true,
  • validationGranularity w obiekcie Wynik to PREMISE lub SUB_PREMISE
  • Żaden z elementów AddressComponent nie jest oznaczony jako:
    • Inferred(Uwaga: inferred=truemoże wystąpić, gdy addressComplete=true)
    • spellCorrected
    • replaced
    • unexpected i
  • confirmationLevel: Poziom potwierdzenia AddressComponent jest ustawiony na CONFIRMEDlubUNCONFIRMED_BUT_PLAUSIBLE

Jeśli odpowiedź interfejsu API nie zawiera powyższych znaczników, adres wejściowy prawdopodobnie ma niską jakość, więc możesz umieścić w pamięci podręcznej flagi, aby to odzwierciedlić. Flagi z pamięci podręcznej wskazują, że cały adres ma niską jakość, a bardziej szczegółowe flagi, takie jak poprawiona pisownia, wskazują konkretny typ problemu z jakością adresu. Przy następnej interakcji klienta z adresem oznaczonym jako niskiej jakości możesz użyć istniejącego adresu w interfejsie API do weryfikacji adresów. Interfejs Address Review API zwraca poprawiony adres, który możesz wyświetlić za pomocą promptu w interfejsie. Gdy klient zaakceptuje sformatowany adres, z odpowiedzi możesz buforować:

  • formattedAddress
  • postalAddress
  • addressComponent componentNames lub
  • UspsData standardizedAddress

Wdrażanie weryfikacji adresu bez interfejsu graficznego

Na podstawie dyskusji powyżej:

  • Ze względów biznesowych często konieczne jest zapisywanie w pamięci podręcznej pewnej części odpowiedzi z interfejsu AddressValidation API.
  • Jednak Warunki korzystania z usługi w Google Maps Platform ograniczają, jakie dane można przechowywać w pamięci podręcznej.

W tej sekcji omówimy dwuetapowy proces zapewniania zgodności z Warunkami korzystania z usługi i wdrażania dużej liczby adresów.

Krok 1.

W pierwszym kroku pokażemy, jak wdrożyć skrypt weryfikacji adresów o dużej ilości danych z istniejącego potoku danych. Ten proces pozwoli Ci przechowywać określone pola z odpowiedzi interfejsu Address Review API w sposób zgodny z Warunkami korzystania z usługi.

Diagram A: na diagramie poniżej widać, jak można ulepszyć potok danych za pomocą logiki walidacji adresów dużej ilości danych.

alt_text

Zgodnie z Warunkami korzystania z usługi możesz buforować te dane z addressComponent:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

Dlatego na tym etapie implementacji będziemy zapisywać w pamięci podręcznej wymienione wyżej pola związane z identyfikatorem UserID.

Więcej informacji o rzeczywistej strukturze danych znajdziesz w artykule o rzeczywistej strukturze danych.

Krok 2.

W kroku 1 zebraliśmy opinie, że niektóre adresy w wejściowym zbiorze danych mogą nie być wysokiej jakości. W następnym kroku wybierzemy oznaczone adresy i wyświetlimy je użytkownikowi oraz uzyskamy ich zgodę na poprawienie zapisanego adresu.

Diagram B: ten schemat przedstawia, jak może wyglądać kompleksowa integracja procesu uzyskiwania zgody użytkownika:

alt_text

  1. Gdy użytkownik się loguje, najpierw sprawdź, czy w pamięci podręcznej znajdują się flagi weryfikacji.
  2. Jeśli występują flagi, należy wyświetlić użytkownikowi interfejs, w którym będzie mógł poprawić i zaktualizować adres.
  3. Możesz ponownie wywołać interfejs Address Billingation API za pomocą zaktualizowanego lub zapisanego adresu w pamięci podręcznej, a następnie przedstawić użytkownikowi poprawiony adres, aby mógł go potwierdzić.
  4. Jeśli adres jest dobrej jakości, interfejs Address Verificationation API zwraca błąd formattedAddress.
  5. Możesz przedstawić ten adres użytkownikowi, jeśli wprowadzisz poprawki, lub dyskretnie zaakceptować, jeśli nie ma żadnych poprawek.
  6. Gdy użytkownik zaakceptuje prośbę, możesz buforować formattedAddress w bazie danych.

Podsumowanie

Weryfikacja adresów dużej liczby adresów to typowy przypadek użycia, który może występować w wielu aplikacjach. W tym dokumencie próbujemy zademonstrować kilka scenariuszy i wzorzec projektowy wdrażania takiego rozwiązania zgodnego z Warunkami korzystania z platformy Mapy Google.

Opracowaliśmy również referencyjną wdrożenie weryfikacji adresów wielu adresów w postaci biblioteki open source w GitHubie. Skorzystaj z niej, aby szybko zacząć tworzyć walidację adresów na dużą skalę. Przeczytaj też artykuł o wzorcach korzystania z biblioteki w różnych sytuacjach.

Dalsze kroki

Pobierz dokument Usprawnij proces płatności, dostawy i operacji dzięki wiarygodnym adresom i obejrzyj webinar o udoskonalaniu procesu płatności, dostawy i działań za pomocą weryfikacji adresów .

Sugerowana dalsza analiza:

Współtwórcy

Google przechowuje ten artykuł. Następujący współtwórcy napisali go pierwotnie.
Główne autorzy:

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