Выберите решение для проверки адреса

Цель

Проверка адреса обеспечивает ценность для различных вариантов использования, и есть ключевые соображения, выходящие за рамки чистого качества результатов тестирования, которые мы предлагаем вам изучить. Например: целостный взгляд на совместимые продукты в потоке пользователя, такие как Place Autocomplete и Maps , региональная доступность, а также доверие и надежность предприятия .

Как только вы приступите к оценке API проверки адресов, вот несколько рекомендаций, которые мы рекомендуем вам использовать в ходе тестирования.

Целями этого теста будут:

1. Подтвердите, что API проверки адреса подходит для вашего варианта использования.
2. Проверьте, насколько API проверки адресов соответствует требованиям вашего решения, таким как:
   • Определение качественных адресов.
   • Оповещение для устранения некачественных данных.
   • Внесение исправлений в адресные данные, включая выводы, замены и исправления орфографии.
   • Предоставление отформатированного адреса для доставки.
   • Оповещение об отсутствующих или неверных данных субпомещений (только для США).
3. Убедитесь, что вы получите ощутимую выгоду от внедрения API.

После проведения теста вы сможете ответить на вышеуказанные вопросы и определить, подходит ли API для вашего бизнеса.

Подготовьте ваши данные

Ваш тест должен быть выполнен на основе выборки ваших существующих адресных данных. Не выбирайте данные для теста вручную, а выбирайте случайные выборки, которые являются репрезентативными для регионов, в которых вы работаете. Это означает, что если вы работаете и в Соединенных Штатах, и в Соединенном Королевстве, но 70% вашего бизнеса осуществляется в Великобритании, а 30% — в США, выборка должна отражать это разделение.

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

Подготовьте для теста выборку объемом около 5000–10 000 записей.

Вызов API

Предварительное условие раздела: Понять, как отправить запрос на проверку адреса .

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

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

Результатом этого шага должны стать выходные данные API для каждой адресной записи. Затем вы сможете проанализировать результаты, чтобы определить пригодность API для вашего варианта использования. Будет ли это использование электронной таблицы, базы данных или другого инструмента — решать вам.

Просмотрите результаты

Предварительное условие раздела: Понять, как обрабатывать ответ проверки , особенно концепции «Исправить», «Подтвердить» и «Принять» .

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

Обзор ключевых полей API, обсуждаемых в этом документе

Проверьте действительные адреса

Отсортируйте возвращаемые данные из API, чтобы определить набор адресов, которые ваша система будет принимать как допустимые. Ключевые сигналы, на которые следует обратить внимание в API:

• verdict.validationGranularity содержит PREMISE или лучше.
• verdict.addressComplete имеет true .
• Никаких предполагаемых или замененных компонентов.

Более подробную информацию см. в разделе «Принять адрес» .

Результатом этого упражнения должно быть подмножество адресных данных, которые будут приняты вашей системой как действительные. На этом этапе вы можете определить:

• Приемлем ли процент принятия?
• Если вы используете существующий процесс проверки адресов, является ли процент принятых заявок таким же или выше?

Пример: Действительный адрес

Вердикт

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true
}

Просмотреть недействительные адреса

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

Отсортируйте возвращаемые данные из API, чтобы определить набор адресов, которые ваша система пометит как недействительные. Ключевые сигналы, на которые следует обратить внимание в API:

• verdict.validationGranularity устанавливается на OTHER или ROUTE в зависимости от вашего уровня риска .
• verdict.addressComplete имеет значение false .

Более подробную информацию см. в разделе «Исправление адреса» .

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

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

Пример: Неверный адрес

Вердикт

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true
}

Обзор отсутствующих или неподтвержденных компонентов

На этом этапе также можно просмотреть отсутствующие или неподтвержденные компоненты. Это часть объекта Address в возврате. Два поля — missingComponentTypes и unconfirmedComponentTypes .

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

Пример: Отсутствующий и неподтвержденный компонент

Вердикт

{
     "inputGranularity": "ROUTE",
     "validationGranularity": "OTHER",
     "geocodeGranularity": "OTHER",
     "hasUnconfirmedComponents": true
}

Отсутствующие и неподтвержденные компоненты

"missingComponentTypes": [
    "street_number"
],
"unconfirmedComponentTypes": [
    "route"
]

Просмотреть адреса с исправлениями

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

Ключевые сигналы, на которые следует обратить внимание:

• Для любого из addressComponents установлено значение true inferred , replaced или spellCorrected .
• verdict.hasInferredComponents или verdict.hasReplacedComponents установлены в true .

Более подробную информацию см. в разделе «Подтверждение адреса» .

Результатом этого упражнения должно стать подмножество адресных данных, к которым API применил исправление.

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

Пример: Адрес с исправлением

Адрес addressComponent

{
    "componentName": {
        "text": "Buckingham Palace Road",
        "languageCode": "en"
    },
    "componentType": "route",
    "confirmationLevel": "CONFIRMED",
    "spellCorrected": true
}

[Только для США] Проверьте адрес с отсутствующими или неверными данными о субпредприятии

API проверки адресов позволяет определить, отсутствует ли подпомещение или оно неверно для адресов в США.

Ключевые сигналы, на которые следует обратить внимание:

• В объекте Адрес :
  • unconfirmedComponentTypes содержит subpremise
  • missingComponentTypes содержит subpremise
• В объекте UspsData :
  • dpvConfirmation — D (отсутствует подпомещение)
  • dpvConfirmation — S (подпосылка неподтверждена)

Более подробную информацию см. в разделе «Адреса в США» .

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

Пример: отсутствует подпредпосылка

Отсутствует компонент

"missingComponentTypes": [
    "subpremise"
]

Данные USPS DPV подтверждение

"dpvConfirmation": "D"

[Только для США] Обзор USPS standardizedAddress

API проверки адресов также возвращает стандартизированный адрес USPS для адресов в Соединенных Штатах. Это особенно важно, если вам необходимо, чтобы на ваших транспортных этикетках печатались адреса в формате USPS.

UspsAddress можно просмотреть, чтобы просмотреть эти данные и определить, добавляют ли они ценность вашему рабочему процессу.

Пример: стандартизированный адрес USPS

"standardizedAddress": {
    "firstAddressLine": "111 8TH AVE FL 11",
    "cityStateZipAddressLine": "NEW YORK NY 10011-5201",
    "city": "NEW YORK",
    "state": "NY",
    "zipCode": "10011",
    "zipCodeExtension": "5201"
}

Заключение

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

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

• Документация разработчика API проверки адресов
• Используйте API проверки адресов для обработки больших объемов адресов
• Проверка адреса для оформления заказа в электронной торговле

Участники

Хенрик Валв | Инженер DevX