Эта страница переведена с помощью Cloud Translation API.

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

Блок-схема, показывающая общий обзор этапов тестирования.

Цель

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

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

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

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

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

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

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

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

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

Вызов API

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

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

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

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

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

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

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

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

Данные ответа	Что это такое?	Как оценить	Как это помогает?
verdict.inputGranularity	Описывает степень детализации ввода адреса.	SUB_PREMISE ПРЕДПОСЫЛКА PREMISE_PROXIMITY БЛОКИРОВАТЬ МАРШРУТ ДРУГОЙ	Позволяет определить, содержит ли входной адрес достаточно данных, чтобы считаться потенциально допустимым.
verdict.validationGranularity	Описывает общую проверку выходных данных адреса.	SUB_PREMISE ПРЕДПОСЫЛКА PREMISE_PROXIMITY БЛОКИРОВАТЬ МАРШРУТ ДРУГОЙ	Позволяет определить общее качество адреса на выходе API.
verdict.hasInferredComponents	Сигнализирует, что API вывел компонент.	Верно/неверно	API может добавлять недостающие компоненты, позволяя вывести данные. Например, отсутствующий код штата.
verdict.hasReplacedComponents	Сигнализирует, что API заменил компонент.	Верно/неверно	В некоторых сценариях API позволяет заменять неверные компоненты правильными данными.
verdict.addressComplete	Сигнализирует, что адрес полный.	Верно/неверно	Если API определит, что выходной адрес содержит все необходимые компоненты, это будет верно.
address.missingComponentTypes	Сигнал, предупреждающий об отсутствии в адресе компонентов.	Значения см . в таблице 2 .	Выделите недостающие компоненты в неполном адресе.

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

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

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

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

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

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

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

Адрес введен	Область
76 Buckingham Palace Road, Лондон SW1W 9TQ	Великобритания

Вердикт

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

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

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

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

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

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

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

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

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

Адрес введен	Область
21 45 40-я улица	США

Вердикт

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

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

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

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

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

Адрес введен	Область
Фейк-стрит, Нью-Йорк, штат Нью-Йорк, 10011	США

Вердикт

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

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

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

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

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

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

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

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

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

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

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

Адрес введен	Область
76 Брукингем Пэлас Роуд, Лондон SW1W 9TQ	Великобритания

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

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

Адрес введен	Область
111 8-я Авеню, Манхэттен, Нью-Йорк 10011	НАС

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

"missingComponentTypes": [
    "subpremise"
]

Подтверждение DPV данных USPS

"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 проверки адресов пользу вашему рабочему процессу.

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

Авторы

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

Выберите решение для проверки адреса Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Цель

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

Вызов API

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

Авторы

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