Créer votre 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 découvrirez comment créer votre logique pour utiliser correctement la réponse, examiner d'autres signaux de l'API, et quand et comment inviter vos clients à fournir plus d'informations.

En général, la réponse de l'API détermine comment votre système doit gérer une adresse:

• Solution : l'adresse est de mauvaise qualité. Vous devriez demander plus d'informations.
• Confirmer : l'adresse est de haute qualité, mais celle d'entrée a changé. Vous pouvez être invité à confirmer l'opération.
• Accepter : l'adresse est de haute qualité. Vous pouvez accepter l'adresse fournie.

Objectif de la clé

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 pseudo-code 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 instructions d'implémentation. Vous pouvez également utiliser notre implémentation Open Source de cette logique, qui se trouve dans la bibliothèque de composants étendus.

Présentation du workflow

Le tableau ci-dessous récapitule deux actions effectuées par votre système:

1. Le workflow à utiliser en fonction du comportement correct, confirmation et accepté.
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 fournissent un indicateur initial de la qualité de l'adresse. Chaque type de comportement correspond à une section de ce document qui décrit d'autres signaux que vous devrez peut-être également étudier.

Comportement du système
Corriger l'adresse	La réponse de verdict indique des informations importantes manquantes qui doivent être fournies. Il est possible que l'adresse renvoyée par l'API Address Validation ne soit pas de bonne qualité. Workflow Examinez les composants d'adresse, si nécessaire. Invitez le client à corriger les problèmes. Demandez la validation de l'adresse mise à jour. (Facultatif) Envoyez une requête au point de terminaison "feedback" pour l'API. Consultez Gérer les adresses mises à jour. Indiquez l'adresse. Signaux d'évaluation L'une des conditions suivantes s'applique: validationGranularity définie sur OTHER. Consultez les valeurs de précision. addressComplete est false.
Confirmer l'adresse	La réponse de verdict indique une adresse de livraison, mais a apporté des modifications à l'entrée d'origine: inférer des données qui ont été corrigées ou qui peuvent être confirmées. Workflow Corrections nécessaires : Examinez les composants d'adresse, si nécessaire. Demandez la validation de l'adresse mise à jour. (Facultatif) Envoyez une requête au point de terminaison "feedback" pour l'API. Consultez Gérer les adresses mises à jour. Indiquez l'adresse. Aucune correction requise: (Facultatif) Envoyez une requête au point de terminaison "feedback" pour l'API. Consultez Gérer les adresses mises à jour. Indiquez l'adresse. Signaux d'évaluation Toutes les conditions suivantes s'appliquent: validationGranularity contient ROUTE ou plus. Consultez les valeurs de précision. addressComplete est true. Le champ hasInferredComponents est true OU le champ hasReplacedComponents est true.
Accepter l'adresse	La réponse de l'API Address Validation indique une adresse d'excellente qualité. Workflow Procédez avec l'adresse renvoyée. Signaux d'évaluation Toutes les conditions suivantes s'appliquent: validationGranularity contient PREMISE ou plus. Consultez les valeurs de précision. addressComplete est true. Aucun composant inféré ou remplacé.

Instructions relatives à la mise en œuvre

Lorsque vous concevez la manière 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. Cependant, il ne s'agit que de recommandations. Gardez donc à l'esprit que votre implémentation doit être adaptée à votre modèle économique.

	Consignes	Détails
Niveau de risque	Tenez compte du niveau de tolérance de votre situation au moment de trouver le bon équilibre entre la demande de corrections et l'acceptation de l'adresse 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 vos activités commerciales nécessitent une plus grande précision des adresses, vous pouvez envoyer une invite à l'utilisateur. Pour obtenir un exemple correspondant à l'une ou l'autre catégorie, consultez la section Numéro de rue non confirmé en dehors des États-Unis dans Accepter l'adresse : exemples.
Accepter les adresses	Il est recommandé de permettre à votre système d'accepter l'entrée d'origine si le client ne répond pas aux invites.	Dans ce cas, le client peut avoir saisi une adresse qui ne figure pas dans le système (pour une nouvelle construction, par exemple).
Envoyer un commentaire	Lorsque vous renvoyez une demande de validation d'adresse, vous pouvez également envoyer une requête au point de terminaison provideValidationFeedback.	Cela permet à Google de savoir comment vous avez finalement géré la réponse finale. Consultez Gérer les adresses mises à jour.

