En este documento, se describe un proceso para compilar un sistema de verificación de direcciones que controle una variedad de respuestas de la API de Address Validation. En ella, se explica cómo interpretar la respuesta de la API para determinar cuándo y cómo solicitar más información a tus clientes.
En general, la respuesta de la API determina las siguientes formas en que tu sistema debe controlar una dirección:
-
Corregir: La dirección puede contener problemas significativos.
Considera solicitarle más información al cliente. -
Agregar subinstalaciones: Es posible que falte una subinstalación en la dirección.
Considera solicitarle a tu cliente que agregue un número de unidad. -
Confirmar: La dirección puede contener problemas menores.
Considera pedirle a tu cliente que confirme que la dirección es correcta. -
Aceptar: Es posible que la dirección no contenga problemas.
Considera usar la dirección sin más indicaciones, bajo tu propia responsabilidad.
Propósito clave
Este documento te ayuda a modificar tu sistema para analizar mejor la respuesta de la API y determinar las próximas acciones que se deben realizar con las direcciones proporcionadas. El siguiente pseudocódigo ilustra un posible flujo.
if (verdict.possibleNextAction == FIX)
Prompt the user to fix the address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
Prompt the user to add a unit number.
else if (verdict.possibleNextAction == CONFIRM)
Confirm with the user that the address is correct.
else
Continue with the address returned by the API.
La lógica exacta depende de tu situación. Consulta Personaliza tu lógica de validación para obtener más detalles.
Flujos de trabajo de ejemplo
En la siguiente tabla, se resumen los ejemplos de flujos de trabajo que podrías implementar para solicitarle información a tu cliente en función de la respuesta de la API.
| El comportamiento del sistema | ||
|---|---|---|
| Corregir la dirección |
La respuesta de
|
|
| Agregar subinstalaciones |
La respuesta de
|
|
| Confirma la dirección |
La respuesta de
|
|
| Aceptar la dirección |
La respuesta de
|
|
Personaliza tu lógica de validación
Si bien puedes usar los resultados del campo verdict.possibleNextAction para determinar cómo tu sistema procesa la respuesta de la API, también puedes considerar la posibilidad de crear una lógica personalizada, por ejemplo, para controlar las necesidades específicas de la empresa.
El propósito de esta sección es ilustrar cómo puedes desarrollar tu propia lógica personalizada para interpretar la respuesta de la API y determinar si quieres solicitarle algo a tu cliente y cómo hacerlo. En esta sección, se describen los niveles de riesgo y los indicadores de respuesta de la API adicionales que debes tener en cuenta para tu personalización.
Dicho esto, incluso si solo te basas en el verdict.possibleNextAction para decidir los próximos pasos, los indicadores adicionales que se describen a continuación pueden ayudarte a comprender los detalles sobre los posibles problemas con la dirección.
Tolerancia al riesgo
Cuando diseñes la forma en que tu sistema responde a los indicadores de la API de Address Validation, las siguientes recomendaciones pueden ayudarte a crear un modelo de respuesta más eficaz. Sin embargo, estas son solo recomendaciones, por lo que debes tener en cuenta que tu implementación debe adaptarse a tu modelo de negocio.
| Orientación | Detalles | |
|---|---|---|
| Nivel de riesgo |
Ten en cuenta el nivel de tolerancia para tu situación cuando decidas si solicitar correcciones o aceptar la dirección tal como se ingresó. |
La API de Address Validation devuelve una variedad de indicadores que puedes incorporar a tu nivel de riesgo para optimizar el proceso de validación. Por ejemplo, si una dirección tiene un número de calle sin confirmar, puedes aceptarla de todos modos. Por otro lado, si tu operación comercial requiere una mayor precisión de la dirección, puedes solicitarle al usuario que la proporcione. Para ver un ejemplo que podría entrar en cualquiera de las dos categorías, consulta Número de calle no confirmado de fuera de EE.UU. en Aceptar dirección: ejemplos. |
| Aceptar direcciones |
Se recomienda permitir que el sistema acepte la entrada original si el cliente no responde a las indicaciones. |
En estos casos, es posible que el cliente haya ingresado una dirección que no se encuentra en el sistema, como la de una construcción nueva. |
Ejemplo de flujo de confirmación de compra que evita riesgos
Si deseas reducir el riesgo de que no se realicen las entregas, puedes personalizar tu lógica para solicitar a tus clientes con mayor frecuencia. Por ejemplo, en lugar de usar la lógica que se describe en la sección Propósito de la clave, puedes usar la siguiente lógica.
if (verdict.possibleNextAction == FIX or verdict.validationGranularity
== OTHER or verdict.validationGranularity == ROUTE)
Prompt customer to fix their address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
Prompt customer to add a unit number.
else if (verdict.possibleNextAction == CONFIRM or verdict.validationGranularity
== PREMISE_PROXIMITY or verdict.hasSpellCorrectedComponents or
verdict.hasReplacedComponents or verdict.hasInferredComponents)
Prompt customer to confirm their address.
else
Proceed with the returned address.
Ejemplo de flujo de confirmación de compra con poca fricción
Si deseas reducir la fricción en el flujo de confirmación de compra, puedes personalizar tu lógica para solicitar a tus clientes con menos frecuencia. Por ejemplo, en lugar de usar la lógica que se describe en la sección Propósito de la clave, puedes usar la siguiente lógica.
if (verdict.possibleNextAction == FIX)
Prompt customer to fix their address.
else if (verdict.hasReplacedComponents)
Prompt customer to confirm their address.
else
Proceed with the returned address.
Indicadores de FIX
Corregir una dirección cuando los resultados indican claramente que es posible que no se pueda realizar la entrega Luego, tu sistema puede solicitarle al cliente que proporcione la información necesaria, tras lo cual volverás a emitir tu flujo de trabajo para obtener una dirección de entrega.
Además de verdict.possibleNextAction, se pueden usar los siguientes campos de la respuesta de la API de Address Validation para determinar si una dirección tiene problemas graves y cuáles son esos problemas.
| Nivel de detalle de la validación | Cuando el enum de granularidad de validación de una dirección es OTHER, es probable que la dirección sea incorrecta.
|
|---|---|
| Faltan componentes | Cuando address.missingComponentTypes no está vacío, es probable que falte información clave en la dirección.
|
| Componentes sospechosos | Cuando el enum de nivel de confirmación de un componente es UNCONFIRMED_AND_SUSPICIOUS, es probable que el componente sea incorrecto.
|
| Componentes sin resolver | Un unresolvedToken es una parte de la entrada que no se reconoce como una parte válida de una dirección. |
| Confirmación de DPV de USPS | Cuando uspsData.dpvConfirmation es N o está vacío, es posible que haya un problema con la dirección. Este campo solo está disponible para direcciones de EE.UU. Para obtener más detalles sobre uspsData.dpvConfirmation, consulta Cómo controlar direcciones de Estados Unidos.
|
Ejemplos de corrección de direcciones
Indicadores de CONFIRM_ADD_SUBPREMISES (solo direcciones de EE.UU.)
Le pides a tu cliente que revise la dirección y considere agregar un número de unidad cuando la respuesta de la API de Address Validation indique que es posible que falte una subinstalación. En estos casos, es probable que la dirección del edificio sea válida, pero quieres tener más certeza de que la dirección resultante es la que el cliente quería.
Además de verdict.possibleNextAction, se pueden usar los siguientes campos de la respuesta de la API de Address Validation para determinar si es probable que falte una subinstalación en una dirección.
Missing subpremise component
|
Cuando el campo address.missingComponentTypes contiene un valor de subpremise, esto indica que falta un número de unidad en la dirección.
|
|---|---|
| Confirmación de DPV de USPS | Cuando uspsData.dpvConfirmation es S, significa que el número principal de la dirección coincide con una dirección de la base de datos de USPS. Sin embargo, se esperaba que la dirección también contuviera un número secundario. Este campo solo está disponible para direcciones de EE.UU. Para obtener más detalles sobre uspsData.dpvConfirmation, consulta Cómo controlar direcciones de Estados Unidos.
|
Ejemplos de direcciones de subinstalaciones
Indicadores de CONFIRM
Confirmas una dirección cuando el veredicto indica que la API de Address Validation infirió o realizó cambios en los componentes de la dirección para producir una dirección validada. En estos casos, tienes una dirección de entrega, pero prefieres tener más certeza de que la dirección resultante es la que el cliente quería.
Además de verdict.possibleNextAction, se pueden usar los siguientes campos de la respuesta de la API de Address Validation para determinar si una dirección tiene problemas menores y cuáles son esos problemas.
| Nivel de detalle de la validación | Cuando validationGranularity para una dirección es ROUTE o PREMISE_PROXIMITY, es posible que la dirección sea incorrecta.
|
|---|---|
| Datos inferidos | Cuando el campo hasInferredComponents es true, sabes que la API completó la información que recopiló de otros componentes de la dirección.
|
| Datos reemplazados | Cuando el campo hasReplacedComponents es true, la API reemplazó los datos ingresados por datos que consideró que harían que la dirección fuera válida.
|
| Correcciones ortográficas | Cuando el campo hasSpellCorrectedComponents es true, la API corrigió la ortografía de algunos componentes mal escritos.
|
Ejemplos de direcciones confirmadas
Indicadores de ACCEPT
Puedes aceptar una dirección cuando la respuesta de la API de Address Validation proporciona un alto grado de confianza en que la dirección es apta para la entrega y se puede usar sin más interacción del cliente en el proceso posterior.
Además de verdict.possibleNextAction, se pueden usar los siguientes campos de la respuesta de la API de Address Validation para determinar si una dirección tiene una calidad aceptable.
| Nivel de detalle de la validación | Un validationGranularity de PREMISE suele ser aceptable, aunque un valor de ROUTE aún puede indicar una dirección de entrega.
|
|---|---|
| No hay datos inferidos | Cuando el campo hasInferredComponents es false, sabes que no se infirió ningún componente en el resultado.
|
| No se reemplazaron datos | Cuando el campo hasReplacedComponents es false, sabes que no se reemplazaron datos de entrada.
|
| No hay correcciones ortográficas | Cuando el campo hasSpellCorrectedComponents es false, sabes que no se realizaron correcciones ortográficas.
|
| Confirmación de DPV de USPS | Cuando uspsData.dpvConfirmation es Y, significa que la dirección coincide con una dirección de la base de datos del USPS. Este campo solo está disponible para direcciones de EE.UU. Para obtener más detalles sobre uspsData.dpvConfirmation, consulta Cómo controlar direcciones de Estados Unidos.
|
Ejemplos de direcciones aceptadas