Ce document décrit un processus de création d'un système de vérification d'adresse permettant de gérer diverses réponses de l'API Address Validation. Il explique comment interpréter la réponse de l'API pour déterminer quand et comment demander plus d'informations à vos clients.
En général, la réponse de l'API détermine les différentes manières dont votre système doit gérer une adresse :
-
Corriger : l'adresse peut contenir des problèmes importants.
Envisagez de demander plus d'informations à votre client. -
Ajouter un sous-lieu : il est possible qu'un sous-lieu manque à l'adresse.
Envisagez d'inviter votre client à ajouter un numéro d'unité. -
Confirmer : l'adresse peut contenir des problèmes mineurs.
Envisagez de demander à votre client de confirmer que l'adresse est correcte. -
Accepter : l'adresse ne contient peut-être pas de problèmes.
Envisagez d'utiliser l'adresse sans autre invite, à vos propres risques.
Objectif principal
Ce document vous aide à modifier votre système pour analyser au mieux la réponse de l'API et déterminer les prochaines actions à entreprendre avec les adresses fournies. Le pseudocode suivant illustre un flux possible.
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 logique exacte dépend de votre situation. Pour en savoir plus, consultez Personnaliser votre logique de validation.
Exemples de workflows
Le tableau ci-dessous récapitule des exemples de workflows que vous pouvez implémenter pour inviter votre client en fonction de la réponse de l'API.
| Comportement de votre système | ||
|---|---|---|
| Corriger l'adresse |
La réponse de
|
|
| Ajouter un sous-établissement |
La réponse de
|
|
| Confirmer l'adresse |
La réponse de
|
|
| Accepter l'adresse |
La réponse de
|
|
Personnaliser votre logique de validation
Bien que vous puissiez utiliser les résultats du champ verdict.possibleNextAction pour déterminer comment votre système traite la réponse de l'API, vous pouvez également envisager de créer une logique personnalisée, par exemple pour répondre à des besoins spécifiques à votre entreprise.
L'objectif de cette section est d'illustrer comment développer votre propre logique personnalisée pour interpréter la réponse de l'API afin de déterminer si et comment vous souhaitez inviter votre client. Cette section aborde les niveaux de risque et les signaux de réponse d'API supplémentaires à prendre en compte pour votre personnalisation.
Cela dit, même si vous vous fiez uniquement à verdict.possibleNextAction pour décider des prochaines étapes, les signaux supplémentaires décrits ci-dessous peuvent toujours vous aider à comprendre les détails des problèmes potentiels liés à l'adresse.
Tolérance au risque
Lorsque vous concevez la façon dont votre système répond aux signaux de l'API Address Validation, les recommandations suivantes peuvent vous aider à créer un modèle de réponse plus efficace. Toutefois, il ne s'agit que de recommandations. N'oubliez pas que votre implémentation doit être adaptée à votre modèle économique.
| Conseils | Détails | |
|---|---|---|
| Niveau de risque |
Tenez compte du niveau de tolérance pour votre situation lorsque vous choisissez entre demander des corrections et accepter l'adresse telle qu'elle a été saisie. |
L'API Address Validation renvoie différents signaux que vous pouvez intégrer à votre niveau de risque pour optimiser votre processus de validation. Par exemple, si une adresse comporte un numéro de rue non confirmé, vous pouvez quand même l'accepter. En revanche, si votre activité nécessite une plus grande précision de l'adresse, vous pouvez inviter l'utilisateur à la fournir. Pour obtenir un exemple pouvant appartenir à l'une ou l'autre des catégories, consultez Numéro de rue non confirmé hors États-Unis dans Accepter l'adresse : exemples. |
| Accepter les adresses |
Il est recommandé d'autoriser votre système à accepter l'entrée d'origine si le client ne répond pas aux invites. |
Dans ce cas, il est possible que le client ait saisi une adresse qui ne figure pas dans le système, par exemple pour une nouvelle construction. |
Exemple de parcours de paiement avec aversion au risque
Si vous souhaitez réduire le risque d'échec des livraisons, vous pouvez personnaliser votre logique pour inciter vos clients plus souvent. Par exemple, au lieu d'utiliser la logique décrite dans la section Objectif de la clé, vous pouvez utiliser la logique suivante.
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.
Exemple de parcours de paiement fluide
Si vous souhaitez réduire les frictions dans votre parcours de paiement, vous pouvez personnaliser votre logique pour inviter moins souvent vos clients. Par exemple, au lieu d'utiliser la logique décrite dans la section Objectif de la clé, vous pouvez utiliser la logique suivante.
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.
Signaux FIX
Corrigez une adresse lorsque les résultats indiquent clairement qu'elle n'est peut-être pas valide. Votre système peut alors inviter le client à fournir les informations nécessaires, après quoi vous réémettez votre workflow pour obtenir une adresse de livraison.
Les champs suivants de la réponse de l'API Address Validation peuvent être utilisés en plus de verdict.possibleNextAction pour déterminer si une adresse présente des problèmes majeurs et quels sont ces problèmes.
| Précision de la validation | Lorsque l'énumération de la précision de validation d'une adresse est définie sur OTHER, il est probable que l'adresse soit incorrecte.
|
|---|---|
| Composants manquants | Lorsque address.missingComponentTypes n'est pas vide, il est probable que l'adresse manque d'informations clés.
|
| Composants suspects | Lorsque l'énumération du niveau de confirmation d'un composant est UNCONFIRMED_AND_SUSPICIOUS, il est probable que le composant soit incorrect.
|
| Composants non résolus | Un unresolvedToken est une partie de l'entrée qui n'est pas reconnue comme une partie valide d'une adresse. |
| Confirmation USPS DPV | Lorsque uspsData.dpvConfirmation est défini sur N ou est vide, il peut y avoir un problème avec l'adresse. Ce champ n'est disponible que pour les adresses aux États-Unis. Pour en savoir plus sur uspsData.dpvConfirmation, consultez Gérer les adresses aux États-Unis.
|
Exemples de correction d'adresses
Signaux CONFIRM_ADD_SUBPREMISES (adresses aux États-Unis uniquement)
Vous invitez votre client à vérifier l'adresse et à envisager d'ajouter un numéro de bâtiment lorsque la réponse de l'API Address Validation indique qu'il manque peut-être un sous-lieu à l'adresse. Dans ce cas, l'adresse du bâtiment est probablement valide, mais vous souhaitez être plus sûr que l'adresse résultante est bien celle voulue par le client.
Les champs suivants de la réponse de l'API Address Validation peuvent être utilisés en plus de verdict.possibleNextAction pour déterminer si une adresse est susceptible de manquer un sous-lieu.
Missing subpremise component
|
Lorsque le champ address.missingComponentTypes contient la valeur subpremise, cela indique qu'il manque un numéro d'appartement dans l'adresse.
|
|---|---|
| Confirmation USPS DPV | Lorsque uspsData.dpvConfirmation est défini sur S, cela signifie que le numéro principal de l'adresse a été mis en correspondance avec une adresse de la base de données USPS. Cependant, l'adresse devait également contenir un numéro secondaire. Ce champ n'est disponible que pour les adresses aux États-Unis. Pour en savoir plus sur uspsData.dpvConfirmation, consultez Gérer les adresses aux États-Unis.
|
Exemples d'adresses de sous-lieux
Signaux CONFIRM
Vous confirmez une adresse lorsque le verdict indique que l'API Address Validation a inféré ou modifié des composants d'adresse pour produire une adresse validée. Dans ce cas, vous disposez d'une adresse de livraison, mais vous préférez être plus sûr que l'adresse obtenue est bien celle voulue par le client.
Les champs suivants de la réponse de l'API Address Validation peuvent être utilisés en plus de verdict.possibleNextAction pour déterminer si une adresse présente des problèmes mineurs et quels sont ces problèmes.
| Précision de la validation | Lorsque la valeur validationGranularity d'une adresse est ROUTE ou PREMISE_PROXIMITY, il est possible que l'adresse soit incorrecte.
|
|---|---|
| Données inférées | Lorsque le champ hasInferredComponents est défini sur true, vous savez que l'API a complété les informations qu'elle a recueillies à partir d'autres composants d'adresse.
|
| Données remplacées | Lorsque le champ hasReplacedComponents est défini sur true, l'API a remplacé les données saisies par des données qu'elle a jugées valides pour l'adresse.
|
| Corrections orthographiques | Lorsque le champ hasSpellCorrectedComponents est défini sur true, l'API corrige l'orthographe de certains composants mal orthographiés.
|
Exemples de confirmation d'adresse
Signaux ACCEPT
Vous pouvez accepter une adresse lorsque la réponse de l'API Address Validation indique un degré de confiance élevé quant à la possibilité de livrer le colis à cette adresse et à son utilisation sans autre interaction avec le client dans le processus en aval.
Les champs suivants de la réponse de l'API Address Validation peuvent être utilisés en plus de verdict.possibleNextAction pour déterminer si une adresse est de qualité acceptable.
| Précision de la validation | Un validationGranularity de PREMISE est souvent acceptable, mais une valeur de ROUTE peut toujours indiquer une adresse où la livraison est possible.
|
|---|---|
| Aucune donnée inférée | Lorsque le champ hasInferredComponents est défini sur false, vous savez qu'aucun composant de la sortie n'a été inféré.
|
| Aucune donnée remplacée | Lorsque le champ hasReplacedComponents est défini sur false, vous savez qu'aucune donnée d'entrée n'a été remplacée.
|
| Aucune correction orthographique | Lorsque le champ hasSpellCorrectedComponents est défini sur false, vous savez qu'aucune correction orthographique n'a été apportée.
|
| Confirmation USPS DPV | Lorsque uspsData.dpvConfirmation est défini sur Y, cela signifie que l'adresse a été associée à une adresse de la base de données USPS. Ce champ n'est disponible que pour les adresses aux États-Unis. Pour en savoir plus sur uspsData.dpvConfirmation, consultez Gérer les adresses aux États-Unis.
|