Confirmar dirección (ejemplos)

En este documento, se describen varias situaciones del mundo real en las que la API de Address Validation proporciona indicadores de respuesta para direcciones que podrían garantizar un comportamiento de confirmación de tu sistema. Consulta la descripción general del flujo de trabajo en Crea tu lógica de validación para obtener contexto.

Nota: Los ejemplos que se muestran aquí son ilustrativos, pero no abarcan todas las situaciones.

Ejemplos comunes: confirmar

En el siguiente ejemplo, se ilustra el caso de las áreas metropolitanas con nombres de calles similares. Supongamos que un usuario desea ingresar la dirección del Edificio D de Google en Kirkland, Washington, Estados Unidos. Sin embargo, en lugar de Kirkland como ciudad, ingresa Seattle por error.

Dirección ingresada	Región
Edificio D, 451 7th Avenue South, Seattle, WA 98033	EE.UU.

Veredicto para los datos reemplazados

En el siguiente ejemplo, se enfatizan los indicadores importantes de la respuesta.

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

El possibleNextAction proporciona una indicación inicial de que podría ser conveniente confirmar la dirección con tu cliente. Los otros indicadores del veredicto proporcionan más detalles sobre lo que podría estar mal con la dirección. PREMISE_PROXIMITY indica la proximación de una dirección a nivel del edificio, pero no es tan detallada como SUB_PREMISE, que es el nivel de detalle proporcionado en la entrada. La respuesta también contiene componentes confirmados y reemplazados.

Una consulta de los componentes de la dirección revela las siguientes áreas de preocupación:

{
  "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"
    ]

En este caso, la API de Address Validation encontró una aproximación cercana a la dirección proporcionada en Seattle y reemplazó el código postal, un componente de nivel superior, para resolver una dirección de Seattle. Este podría ser un reemplazo válido, pero, además del hecho de que los componentes no se confirmaron, tiene sentido asegurarse de que el usuario tenga la intención de ingresar una dirección de Seattle y no otra, como Kirkland.

Sugerencia: Verifica la dirección correcta en la demo. Para ello, usa 451 7th Avenue South, Kirkland, WA 98033 para ver la respuesta de la dirección que se indicó originalmente.

Acción: Para esta dirección, puedes pedirle al usuario que confirme si la dirección que se muestra es correcta.

Ejemplos de casos extremos: Confirma

En los siguientes ejemplos, se ilustran los siguientes tipos de casos extremos:

• Inferencias menores que SÍ se confirman. La API de Address Validation infiere el país, el código postal o el estado, pero todo lo demás se proporciona y confirma. La combinación del nivel de detalle y de confirmación genera una inferencia menor que no necesariamente requiere una acción de confirmación.
• No se confirmó el componente de dirección inesperado. Los componentes de dirección no confirmados aumentan el nivel de riesgo de la dirección. Esto podría requerir una confirmación.
• Componente de dirección inesperado que ESTÁ confirmado. El componente no es estrictamente necesario para una dirección adecuada, y la API de Address Validation lo quita del resultado. Por lo general, los problemas de formato no requieren una confirmación.

Inferencias menores que SÍ se confirman

Cuando se combina con datos confirmados de un nivel más detallado, la API aún puede realizar una inferencia correcta si a la entrada le falta solo un componente de los siguientes tipos:

• Ciudad
• Estado
• Código postal
• País

Por ejemplo, un cliente proporciona una dirección válida para un restaurante McDonald's en Springfield, Massachusetts, pero se olvida de ingresar la ciudad y proporciona un código postal sin la extensión de 4 dígitos.

Dirección ingresada	Región
1402 Allen St, MA 01118	EE.UU.

Veredicto para la ciudad faltante

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

En situaciones en las que la API de Address Validation infiere componentes de nivel superior para generar una dirección de entrega, puedes tener un nivel más alto de confianza en que los datos del sistema son correctos. Esto se debe a que los componentes inferidos que representan una amplia región geográfica coinciden más fácilmente con los componentes de dirección confirmados que son más detallados. Incluso en países donde se repiten los nombres de las ciudades, como Springfield en Estados Unidos, los otros componentes combinados con él pueden proporcionar una dirección única.

En nuestro ejemplo anterior, un análisis de todos los componentes de la dirección muestra que cada componente se confirma, lo que significa que coincide con los datos almacenados por la API de Address Validation y que el servicio también infiere dos componentes de nivel superior.

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

Acción: Las direcciones como estas proporcionan suficiente nivel de detalle confirmado, junto con la confirmación de los componentes inferidos, para que tu lógica pueda aceptarlas como válidas sin necesidad de solicitarle al cliente que las confirme. Como siempre, considera tu nivel de riesgo cuando decidas si debes solicitarle o no la dirección al cliente antes de aceptarla.

No se confirmó el componente de dirección inesperado

Esta situación ilustra la importancia de verificar cuándo los componentes no se confirman. Si un componente de dirección es inesperado, la API de Address Validation lo quita de la salida. En estos casos, puedes aceptar la dirección o volver a confirmarla con el cliente, según tu nivel de riesgo y confianza.

Por ejemplo, una dirección puede ser de una región en la que los clientes suelen ingresar información inofensiva que la autoridad postal ignora. En ese caso, aceptarías la dirección. Sin embargo, en algunos casos, un componente no confirmado puede no ser lo que el cliente quiere.

Dirección ingresada	Región
59 Cherrydown Avenue, Chingford, Londres E4 8DT	Reino Unido

No se confirmó el veredicto para el componente de dirección inesperado

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

Además de un veredicto con componentes no confirmados, la API de Address Validation muestra la siguiente dirección con formato:

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

Un análisis de componentes no confirmados muestra que la API quitó Chingford de la dirección que se muestra:

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

Acción: En este caso, la sublocalidad, que puede indicar un distrito habitacional o un vecindario, podría ser correcta, pero la autoridad postal la ignora. Sin embargo, como la API de Address Validation **no** confirma esta información, te recomendamos que la confirmes con el cliente. En este punto, puedes ignorar la eliminación o confirmarla.

Componente de dirección inesperado que SI se confirmó

En este ejemplo, se ilustra la inclusión de un condado del Reino Unido en la dirección proporcionada, lo que es una práctica común. Sin embargo, este no es un requisito de la autoridad postal del Reino Unido y se ignora en gran medida. Consulta postoffice.co.uk y Cómo dirigir el correo del Reino Unido y el internacional.

Como resultado, cuando un cliente proporciona un condado en una dirección del Reino Unido, el servicio lo evalúa como una entrada inesperada.

Dirección ingresada	Región
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP	Reino Unido

Veredicto para el componente de dirección inesperado que SE confirma

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

Aquí, address_complete se evalúa como falso y un análisis del componente de dirección revela una marca inesperada.

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

Este componente es inesperado y confirmado, lo que significa lo siguiente:

• Confirmados como datos correctos. Esto indica que el componente es el condado correcto que contiene la dirección.
• Es inesperado como entrada. Indica un componente que no es necesario para dar el formato correcto a la dirección.

Si bien Gloucestershire es el condado correcto para la dirección ingresada, esta tiene un formato incorrecto. Recuerda que la API de Address Validation también evalúa la información para verificar que tenga el formato correcto.

Acción: En esta situación, puedes aceptar la dirección sin más solicitudes, según tu nivel de riesgo.