Guía de soluciones de Address Validation

Diagrama de flujo que muestra la descripción general de alto nivel de los pasos de prueba.

Objetivo

Address Validation proporciona valor para una variedad de casos de uso, y hay consideraciones clave más allá de la calidad sin procesar de los resultados de las pruebas que te sugerimos explorar. Por ejemplo, una vista integral de los productos compatibles en un flujo de usuarios, como Place Autocomplete y Maps, la disponibilidad regional y la confianza y confiabilidad empresarial.

Una vez que llegues al punto de evaluar la API de Address Validation, te recomendamos que sigas estos lineamientos como parte de tus pruebas.

Los objetivos de esta prueba serán los siguientes:

  1. Confirma que la API de Address Validation sea adecuada para tu caso de uso.
  2. Verifica cómo la API de Address Validation cumple con los requisitos de tus soluciones, como los siguientes:
    • Identificar direcciones de buena calidad
    • Alertas para abordar entradas de baja calidad
    • Realizar correcciones en los datos de direcciones, incluidas las inferencias, los reemplazos y las correcciones ortográficas
    • Proporcionar una dirección con formato para el envío
    • Alertar sobre datos de subpremisa faltantes o incorrectos (solo en EE.UU.)
  3. Asegúrate de que recibirás un beneficio medible por implementar la API.

Después de realizar la prueba, podrás responder las preguntas anteriores y determinar si la API es adecuada para tu empresa.

Prepara los datos

La prueba debe realizarse con una muestra de tus datos de direcciones existentes. No selecciones datos para la prueba, sino que elige muestras aleatorias que sean representativas de las ubicaciones geográficas en las que operas. Esto significa que, si operas tanto en Estados Unidos como en el Reino Unido, pero el 70% de tu empresa se encuentra en el Reino Unido y el 30% en EE.UU., la muestra debería reflejar esa división.

Usa las direcciones del punto de captura. Por ejemplo, si planeas implementar la validación de direcciones en la confirmación de la compra de tu comercio electrónico, usa las direcciones tal como las ingresaron tus clientes en el formulario, antes de que se realice cualquier procesamiento existente que se pueda reemplazar con la implementación de la API de Address Validation.

Prepara un tamaño de muestra de entre 5,000 y 10,000 registros para la prueba.

Llama a la API

Requisito previo de la sección: Comprende cómo enviar una solicitud de validación de dirección.

Una vez que hayas preparado los datos, deberás ejecutar cada registro de dirección en la API.

Consulta la documentación de la API de Address Validation para obtener orientación sobre cómo llamar a la API. También tenemos un artículo en el que se describen las prácticas recomendadas para usar la API de Address Validation para procesar direcciones en grandes volúmenes.

El resultado de este paso debe ser la salida de datos de la API para cada registro de dirección. Luego, podrás analizar los resultados para determinar la idoneidad de la API para tu caso de uso. Tú decides si usarás una hoja de cálculo, una base de datos o alguna otra herramienta.

Revisa los resultados

Requisito previo de la sección: Comprende cómo controlar la respuesta de validación, en especial, el concepto de Corregir, Confirmar y Aceptar.

En esta sección, analizaremos las situaciones de salida que puedes analizar para evaluar la idoneidad de la solución.

Descripción general de los campos clave de la API que se analizan en este documento

Datos de respuesta

¿Qué es?

Cómo evaluar

¿Cómo ayuda?

verdict.inputGranularity

Describe el nivel de detalle de entrada de la dirección.

SUB_PREMISE

PREMISA

PREMISE_PROXIMITY

BLOQUEAR

ROUTE

OTRO

Te permite determinar si la dirección de entrada tiene suficientes datos para ser potencialmente válida.

verdict.validationGranularity

Describe la validación general del resultado de la dirección.

SUB_PREMISE

PREMISA

PREMISE_PROXIMITY

BLOQUEAR

ROUTE

OTRO

Te permite determinar la calidad general de la dirección en el resultado de la API.

