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

В этом документе описывается ряд реальных сценариев, в которых 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
}

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

Совет: проверьте правильный адрес в демо-версии , указав 451 7th Avenue South, Kirkland, WA 98033, чтобы увидеть ответ на первоначально предполагаемый адрес.

Действие: Подтвердите ввод адреса у клиента.

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

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

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

Незначительные выводы, которые ПОДТВЕРЖДЕНЫ

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

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

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

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

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

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

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

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

Адрес введен	Область
1 Rue Grenache, la Caritat 2, 34630 Сен-Тибери	Франция

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

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

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

"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",

Сканирование на наличие неподтвержденных компонентов показывает, что API удалил la caritat 2 из возвращенного адреса:

{
  "componentName": {
    "text": "la caritat 2",
    "languageCode": "fr"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

Действие: Подтвердите. В этом случае сублокация, которая может указывать на жилой район или район, может быть правильной, но все равно игнорироваться почтовой службой. Однако, учитывая, что эта информация **не** подтверждена API проверки адреса, имеет смысл уточнить это у клиента. На этом этапе вы либо игнорируете удаление, либо подтверждаете его.

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

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

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

Адрес введен	Область
33 Dunalley St, Челтнем, Глостершир, GL50 4AP	Великобритания

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

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

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

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

Этот компонент является одновременно неожиданным и подтвержденным, что означает следующее:

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

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

Действие: Для этого сценария рекомендуемым действием является игнорировать этот сигнал и принять адрес.