Руководство по Address Validation для больших объемов данных

Цель

Разработчикам часто приходится работать с наборами данных, содержащими адреса клиентов, которые могут быть некачественными. Вам необходимо убедиться, что адреса указаны правильно для различных вариантов использования, от проверки идентификатора клиента до доставки и многого другого.

Address Validation API – это продукт платформы Google Карт, который можно использовать для проверки адресов. Однако он обрабатывает только один адрес за раз. В этом документе мы рассмотрим, как использовать High Volume Address Validation в разных сценариях – от тестирования API до однократной и регулярной проверки адресов.

Примеры использования

Теперь мы рассмотрим сценарии использования, в которых High Volume Address Validation может быть полезен.

Тестирование

Часто требуется протестировать Address Validation API, выполнив проверку тысяч адресов. Например, у вас есть адреса в CSV-файле и вы хотите проверить их качество.

Однократная проверка адресов

При регистрации в Address Validation API вы хотите проверить существующую базу данных адресов по базе данных пользователей.

Повторяющаяся проверка адресов

Вот несколько сценариев, в которых требуется регулярная проверка адресов:

  • Вы можете запланировать задания по проверке адресов, полученных в течение дня, например при регистрации клиентов, оформлении заказов или составлении графиков доставки.
  • Вы можете получать дампы данных, содержащие адреса из разных отделов, например, от продаж до маркетинга. Новый отдел, получающий адреса, часто хочет проверить их перед использованием.
  • Вы можете собирать адреса во время опросов или различных рекламных акций, а затем обновлять их в онлайн-системе. Вы хотите проверять правильность адресов при их вводе в систему.

Технический анализ

В этом документе предполагается, что:

  • Вы вызываете Address Validation API с адресами из базы данных клиентов (т. е. базы данных с информацией о клиентах).
  • Вы можете кешировать флаги действительности для отдельных адресов в своей базе данных.
  • Пометки о действительности адреса извлекаются из Address Validation API, когда клиент входит в систему.

Кеширование для рабочих целей

При использовании Address Validation API часто требуется кешировать часть ответа на вызов API. Хотя наши Условия использования ограничивают типы данных, которые можно кешировать, любые данные, которые можно кешировать из Address Validation API, должны кешироваться в аккаунте пользователя. Это означает, что в базе данных адрес или метаданные адреса должны быть кешированы по адресу электронной почты пользователя или другому основному идентификатору.

При использовании High Volume Address Validation кеширование данных должно выполняться в соответствии с Условиями использования сервиса Address Validation API, описанными в разделе 11.3. На основе этой информации вы сможете определить, является ли адрес пользователя недействительным, и в этом случае попросить пользователя указать правильный адрес при следующем взаимодействии с вашим приложением.

  • Данные из объекта AddressComponent
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

Если вы хотите кешировать какую-либо информацию о фактическом адресе, то эти данные должны кешироваться только с согласия пользователя. Это гарантирует, что пользователь понимает, почему определенный сервис хранит его адрес, и согласен с условиями передачи адреса.

Примером согласия пользователя может быть прямое взаимодействие с формой адреса электронной торговли на странице оформления покупки. Вы можете кешировать и обрабатывать адрес для доставки посылки.

С согласия пользователя вы можете кешировать formattedAddress и другие ключевые компоненты ответа. Однако в сценарии без пользовательского интерфейса пользователь не может дать согласие, поскольку проверка адреса выполняется из серверной части. Поэтому в таком сценарии вы можете кешировать очень ограниченный объем информации.

Как интерпретировать ответ

Если ответ Address Validation API содержит следующие маркеры, вы можете быть уверены, что введенный адрес пригоден для доставки:

  • Маркер addressComplete в объекте Verdict имеет значение true.
  • Значение validationGranularity в объекте Verdict – PREMISE или SUB_PREMISE.
  • Ни один из объектов AddressComponent не помечен как:
    • Inferred(Примечание.: inferred=trueможет произойти, когда addressComplete=true)
    • spellCorrected
    • replaced
    • unexpected и
  • confirmationLevel: уровень подтверждения в AddressComponent задан как CONFIRMED или UNCONFIRMED_BUT_PLAUSIBLE.