verdict.hasInferredComponents

Indica si la API infirió un componente.

Verdadero o falso

La API puede agregar componentes faltantes cuando puede inferir los datos. Por ejemplo, falta el código de estado.

verdict.hasReplacedComponents

Indica si la API reemplazó un componente.

Verdadero o falso

La API puede reemplazar los componentes incorrectos por los datos correctos en algunas situaciones.

verdict.addressComplete

Indica si la dirección está completa.

Verdadero o falso

Si la API determina que la dirección de salida tiene todos los componentes necesarios, este valor será verdadero.

address.missingComponentTypes

Es un indicador para advertir si faltan componentes en la dirección.

Consulta la tabla dos para ver los valores.

Destaca los componentes que faltan en una dirección incompleta.

Revisa las direcciones válidas

Ordena los datos que devuelve la API para determinar el conjunto de direcciones que tu sistema aceptaría como válidas. Los indicadores clave que se deben buscar en la API son los siguientes:

  • verdict.validationGranularity contiene PREMISE o una versión posterior.
  • verdict.addressComplete es true.
  • No hay componentes inferidos ni reemplazados.

Consulta Cómo aceptar una dirección para obtener más información.

El resultado de este ejercicio debería ser un subconjunto de los datos de direcciones que tu sistema aceptaría como válidos. En este punto, puedes determinar lo siguiente:

  • ¿Es aceptable el porcentaje de aceptación?
  • Si usas un flujo de trabajo de Address Validation existente, ¿el porcentaje de aceptación es equivalente o mejor?

Ejemplo: Dirección válida

Dirección ingresada

Región

76 Buckingham Palace Road, Londres SW1W 9TQ

Reino Unido

Veredicto

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

Revisa las direcciones no válidas

Este paso es una oportunidad para revisar de forma manual algunos de los datos de direcciones que se marcaron como no válidos y ver si, sin usar la API de Address Validation, esa dirección no válida podría causar problemas en el futuro.

Ordena los datos que muestra la API para determinar el conjunto de direcciones que tu sistema marcaría como no válidas. Los indicadores clave que se deben buscar en la API son los siguientes:

  • verdict.validationGranularity configurado como OTHER o ROUTE según tu nivel de riesgo.
  • verdict.addressComplete es false.

Consulta cómo corregir una dirección para obtener más información.

El resultado de este ejercicio debería ser un subconjunto de los datos de dirección que tu sistema marcaría como no válidos. En este punto, puedes determinar si el porcentaje de invalidación es aceptable.

Es importante tener en cuenta que marcar direcciones como no válidas es una parte fundamental de la funcionalidad de la API de Address Validation, y que una tasa alta de direcciones marcadas como no válidas no necesariamente refleja un mal funcionamiento de la API. La API te informa que hay un problema con la dirección, lo que puede mejorar la eficiencia de tu flujo de trabajo, ya que detecta errores antes de que causen problemas más adelante.

Ejemplo: Dirección no válida

Dirección ingresada

Región

21 45 40th street

Estados Unidos

Veredicto

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true
}

Revisa los componentes faltantes o no confirmados

En esta etapa, también se pueden revisar los componentes faltantes o no confirmados. Esto forma parte del objeto Address en la devolución. Los dos campos son missingComponentTypes y unconfirmedComponentTypes.

Usa estos campos para detectar el motivo por el que la API marca una dirección como no válida y recopila la información correcta para que la dirección sea válida. Para ello, envía comentarios al punto de recopilación de datos sobre los campos específicos que son incorrectos. Esta es una forma en que la API proporciona valor, ya que te brinda información específica sobre la calidad de tus datos.

Ejemplo: Componente faltante y no confirmado

Dirección ingresada

Región

Fake St, Nueva York, NY 10011

Estados Unidos

Veredicto

{
     "inputGranularity": "ROUTE",
     "validationGranularity": "OTHER",
     "geocodeGranularity": "OTHER",
     "hasUnconfirmedComponents": true
}

