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

Подтвердить адрес – примеры

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

Распространенные примеры: подтвердить

Следующий пример иллюстрирует случай мегаполисов со схожими названиями улиц. Предположим, пользователь хочет ввести адрес здания Google Building D в Киркленде, штат Вашингтон, США . Однако вместо Киркленда в качестве города он по ошибке вводит Сиэтл .

Введенный адрес	Область
Здание D, 451 7th Avenue South, Сиэтл, штат Вашингтон 98033	НАС

Вердикт по поводу замененных данных

Приведенный ниже пример подчеркивает важные сигналы, получаемые в результате ответа.

{
  "inputGranularity": "SUB_PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete": true,
  "hasUnconfirmedComponents": true
  "hasReplacedComponents": true,
  "possibleNextAction": "CONFIRM"
}

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

Анализ компонентов адреса выявляет следующие проблемные области:

{
  "componentName": {
    "text": "451",
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
  "componentName": {
    "text": "98104",
  },
  "componentType": "postal_code",
  "confirmationLevel": "CONFIRMED",
  "replaced": true
}
...
{
  "componentName": {
    "text": "Building D",
    "language_code": "en"
  },
  "componentType": "subpremise",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......

    "unconfirmedComponentTypes": [
      "street_number",
      "subpremise"
    ]

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

Примеры крайних случаев: подтвердить

Следующие примеры иллюстрируют следующие типы граничных случаев:

Незначительные выводы, которые ПОДТВЕРЖДАЮТСЯ . API проверки адресов определяет страну, почтовый индекс или штат, но все остальное предоставляется и подтверждается. Сочетание детализации и уровня подтверждения делает незначительный вывод не обязательно требующим подтверждения.
Неожиданный компонент адреса НЕ подтвержден . Неподтвержденные компоненты адреса повышают уровень риска. Это может потребовать подтверждения.
Неожиданный компонент адреса, который ПОДТВЕРЖДЕН . Этот компонент не является строго необходимым для корректного адреса, и API проверки адресов удаляет его из выходных данных. Проблемы с форматированием обычно не требуют подтверждения.

Незначительные выводы, которые подтверждаются.

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

Город
Состояние
Почтовый индекс
Страна

Например, клиент указывает действительный адрес ресторана McDonald's в Спрингфилде, штат Массачусетс, но забывает указать город и вводит почтовый индекс без 4-значного расширения.

Введенный адрес	Область
1402 Аллен-стрит, Массачусетс 01118	НАС

Вердикт по делу о пропавшем городе

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true,
  "hasInferredComponents": true,
  "possibleNextAction": "CONFIRM"
}

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

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

{
  "componentName": {
    "text": "Springfield",
    "languageCode": "en"
  },
  "componentType": "locality",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
},
{
  "componentName": {
    "text": "1806"
  },
  "componentType": "postal_code_suffix",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
}

Неожиданный компонент адреса НЕ подтвержден

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

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

Введенный адрес	Область
59 Черридаун Авеню, Чингфорд, Лондон E4 8DT	Великобритания

Вердикт по неожиданному компоненту адреса не подтвержден.

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "unconfirmedComponents": true,
  "possibleNextAction": "ACCEPT"
}

Помимо вердикта с неподтвержденными компонентами, API проверки адресов возвращает адрес в следующем формате:

"formattedAddress": "59 Cherrydown Avenue, London E4 8DT, UK",

Проверка на наличие неподтвержденных компонентов показывает, что API удалил Чингфорда из возвращаемого адреса:

{
  "componentName": {
    "text": "Chingford",
    "languageCode": "en"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

Неожиданный компонент адреса, который подтвержден

Этот пример иллюстрирует включение названия графства Великобритании в указанный адрес, что является распространенной практикой. Однако это не является требованием почтовой службы Великобритании и, по сути, игнорируется. См. postoffice.co.uk и «Как правильно оформлять почту в Великобритании и за рубежом» .

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

Введенный адрес	Область
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP	Великобритания

Вердикт по неожиданному компоненту адреса, который подтвержден.

{
   "inputGranularity": "PREMISE",
   "validationGranularity": "PREMISE",
   "geocodeGranularity": "PREMISE",
   "possibleNextAction": "ACCEPT"
}

В данном случае address_complete возвращает false, а анализ компонента адреса выявляет неожиданный флаг.

{
  "componentName": {
    "text": "Gloucestershire",
    "languageCode": "en"
  },
  "componentType": "administrative_area_level_2",
  "confirmationLevel": "CONFIRMED",
  "unexpected": true
}

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