Guide de la solution Address Validation

Diagramme de flux présentant un aperçu général des étapes de test.

Objectif

Address Validation est utile dans de nombreux cas d'utilisation. Nous vous suggérons d'explorer des points clés qui vont au-delà de la qualité brute des résultats de test. Par exemple, une vue globale des produits compatibles dans un parcours utilisateur comme Place Autocomplete et Maps, la disponibilité régionale, ainsi que la confiance et la fiabilité de l'entreprise.

Une fois que vous êtes prêt à évaluer l'API Address Validation, voici quelques consignes que nous vous recommandons de suivre pour vos tests.

Les objectifs de ce test sont les suivants :

  1. Vérifiez que l'API Address Validation est adaptée à votre cas d'utilisation.
  2. Vérifiez que l'API Address Validation répond aux exigences de vos solutions, par exemple :
    • Identifier des adresses de bonne qualité
    • Alerter pour résoudre les problèmes d'entrées de mauvaise qualité.
    • Apporter des corrections aux données d'adresse, y compris des inférences, des remplacements et des corrections orthographiques.
    • Fournir une adresse de livraison mise en forme.
    • Alerte en cas de données de sous-locaux manquantes ou incorrectes (États-Unis uniquement).
  3. Assurez-vous que l'implémentation de l'API vous apportera un avantage mesurable.

Après avoir effectué votre test, vous pourrez répondre aux questions ci-dessus et déterminer si l'API est adaptée à votre entreprise.

Préparer vos données

Votre test doit être effectué sur un échantillon de vos données d'adresse existantes. Ne sélectionnez pas les données pour le test, mais choisissez des échantillons aléatoires représentatifs des zones géographiques dans lesquelles vous opérez. Cela signifie que si vous opérez à la fois aux États-Unis et au Royaume-Uni, mais que 70% de votre activité est réalisée au Royaume-Uni contre 30% aux États-Unis, l'échantillon doit refléter cette répartition.

Utilisez les adresses du point de capture. Par exemple, si vous prévoyez d'implémenter la validation d'adresse lors du paiement sur votre site d'e-commerce, utilisez les adresses telles qu'elles ont été saisies par vos clients dans le formulaire, avant tout traitement existant qui pourrait être remplacé par l'implémentation de l'API Address Validation.

Préparez un échantillon d'environ 5 000 à 10 000 enregistrements pour le test.

Appeler l'API

Prérequis de la section : découvrez comment envoyer une requête de validation d'adresse.

Une fois les données préparées, vous devez exécuter chaque enregistrement d'adresse sur l'API.

Consultez la documentation de l'API Address Validation pour savoir comment appeler l'API. Nous avons également un article décrivant les bonnes pratiques pour utiliser l'API Address Validation afin de traiter des adresses en grand volume.

Cette étape doit générer des données de l'API pour chaque enregistrement d'adresse. Vous pourrez ensuite analyser les résultats pour déterminer si l'API est adaptée à votre cas d'utilisation. C'est à vous de décider si vous souhaitez utiliser une feuille de calcul, une base de données ou un autre outil.

Examinez les résultats.

Prérequis de la section : découvrez comment gérer la réponse de validation, en particulier les concepts de correction, de confirmation et d'acceptation.

Dans cette section, nous allons examiner les scénarios de sortie que vous pouvez analyser pour évaluer l'adéquation de la solution.

Présentation des principaux champs d'API abordés dans ce document

Données de réponse

De quoi s'agit-il ?

Comment évaluer

En quoi cela vous aide-t-il ?

verdict.inputGranularity

Décrit la précision de l'adresse saisie.

SUB_PREMISE

PREMISE

PREMISE_PROXIMITY

BLOQUER

ROUTE

OTHER

Permet de déterminer si l'adresse d'entrée contient suffisamment de données pour être potentiellement valide.

verdict.validationGranularity

Décrit la validation globale de l'adresse de sortie.

SUB_PREMISE

PREMISE

PREMISE_PROXIMITY

BLOQUER

ROUTE

