En este documento, se describen varios casos prácticos en los que la API de Address Validation proporciona indicadores de respuesta para las direcciones que justifican un comportamiento de confirmación por parte de tu sistema. Los ejemplos que se muestran aquí son ilustrativos, pero no exhaustivos. Consulta la descripción general del flujo de trabajo en Cómo compilar tu lógica de validación para obtener contexto.
Ejemplos comunes: Confirmar
En el siguiente ejemplo, se ilustra el caso de áreas metropolitanas con nombres de calles similares. Supongamos que un usuario desea ingresar la dirección del edificio D de Google en Kirkland, WA, Estados Unidos. Sin embargo, en lugar de Kirkland como ciudad, ingresan por error Seattle.
| Dirección ingresada | Región |
|---|---|
| Edificio D, 451 7th Avenue South, Seattle, WA 98033 | EE.UU. |
Verificación de los datos reemplazados
En el siguiente ejemplo, se destacan los indicadores importantes del veredicto.
{
"inputGranularity": "SUB_PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete": true,
"hasUnconfirmedComponents": true
"hasReplacedComponents": true
}
El nivel de detalle de PREMISE_PROXIMITY indica la aproximación de una dirección a nivel del edificio, pero no es tan detallado como SUB_PREMISE, que es el detalle proporcionado en la entrada. La respuesta también contiene componentes no confirmados y reemplazados, por lo que la combinación la clasifica en la categoría confirmar.
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. Podría ser un reemplazo válido, pero, junto con el 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 cosa, como Kirkland.
Ejemplos de casos extremos: Confirmar
En los siguientes ejemplos, se ilustran los siguientes tipos de casos extremos:
- Inferencias secundarias que 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 de la granularidad y el nivel de confirmación hace que una inferencia menor no necesariamente necesite 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 SE confirma. El componente no es estrictamente necesario para una dirección correcta, y la API de Address Validation lo quita del resultado. Por lo general, los problemas de formato no justifican una confirmación.
Inferencias secundarias 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 la entrada solo carece de un componente de los siguientes tipos:
- Ciudad
- Estado
- Código postal
- País
Por ejemplo, un cliente proporciona una dirección de calle válida para un restaurante de McDonald's en Springfield, Massachusetts, pero olvida 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. |
Verificación de la ciudad faltante
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"addressComplete": true,
"hasInferredComponents": true
}
En situaciones en las que la API de Address Validation infiere componentes de nivel superior para generar una dirección apta para la entrega, puedes tener un mayor nivel de confianza en que los datos del sistema son correctos. Esto se debe a que los componentes inferidos que representan una región geográfica amplia se correlacionan más fácilmente con los componentes de dirección confirmados que son más detallados. Incluso en los países en los que 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 está confirmado, 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
}
No se confirmó el componente de dirección inesperado
En este caso, se ilustra la importancia de verificar cuándo no se confirman los componentes. Si un componente de dirección es inesperado, la API de Address Validation lo quita del resultado. En estos casos, puedes aceptar la dirección o volver a confirmarla con el cliente, según tu nivel de riesgo y de 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 cuyo caso aceptarías la dirección. Sin embargo, en algunos casos, un componente no confirmado podría no ser lo que el cliente desea.
| Dirección ingresada | Región |
|---|---|
| 1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry | Francia |
No se confirmó el veredicto para el componente de dirección inesperado
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true
}
Además de un veredicto con componentes no confirmados, la API de Address Validation devuelve la siguiente dirección con formato:
"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",
Un análisis de los componentes no confirmados muestra que la API quitó la caritat 2 de la dirección devuelta:
{
"componentName": {
"text": "la caritat 2",
"languageCode": "fr"
},
"componentType": "sublocality_level_1",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
"unexpected": true
}
Componente de dirección inesperado que SÍ se confirma
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, la autoridad postal del Reino Unido no lo exige y, básicamente, lo ignora. Consulta postoffice.co.uk y Cómo dirigir el correo internacional y del Reino Unido.
Como resultado, cuando un cliente proporciona un condado en una dirección del Reino Unido, el servicio evalúa esto como una entrada inesperada.
| Dirección ingresada | Región |
|---|---|
| 33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | Reino Unido |
Verificación para el componente de dirección inesperado que SE CONFIRMA
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
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
}
Si bien Gloucestershire es el condado correcto para la dirección ingresada, la dirección en sí tiene un formato incorrecto. Recuerda que la API de Address Validation también evalúa la información para garantizar el formato adecuado.