Если ответ API не содержит указанных выше маркеров, то входной адрес, скорее всего, был низкого качества, и вы можете кэшировать флаги в своей базе данных, чтобы отразить это. Пометки о кешировании указывают на то, что адрес в целом низкого качества, а более подробные пометки, такие как "Исправлена орфография", указывают на конкретный тип проблемы с качеством адреса. При следующем взаимодействии с клиентом, адрес которого помечен как некачественный, вы можете вызвать Address Validation API с существующим адресом. Address Validation API вернет исправленный адрес, который можно показать в интерфейсе. После того как клиент примет отформатированный адрес, вы можете кешировать следующие данные из ответа:

  • formattedAddress
  • postalAddress
  • addressComponent componentNames или
  • UspsData standardizedAddress

Как реализовать проверку адреса без интерфейса

На основе обсуждения выше:

  • Часто по коммерческим причинам требуется кешировать часть ответа Address Validation API.
  • Однако Условия использования платформы Google Карт ограничивают типы данных, которые можно кешировать.

В следующем разделе мы обсудим двухэтапный процесс, позволяющий соблюдать Условия использования и выполнять проверку адресов в больших объемах.

Шаг 1.

На первом этапе мы рассмотрим, как реализовать скрипт проверки адресов в больших объемах из существующего конвейера данных. Это позволит вам хранить определенные поля из ответа Address Validation API в соответствии с Условиями использования.

Диаграмма А. На следующей диаграмме показано, как можно улучшить конвейер данных с помощью логики High Volume Address Validation.

alt_text

Согласно Условиям использования, вы можете кешировать следующие данные из addressComponent:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

Таким образом, на этом этапе реализации мы будем кэшировать вышеупомянутые поля в соответствии с UserID.

Подробную информацию вы найдете в разделе Структура данных.

Шаг 2.

На шаге 1 мы получили отзывы о том, что некоторые адреса во входном наборе данных могут быть невысокого качества. На следующем шаге мы покажем пользователю помеченные адреса и попросим его подтвердить исправление сохраненного адреса.

Диаграмма Б. На этой диаграмме показано, как может выглядеть сквозная интеграция процесса получения согласия пользователя.

alt_text

  1. При входе пользователя в систему сначала проверьте, есть ли в ней кешированные флаги подтверждения.
  2. Если пометки есть, покажите пользователю интерфейс, в котором он сможет исправить и обновить адрес.
  3. Вы можете снова вызвать Address Validation API с обновленным или кешированным адресом и показать пользователю исправленный адрес для подтверждения.
  4. Если адрес качественный, Address Validation API возвращает formattedAddress.
  5. Вы можете показать пользователю исправленный адрес или, если исправлений не было, принять его без уведомления.
  6. После того как пользователь примет запрос, вы можете кешировать formattedAddress в базе данных.

Заключение

Проверка адресов в больших объемах – это распространенный сценарий использования, с которым вы, скорее всего, столкнетесь во многих приложениях. В этом документе мы рассмотрим несколько сценариев и шаблон проектирования, которые помогут вам реализовать такое решение в соответствии с Условиями использования платформы Google Карт.

Мы также написали эталонную реализацию High Volume Address Validation в виде библиотеки с открытым исходным кодом на GitHub. Ознакомьтесь с ним, чтобы быстро начать работу с High Volume Address Validation API. Также ознакомьтесь со статьей о шаблонах проектирования, в которой рассказывается, как использовать библиотеку в разных сценариях.

Дальнейшие действия

Скачайте технический документ Проверка адресов снижает вероятность ошибок при оформлении и доставке покупок и посмотрите вебинар Проверка адресов снижает вероятность ошибок при оформлении и доставке покупок .

Дополнительные сведения

Авторы

Google поддерживает эту статью. Ниже перечислены авторы, которые изначально написали его.
Основные авторы:

Хенрик Вальве (Henrik Valve) | инженер по решениям
Тома Англаре (Thomas Anglaret) | инженер по решениям
Сартак Гангули (Sarthak Ganguly) | инженер по решениям