OTHER

Permet de déterminer la qualité globale de l'adresse en sortie de l'API.

verdict.hasInferredComponents

Indique si l'API a déduit un composant.

Vrai ou faux

L'API peut ajouter des composants manquants lorsqu'elle peut déduire les données. Par exemple, un code d'État manquant.

verdict.hasReplacedComponents

Indique si l'API a remplacé un composant.

Vrai ou faux

Dans certains cas, l'API peut remplacer les composants incorrects par les données correctes.

verdict.addressComplete

Indique si l'adresse est complète.

Vrai ou faux

Si l'API détermine que l'adresse de sortie comporte tous les composants nécessaires, la valeur est "true".

address.missingComponentTypes

Signal permettant d'avertir si des composants sont manquants dans l'adresse.

Consultez le tableau 2 pour connaître les valeurs.

Mettez en évidence les composants manquants d'une adresse incomplète.

Examiner les adresses valides

Triez les données renvoyées par l'API pour déterminer l'ensemble d'adresses que votre système accepterait comme valides. Voici les principaux signaux à rechercher dans l'API :

  • verdict.validationGranularity contient PREMISE ou mieux.
  • verdict.addressComplete correspond à true.
  • Aucun composant inféré ou remplacé.

Pour en savoir plus, consultez Accepter une adresse.

Le résultat de cet exercice doit être un sous-ensemble des données d'adresse qui seraient acceptées comme valides par votre système. À ce stade, vous pouvez déterminer :

  • Le taux d'acceptation est-il acceptable ?
  • Si vous utilisez un workflow de validation d'adresse existant, le taux d'acceptation est-il équivalent ou supérieur ?

Exemple : Adresse valide

Adresse saisie

Région

76 Buckingham Palace Road, Londres, SW1W 9TQ, Royaume-Uni

Royaume-Uni

Verdict

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true
}

Examiner les adresses non valides

Cette étape vous permet d'examiner manuellement certaines des données d'adresse qui ont été marquées comme non valides et de voir si, sans utiliser l'API Address Validation, cette adresse non valide peut entraîner des problèmes en aval.

Triez les données renvoyées par l'API pour déterminer l'ensemble d'adresses que votre système marquerait comme non valides. Voici les principaux signaux à rechercher dans l'API :

  • verdict.validationGranularity défini sur OTHER ou ROUTE en fonction de votre niveau de risque.
  • verdict.addressComplete correspond à false.

Pour en savoir plus, consultez Corriger une adresse.

Le résultat de cet exercice doit être un sous-ensemble des données d'adresse qui seraient marquées comme non valides par votre système. À ce stade, vous pouvez déterminer si le pourcentage de trafic incorrect est acceptable.

Il est important de noter que le marquage des adresses comme non valides est une fonctionnalité essentielle de l'API Address Validation, et qu'un taux élevé d'adresses marquées comme non valides ne reflète pas nécessairement une mauvaise qualité de l'API. L'API vous informe qu'il y a un problème avec l'adresse, ce qui peut améliorer l'efficacité de votre workflow en détectant les erreurs plus tôt, avant qu'elles ne causent des problèmes en aval.

Exemple : Adresse non valide

Adresse saisie

Région

21 45 40th street

USA

Verdict

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true
}

Examiner les composants manquants ou non confirmés

À ce stade, les composants manquants ou non confirmés peuvent également être examinés. Il fait partie de l'objet Address dans la réponse. Les deux champs sont missingComponentTypes et unconfirmedComponentTypes.

Utilisez ces champs pour identifier la raison pour laquelle une adresse est marquée comme non valide par l'API, et collectez les informations correctes pour l'adresse qui lui permettraient d'être valide, en renvoyant au point de collecte des données le ou les champs spécifiques qui sont incorrects. L'API vous fournit ainsi des informations spécifiques sur la qualité de vos données.

Exemple : Composant manquant et non confirmé

Adresse saisie

Région

Fake St, New York, NY 10011

USA

Verdict

