Руководство по 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 не содержит указанных выше маркеров, то, скорее всего, введенный адрес был низкого качества, и вы можете кэшировать флаги в своей базе данных, чтобы отразить это. Пометки Cached указывают на то, что адрес в целом низкого качества, а более подробные пометки, такие как Spell Corrected, указывают на конкретный тип проблемы с качеством адреса. При следующем взаимодействии с клиентом, адрес которого помечен как некачественный, вы можете вызвать 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

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

Подробнее о структуре данных…

Шаг 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 поддерживает эту статью. The following contributors originally wrote it.
Основные авторы:

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