Créer une logique de validation

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. Vous apprendrez à créer votre logique pour utiliser correctement la réponse, à examiner d'autres signaux de l'API, et à 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 est de mauvaise qualité. Vous devez demander plus d'informations.
  • Confirmer : l'adresse est de bonne qualité, mais elle a été modifiée par rapport à l'adresse saisie. Vous pouvez demander une confirmation.
  • Accepter : l'adresse est de haute qualité. Vous pouvez accepter l'adresse fournie.

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 (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

La logique exacte dépend de votre situation. Pour en savoir plus, consultez les conseils d'implémentation. Vous pouvez également utiliser notre implémentation Open Source de cette logique, qui se trouve dans la bibliothèque de composants étendue.

Présentation du workflow

Le tableau ci-dessous récapitule deux actions pour votre système :

  1. Workflow à utiliser en fonction du comportement de correction, de confirmation et d'acceptation.
  2. Les premiers signaux à vérifier dans la réponse. Les signaux décrits ici proviennent de la propriété verdict et ne sont pas les seuls signaux à vérifier, mais ils fournissent une indication initiale de la qualité de l'adresse. Chaque type de comportement correspond à une section de ce document décrivant d'autres signaux que vous pourriez également devoir examiner.
Comportement de votre système
Corriger l'adresse

La réponse de verdict indique des informations importantes manquantes qui devraient être fournies. Il est possible que l'adresse renvoyée par l'API ne soit pas de qualité suffisante pour la livraison.

Workflow

  1. Si nécessaire, examinez les composants de l'adresse.
  2. Invitez le client à corriger les problèmes d'adresse.
  3. Demandez la validation de la nouvelle adresse.
  4. Poursuivez avec l'adresse.

Signaux de verdict

L'une des conditions suivantes s'applique :
Confirmer l'adresse

La réponse de verdict indique une adresse de livraison, mais a apporté des modifications à l'entrée d'origine. Elle infère des données dont l'orthographe a été corrigée ou qui peuvent être confirmées.

Workflow

  1. Corrections nécessaires :
    1. Si nécessaire, examinez les composants de l'adresse.
    2. Demandez la validation de la nouvelle adresse.
    3. Poursuivez avec l'adresse.
  2. Aucune correction n'est nécessaire :
  3. Poursuivez avec l'adresse.

Signaux de verdict

Toutes les conditions suivantes s'appliquent :
Accepter l'adresse

La réponse de l'API Address Validation indique une adresse d'excellente qualité.

Workflow

Poursuivez avec l'adresse de retour.

Signaux de verdict

Toutes les conditions suivantes s'appliquent :

Instructions relatives à la mise en œuvre

Lorsque vous concevez la façon dont votre système répond aux signaux de validation d'adresse, 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 le numéro de rue d'une adresse n'est pas 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 de ces 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.

Corriger une adresse

Corrigez une adresse lorsque les résultats indiquent clairement qu'elle n'est 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.

Corriger les signaux

L'API Address Validation fournit un certain nombre de signaux pour vous indiquer si une adresse doit être corrigée.

1. Granularité de la validation et composants manquants

Ces deux signaux sont les meilleurs indicateurs d'une adresse problématique :

  • Chaque fois que le champ validationGranularity est défini sur OTHER, votre système doit examiner les signaux des composants d'adresse pour en savoir plus sur l'origine de l'erreur et sur la façon de la corriger.
  • Chaque fois que l'objet address post-traité renvoie un champ missingComponentTypes, votre système doit rechercher ce composant. Si des éléments sont manquants, l'adresse est également considérée comme incomplète et la livraison ne peut pas être effectuée.

2. Autres signaux

L'API Address Validation fournit également d'autres signaux pour vous aider à diagnostiquer des problèmes spécifiques :

Composants suspects Lorsque l'énumération du niveau de confirmation d'un composant est UNCOMFIRMED_AND_SUSPICIOUS, il est probable que le composant soit incorrect.
Composant non résolu Un unresolvedToken est une partie de l'entrée qui n'est pas reconnue comme une partie valide d'une adresse.

3. Signaux d'adresse aux États-Unis

Certains champs applicables uniquement aux adresses aux États-Unis fournissent un signal utile indiquant que l'adresse n'est pas valide et doit être corrigée. Si une adresse doit être corrigée, le message suivant s'affiche :

dpvConfirmation N, D ou vide.

Pour en savoir plus sur dpvConfirmation, consultez Gérer les adresses aux États-Unis.

Exemples de correction d'adresses

Confirmer une adresse

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.

Pour fournir au client la bonne invite, votre logique identifierait les composants signalés par le service afin de déterminer l'action ou le signalement que l'API a appliqué au composant, comme inferred, replaced ou spellCorrected. Consultez AddressComponent dans la documentation de référence.

Confirmer les signaux

L'API Address Validation fournit un certain nombre de signaux pour vous indiquer si une adresse doit être confirmée.

1. Précision de la validation

Un validationGranularity de ROUTE ou plus est acceptable, mais PREMISE ou SUBPREMISE fournissent un signal plus fort de délivrabilité.

2. Autres signaux

Lorsque vous décidez de confirmer l'adresse saisie avec le client, le verdict fournit également les informations suivantes pour déterminer les composants à examiner :

Données inférées Lorsque le champ hasInferredComponents est défini sur true, cela signifie 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.

3. Signaux d'adresse aux États-Unis

Certains champs applicables uniquement aux adresses aux États-Unis indiquent que votre logique doit confirmer les informations avec le client. L'une des conditions suivantes s'applique :

dpvConfirmation S

Pour en savoir plus sur dpvConfirmation, consultez Gérer les adresses aux États-Unis.
Réponse d'adresse Contient le champ missingComponentTypes avec la valeur subpremise.

Exemples de confirmation d'adresse

Accepter une adresse

Vous acceptez une adresse lorsque le verdict indique avec un degré de confiance élevé que l'adresse est distribuable et peut être utilisée sans autre interaction avec le client dans le processus en aval.

Accepter les signaux

L'API Address Validation fournit un certain nombre de signaux pour vous indiquer si une adresse doit être confirmée.

1. Précision de la validation

Un validationGranularity de PREMISE ou plus est acceptable, mais dans certains cas, ROUTE indique toujours une adresse de livraison.

2. Autres signaux

Un verdict pour une adresse de haute qualité doit également fournir les informations suivantes :

  • Aucune donnée remplacée. Dans le cas présent : hasReplacedComponents: FALSE.
  • Aucun composant inféré. Dans le cas présent : hasInferredComponents: FALSE.

3. Signaux d'adresse aux États-Unis

Certains champs applicables uniquement aux adresses aux États-Unis indiquent une adresse de haute qualité à laquelle la livraison peut être effectuée. Pour une adresse américaine valide, vous devriez voir les éléments suivants :

dpvConfirmation Y

Pour en savoir plus sur dpvConfirmation, consultez Gérer les adresses aux États-Unis.

Exemples d'adresses acceptées