Créer une logique de validation

Ce document décrit un processus de création d'un système de vérification d'adresse pour gérer différentes réponses de l'API Address Validation. Il explique comment créer votre logique pour utiliser correctement la réponse, examiner d'autres signaux de l'API, et quand et comment demander plus d'informations à vos clients.

En général, la réponse de l'API détermine les façons suivantes dont votre système doit gérer une adresse :

  • Corriger : l'adresse est de mauvaise qualité. Vous devez demander plus d'informations.
  • Confirm (Confirmer) : l'adresse est de haute qualité, mais elle a été modifiée par rapport à l'adresse d'entrée. Vous pouvez demander une confirmation.
  • Accept : 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 à effectuer 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. Le 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 à vérifier, mais ils fournissent un premier indicateur de la qualité de l'adresse. Chaque type de comportement correspond à une section de ce document décrivant d'autres signaux que vous devrez peut-être également examiner.
Le comportement de votre système
Corriger l'adresse

La réponse de verdict indique qu'il manque des informations importantes qui doivent être fournies. L'adresse renvoyée par l'API n'est peut-être pas de qualité suffisante pour la livraison.

Workflow

  1. Examinez les composants de l'adresse si nécessaire.
  2. Invitez le client à corriger les problèmes d'adresse.
  3. Demandez la validation de l'adresse mise à jour.
  4. Continuer avec l'adresse.

Signaux d'évaluation

L'un des éléments suivants s'applique :
Confirmer l'adresse

La réponse de verdict indique une adresse livrable, mais des modifications ont été apportées à l'entrée d'origine : déduction de données dont l'orthographe a été corrigée ou de données pouvant être confirmées.

Workflow

  1. Corrections nécessaires :
    1. Examinez les composants de l'adresse si nécessaire.
    2. Demandez la validation de l'adresse mise à jour.
    3. Continuer avec l'adresse.
  2. Aucune correction nécessaire :
  3. Continuer avec l'adresse.

Signaux d'évaluation

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

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

Workflow

Poursuivre avec l'adresse renvoyée.

Signaux d'évaluation

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. Gardez à l'esprit 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 de votre situation lorsque vous devez choisir entre demander des corrections et accepter l'adresse telle qu'elle a été saisie.

L'API Address Validation renvoie divers 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 toujours l'accepter. En revanche, si votre activité nécessite une plus grande précision d'adresse, vous pouvez inviter l'utilisateur à la fournir. Pour obtenir un exemple pouvant appartenir à l'une ou l'autre catégorie, consultez Numéro de rue non confirmé en dehors des É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 requêtes.

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 livrable. Votre système peut alors inviter le client à fournir les informations nécessaires, après quoi vous rééditez 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. Précision de la validation et composants manquants

Ces deux signaux fournissent la meilleure indication 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'emplacement 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. S'il manque des composants, l'adresse est également incomplète et non distribuable.

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 américaines fournissent un signal utile indiquant que l'adresse n'est pas livrable et doit être corrigée. Pour une adresse qui doit être corrigée, vous devriez voir ce qui suit :

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 déduit 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 vous assurer que l'adresse obtenue est bien celle prévue par le client.

Pour fournir au client l'invite appropriée, votre logique identifierait les composants signalés par le service afin de déterminer l'action ou l'indicateur que l'API a appliqué au composant, par exemple 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 de délivrabilité plus fort.

2. Autres signaux

Lorsque vous décidez de confirmer la saisie de l'adresse auprès du client, le verdict fournit également les éléments suivants pour déterminer les composants à examiner :

Données inférées Lorsque le champ hasInferredComponents est défini sur true, vous savez que l'API a renseigné 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 détails auprès du 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 d'adresses de confirmation

Accepter une adresse

Vous acceptez une adresse lorsque le verdict indique avec un degré de confiance élevé que l'adresse est livrable 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

Le verdict d'une adresse de haute qualité doit également fournir les éléments suivants :

  • 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 américaines indiquent une adresse de haute qualité à laquelle la livraison est possible. Pour une adresse américaine acceptable, vous devriez voir ce qui suit :

dpvConfirmation Y

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

Exemples d'adresses acceptées