{
     "inputGranularity": "ROUTE",
     "validationGranularity": "OTHER",
     "geocodeGranularity": "OTHER",
     "hasUnconfirmedComponents": true
}

Composants manquants et non confirmés

"missingComponentTypes": [
    "street_number"
],
"unconfirmedComponentTypes": [
    "route"
]

Examiner les adresses avec corrections

L'API Address Validation peut corriger les données d'entrée, en prenant une adresse potentiellement non valide et en générant des données d'adresse valides. C'est l'un des avantages de l'API, et il est important de le prendre en compte dans le test.

Voici les principaux signaux à rechercher :

  • inferred, replaced ou spellCorrected défini sur true sur l'un des addressComponents.
  • verdict.hasInferredComponents ou verdict.hasReplacedComponents défini sur true.

Pour en savoir plus, consultez Confirmer une adresse.

Le résultat de cet exercice doit être un sous-ensemble des données d'adresse auquel une correction a été appliquée par l'API.

Une partie de ces données peut être examinée manuellement pour déterminer si l'API apporte des corrections à vos données qui réduiraient les frictions dans votre workflow en aval.

Exemple : Adresse avec une correction

Adresse saisie

Région

76 Buckingham Palace Road, Londres, SW1W 9TQ, Royaume-Uni

Royaume-Uni

Route addressComponent

{
    "componentName": {
        "text": "Buckingham Palace Road",
        "languageCode": "en"
    },
    "componentType": "route",
    "confirmationLevel": "CONFIRMED",
    "spellCorrected": true
}

[États-Unis uniquement] Examiner l'adresse avec des données de sous-bâtiment manquantes ou incorrectes

L'API Address Validation peut déterminer si un complément d'adresse est manquant ou incorrect pour les adresses aux États-Unis.

Voici les principaux signaux à rechercher :

  • Dans l'objet Address :
    • unconfirmedComponentTypes contient subpremise
    • missingComponentTypes contient subpremise
  • Dans l'objet UspsData :
    • dpvConfirmation est D (sous-bâtiment manquant)
    • dpvConfirmation est S (sous-bâtiment non confirmé)

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

Ce test permet de déterminer si vos données présentent un problème de sous-locaux manquants ou incorrects, comme des numéros d'appartement. Cela peut entraîner des problèmes en aval, en particulier pour les cas d'utilisation de livraison. L'API Address Validation peut ajouter de la valeur à votre workflow en identifiant ce problème plus tôt, ce qui vous permet de mettre en œuvre des étapes pour collecter des données corrigées.

Exemple : Sous-bâtiment manquant

Adresse saisie

Région

111 8th Avenue, Manhattan, NY 10011

États-Unis

Composant manquant

"missingComponentTypes": [
    "subpremise"
]

Confirmation de la validation du point de distribution (DPV) des données USPS

"dpvConfirmation": "D"

[USA only] Review USPS standardizedAddress

L'API Address Validation renvoie également l'adresse normalisée USPS pour les adresses aux États-Unis. Cela est particulièrement important si vous avez besoin que les adresses au format USPS soient imprimées sur vos étiquettes de livraison.

Vous pouvez examiner UspsAddress pour afficher ces données et déterminer si elles ajoutent de la valeur à votre workflow.

Exemple : Adresse standardisée par l'USPS

"standardizedAddress": {
    "firstAddressLine": "111 8TH AVE FL 11",
    "cityStateZipAddressLine": "NEW YORK NY 10011-5201",
    "city": "NEW YORK",
    "state": "NY",
    "zipCode": "10011",
    "zipCodeExtension": "5201"
}

Conclusion

Commencez à tester l'API Address Validation dès aujourd'hui pour garantir l'exactitude des données d'adresse, améliorer l'expérience client et simplifier vos opérations commerciales. Après avoir suivi les scénarios de test décrits ci-dessus, vous disposerez des informations nécessaires pour déterminer si l'API Address Validation apportera de la valeur à votre workflow.

Suggestions de lecture :

Contributeurs

Henrik Valve | Ingénieur DevX