Используйте API проверки адресов для обработки адресов в больших объемах.

Цель

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

API проверки адресов — это продукт платформы Google Maps, который можно использовать для проверки адресов. Однако он обрабатывает только один адрес за раз. В этом документе мы рассмотрим, как использовать API для проверки адресов в больших объемах в различных сценариях, от тестирования API до разовой и повторяющейся проверки адресов.

Варианты использования

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

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

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

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

При подключении к API проверки адресов вам потребуется проверить существующую базу данных адресов на соответствие базе данных пользователей.

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

Ряд сценариев требует регулярной проверки адресов:

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

Технический подробный анализ

Для целей настоящего документа мы исходим из того, что:

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

Кэш для использования в производственной среде

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

Для сценария использования проверки адресов в больших объемах кэширование данных должно соответствовать специфическим условиям использования сервиса API проверки адресов, изложенным в разделе 11.3. На основе этой информации вы сможете определить, является ли адрес пользователя недействительным, и в этом случае вам будет предложено ввести исправленный адрес при следующем взаимодействии пользователя с вашим приложением.

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

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

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

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

Поймите ответ

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

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

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

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

Реализуйте проверку адресов в безголовом режиме.

Исходя из вышеизложенного обсуждения:

• По бизнес-целям часто возникает необходимость кэшировать часть ответа от API проверки адресов.
• Однако условия использования платформы Google Maps ограничивают объем данных, которые могут быть кэшированы.

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

Шаг 1:

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

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

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

• confirmationLevel
• inferred
• spellCorrected
• replaced
• unexpected

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

Для получения более подробной информации см. описание фактической структуры данных .

Шаг 2:

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

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

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

Заключение

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

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

Следующие шаги

Загрузите документ «Улучшение процесса оформления заказа, доставки и операций с помощью надежных адресов» и посмотрите вебинар « Улучшение процесса оформления заказа, доставки и операций с помощью проверки адресов» .

Рекомендуемая дополнительная литература:

• Применение высокопроизводительной проверки адресов
• Библиотека Python на GitHub
• Ознакомьтесь с демонстрацией проверки адресов.

Авторы

Данная статья поддерживается компанией Google. Ее первоначальный автор — следующие лица.
Основные авторы:

Хенрик Вальв | Инженер по решениям
Томас Англаре | Инженер по решениям
Сартак Гангули | Инженер по решениям