En este documento, se describen varias situaciones reales en las que la API de Address Validation proporciona indicadores de respuesta para las direcciones que garantizan un comportamiento de confirmación de tu sistema. Consulta la Descripción general del flujo de trabajo en Compila la lógica de validación para obtener más contexto.
Ejemplos comunes: confirmación
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, WA, Estados Unidos. Sin embargo, en lugar de Kirkland como ciudad, por accidente ingresaron a Seattle.
| Dirección ingresada | Región |
|---|---|
| Building D, 451 7th Avenue South, Seattle, WA 98033 | EE.UU. |
Veredicto para datos reemplazados
El siguiente ejemplo enfatiza las señales importantes de la respuesta.
{
"inputGranularity": "SUB_PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete": true,
"hasUnconfirmedComponents": true
"hasReplacedComponents": true
}
El PREMISE_PROXIMITY indica la proximación de una dirección a nivel de edificio, pero no es tan detallado como SUB_PREMISE, que es el nivel de detalle proporcionado en la entrada.
La respuesta también contiene componentes no confirmados y reemplazados, por lo que la combinación sugiere esto a la categoría confirm.
Una consulta de los componentes de 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.
Ejemplos de casos extremos: Confirmar
En los siguientes ejemplos, se ilustran los siguientes tipos de casos límite:
- Inferencias menores confirmadas. 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 hace que una inferencia menor no necesite una acción de confirmación.
- Componente de dirección inesperado NO confirmado. Los componentes de dirección sin confirmar se suman al 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 obligatorio para una dirección adecuada, y la API de Address Validation lo quita del resultado. Por lo general, los problemas de formato no garantizan una confirmación.
Inferencias menores que ESTÁN confirmadas
Cuando se combina con datos confirmados de un nivel más detallado, la API aún puede hacer 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 de 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 producir una dirección de entregable, puedes tener más 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 emparejan más fácilmente con los componentes de dirección confirmados que son más detallados. Incluso en países donde los nombres de ciudades se repiten, como Springfield en los Estados Unidos, los otros componentes combinados pueden proporcionar una dirección única.
Con 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 esta situación, se ilustra la importancia de verificar cuando los componentes no están confirmados. Si un componente de la 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 donde los clientes suelen ingresar información inofensivo que ignora la autoridad postal, en cuyo caso deberías aceptar la dirección. Sin embargo, en algunos casos, es posible que un componente no confirmado no sea lo que el cliente desea.
| Dirección ingresada | Región |
|---|---|
| 1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry | Francia |
Veredicto para componente de dirección inesperada no confirmado
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true
}
Además de un veredicto con componentes no confirmados, la API de Address Validation muestra la siguiente dirección con formato:
"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",
Un análisis de componentes no confirmados muestra que la API quitó la caritat 2 de la dirección mostrada:
{
"componentName": {
"text": "la caritat 2",
"languageCode": "fr"
},
"componentType": "sublocality_level_1",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
"unexpected": true
}
Componente de dirección inesperado que ESTÁ confirmado
En este ejemplo, se ilustra la inclusión de un condado del Reino Unido en la dirección proporcionada, lo cual es una práctica común. Sin embargo, este no es un requisito de la autoridad postal del Reino Unido y, en esencia, se ignora. Consulta postoffice.co.uk y Cómo enviar el correo internacional y el Reino Unido.
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 componente de dirección inesperada que ESTÁ confirmado
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
Aquí, address_complete se evalúa como falso y un análisis del componente de la 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 que tenga un formato adecuado.