Essayez la démonstration. Le reste de ce document utilise différents exemples pour vous aider à comprendre le processus de correction, de confirmation et d'acceptation décrit ci-dessus. Vous pouvez examiner les résultats de ces exemples en les saisissant dans la démonstration de l'API Address Validation.

Corriger une adresse

Corrigez une adresse lorsque les résultats indiquent clairement qu'elle ne peut pas être livrée. Votre système peut ensuite inviter le client à fournir les informations nécessaires, puis vous émettez à nouveau votre workflow pour obtenir l'adresse du produit livrable.

Remarque :Lorsque vous répétez des requêtes adressées à l'API Address Validation pour la même adresse, vous pouvez appeler provideValidationFeedback pour indiquer votre résultat. Consultez Gérer les adresses aux États-Unis.

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

Les deux signaux suivants sont le meilleur indicateur 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 savoir où l'erreur s'est produite et comment la corriger.
• Chaque fois que l'objet address post-traité renvoie un champ missingComponentTypes, votre système doit rechercher ce composant. L'absence d'éléments individuels peut également entraîner l'envoi d'une adresse incomplète et impossible de livrer le colis.

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 non reconnue comme une partie valide d'une adresse.

3. Signaux d'adresse aux États-Unis

Certains champs applicables uniquement aux adresses aux États-Unis indiquent utile que l'adresse ne peut pas être livrée et qu'elle doit être corrigée. Pour une adresse qui doit être corrigée, vous devriez obtenir le résultat suivant:

dpvConfirmation	N, D ou vide.

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

Corriger des exemples d'adresses

Confirmer une adresse

Vous confirmez une adresse lorsque le verdict indique que l'API Address Validation a inféré ou apporté des modifications aux composants d'adresse afin de générer 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 celle que le client souhaite obtenir.

Pour fournir au client l'invite appropriée, votre logique identifie les composants signalés par le service afin de déterminer l'action ou l'indicateur que l'API applique au composant, tels que inferred, replaced ou spellCorrected. Consultez la section AddressComponent dans la documentation de référence.

Remarque :Tenez compte de votre niveau de risque lorsque vous décidez de confirmer l'adresse avec le client ou de l'accepter comme valide. En outre, si vous renvoyez des requêtes à l'API Address Validation, vous pouvez appeler provideValidationFeedback pour indiquer votre résultat. Consultez la section Gérer les adresses mises à jour.

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 supérieur ou égal à ROUTE est acceptable, mais l'option PRÉMISE ou SOUS-PREMIER fournit un signal plus fort de livraison.

2. Autres signaux

Lorsque vous décidez de confirmer la saisie d'une adresse avec le client, l'évaluation fournit également les éléments suivants pour déterminer les composants à examiner:

Données déduites	Lorsque le champ hasInferredComponents est défini sur true, vous savez que l'API a rempli des informations qu'elle a collectées auprès 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 celles qu'elle jugeait valides.

3. Signaux d'adresse aux États-Unis

Certains champs ne s'appliquant qu'aux adresses aux États-Unis indiquent que votre logique doit confirmer les informations auprès du client. Les deux cas de figure suivants s'appliquent:

dpvConfirmation	S Pour en savoir plus sur dpvConfirmation, consultez Gérer les adresses aux États-Unis.
Réponse à l'adresse	Contient un champ missingComponentType avec la valeur subpremise. Remarque: Si le champ contient des types autres que subpremise, l'action appartient à la catégorie d'adresse corrigée. Consultez la liste complète des types d'adresses dans la documentation sur Geocoding.

Confirmer les exemples d'adresses

Accepter une adresse

Vous acceptez une adresse lorsque le verdict fournit un niveau de confiance élevé que celle-ci est un produit livrable et qu'elle peut être utilisée sans interaction supplémentaire du 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 supérieur ou égal à PREMISE 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 aux États-Unis indiquent une adresse de haute qualité pouvant être livrée. Pour une adresse aux États-Unis acceptable, vous devez obtenir les informations suivantes:

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

Accepter des exemples d'adresses