Componentes faltantes y no confirmados

"missingComponentTypes": [
    "street_number"
],
"unconfirmedComponentTypes": [
    "route"
]

Revisa las direcciones con correcciones

La API de Address Validation puede corregir los datos de entrada, ya que toma una dirección potencialmente no válida y genera datos de dirección válidos. Esta es una forma en que la API agrega valor, y es importante capturar esto como parte de la prueba.

Los indicadores clave que debes buscar son los siguientes:

  • inferred, replaced o spellCorrected configurados como true en cualquiera de los addressComponents.
  • verdict.hasInferredComponents o verdict.hasReplacedComponents configurado como true.

Consulta Cómo confirmar una dirección para obtener más información.

El resultado de este ejercicio debería ser un subconjunto de los datos de direcciones que la API corrigió.

Una parte de estos datos se puede revisar de forma manual para determinar si la API realiza correcciones en tus datos que reducirían la fricción en tu flujo de trabajo descendente.

Ejemplo: Dirección con una corrección

Dirección ingresada

Región

76 Buckingham Palace Road, Londres SW1W 9TQ

Reino Unido

Ruta addressComponent

{
    "componentName": {
        "text": "Buckingham Palace Road",
        "languageCode": "en"
    },
    "componentType": "route",
    "confirmationLevel": "CONFIRMED",
    "spellCorrected": true
}

[Solo para EE.UU.] Revisa la dirección con datos de subpremisa faltantes o incorrectos

La API de Address Validation puede determinar si falta un sublocal o si es incorrecto en las direcciones de EE.UU.

Los indicadores clave que debes buscar son los siguientes:

  • En el objeto Address, haz lo siguiente:
    • unconfirmedComponentTypes contiene subpremise
    • missingComponentTypes contiene subpremise
  • En el objeto UspsData, haz lo siguiente:
    • dpvConfirmation es D (falta el subpremise)
    • dpvConfirmation es S (subpremisa sin confirmar)

Consulta Cómo controlar las direcciones de Estados Unidos para obtener más información.

Esta prueba mostrará si hay un problema en tus datos con sublocales faltantes o incorrectos, como números de departamento. Esto puede causar problemas posteriores, en especial para los casos de uso de entrega. La API de Address Validation puede agregar valor a tu flujo de trabajo, ya que identifica este problema antes y te permite implementar pasos para recopilar datos corregidos.

Ejemplo: Falta el sublocal

Dirección ingresada

Región

111 8th Avenue, Manhattan, NY 10011

EE.UU.

Falta un componente

"missingComponentTypes": [
    "subpremise"
]

Confirmación de DPV de datos de USPS

"dpvConfirmation": "D"

[Solo para EE.UU.] Revisa la dirección estandarizada de USPS

La API de Address Validation también devuelve la dirección estandarizada del USPS para las direcciones de Estados Unidos. Esto es especialmente importante si necesitas que se impriman direcciones con el formato del USPS en tus etiquetas de envío.

Se puede revisar UspsAddress para ver estos datos y determinar si agregan valor a tu flujo de trabajo.

Ejemplo: Dirección estandarizada del USPS

"standardizedAddress": {
    "firstAddressLine": "111 8TH AVE FL 11",
    "cityStateZipAddressLine": "NEW YORK NY 10011-5201",
    "city": "NEW YORK",
    "state": "NY",
    "zipCode": "10011",
    "zipCodeExtension": "5201"
}

Conclusión

Comienza a realizar pruebas: Comienza a probar la API de Address Validation hoy mismo para garantizar datos de direcciones precisos, mejorar la experiencia del cliente y optimizar tus operaciones comerciales. Después de seguir las situaciones de prueba descritas anteriormente, tendrás la información que necesitas para determinar si la API de Address Validation aportará valor a tu flujo de trabajo.

Lecturas adicionales sugeridas:

Colaboradores

Henrik Valve | Ingeniero de DevX