Créer une logique de validation

Ce document décrit un processus de création d'un système de vérification d'adresses permettant de 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.
• 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 bonne 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 à 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 instructions relatives à la mise en œuvre . Vous pouvez également utiliser notre mise en œuvre 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 signaux à vérifier, mais ils fournissent un indicateur initial 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.

Comportement de votre système
Corriger l'adresse	La réponse de verdict indique des informations importantes manquantes information qui doivent être fournies. L'adresse renvoyée par l'API n'est peut-être pas de qualité suffisante pour être livrée. Workflow Examinez les composants de l'adresse si nécessaire. Demandez au client de corriger les problèmes d'adresse. Demandez la validation de l'adresse mise à jour. Continuez avec l'adresse. Signaux de verdict L'un des éléments suivants s'applique : validationGranularity est défini sur OTHER. addressComplete est false.
Confirmer l'adresse	La réponse de verdict indique une adresse livrable , mais elle a été modifiée par rapport à l'entrée d'origine : inférence de données dont l'orthographe a été corrigée ou données pouvant être confirmées. Workflow Corrections nécessaires : Examinez les composants de l'adresse si nécessaire. Demandez la validation de l'adresse mise à jour. Continuez avec l'adresse. Aucune correction nécessaire : Continuez avec l'adresse. Signaux de verdict Tous les éléments suivants s'appliquent : validationGranularity contient ROUTE addressComplete est true. hasInferredComponents le champ est true OU hasReplacedComponents le champ est true.
Accepter l'adresse	La réponse de l'API Address Validation indique une adresse d'excellente qualité. Workflow Continuez avec l'adresse renvoyée. Signaux de verdict Tous les éléments suivants s'appliquent : validationGranularity contient PREMISE ou une valeur supérieure. addressComplete est true. Aucun composant inféré ou remplacé.

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 donc pas que votre mise en œuvre 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 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 process. 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 de l'adresse, vous pouvez demander à l'utilisateur de la saisir. Pour obtenir un exemple qui pourrait appartenir à 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é d'autoriser votre système à accepter l'entrée d'origine si le client ne répond pas aux invites.	Dans ce cas, le client a peut-être saisi une adresse qui ne figure pas dans le système, par exemple pour une nouvelle construction.

Tester la fonctionnalité 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 explorer les résultats de ces exemples en les saisissant dans la démo de l'API Address Validation dans Maps JavaScript.

Corriger une adresse

Corrigez une adresse lorsque les résultats indiquent clairement qu'elle n'est pas livrable. Votre système peut alors demander au client de fournir les informations nécessaires, après quoi vous réémettez votre workflow pour obtenir une adresse livrable.

Signaux de correction

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 validationGranularity champ est OTHER, votre système doit examiner les signaux des composants de l'adresse pour en savoir plus sur l'origine de l'erreur et comment la corriger.
• Chaque fois que l'objet address post-traité renvoie un champ missingComponentTypes, votre système doit vérifier ce composant. Les composants manquants rendent également une adresse incomplète et non livrable.

2. Autres signaux

L'API Address Validation fournit également les 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 livrable et doit être corrigée. Pour une adresse qui nécessite une correction, vous devriez voir les éléments suivants :

dpvConfirmation	N, D ou vide.

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

Exemples de correction d'adresse

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 afin de produire une adresse validée. Dans ce cas, vous disposez d'une adresse livrable, mais vous préférez être plus sûr que l'adresse résultante est celle souhaitée par le client.

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 a appliqué au composant, tel que inferred, replaced ou spellCorrected. Consultez AddressComponent dans la documentation de référence.

Remarque : Tenez compte de votre niveau de risque lorsque vous décidez de confirmer l'adresse auprès du client ou de l'accepter comme valide.

Signaux de confirmation

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

Une validationGranularity de ROUTE ou plus est acceptable, mais PREMISE ou SUBPREMISE fournit un signal plus fort de livrabilité.

2. Autres signaux

Lorsque vous décidez de confirmer l'adresse saisie 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 hasInferredComponents champ est true, vous savez que l'API a rempli les informations qu'elle a recueillies à partir d'autres composants d'adresse.
Données remplacées	Lorsque le hasReplacedComponents champ est 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 auprès du client. L'un des éléments suivants 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 de subpremise. Remarque : Si le champ contient des types autres que subpremise, l'action appartient à la catégorie de correction d'adresse. Consultez la liste complète des types d'adresses dans la documentation sur le géocodage.

Exemples de confirmation d'adresse

Accepter une adresse

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

Signaux d'acceptation

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

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

2. Autres signaux

Un verdict pour une adresse de haute qualité doit également fournir les éléments suivants :

• Aucune donnée remplacée. Dans ce cas, hasReplacedComponents: FALSE.
• Aucun composant inféré. Dans ce cas, hasInferredComponents: FALSE.

3. Signaux d'adresse aux États-Unis

Certains champs applicables uniquement aux adresses aux États-Unis indiquent une adresse de haute qualité qui peut être livrée. Pour une adresse aux États-Unis acceptable, 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'acceptation d'adresse