Guide de validation d'adresses à grand volume

Objectif

En tant que développeur, vous travaillez souvent avec des ensembles de données contenant des adresses de clients qui ne sont pas forcément de bonne qualité. Vous devez vous assurer que les adresses sont correctes pour des cas d'utilisation allant de la validation de l'identité du client à la livraison, et plus encore.

L'API Address Validation est un produit de Google Maps Platform que vous pouvez utiliser pour valider une adresse. Toutefois, il ne traite qu'une seule adresse à la fois. Dans ce document, nous allons voir comment utiliser la validation d'adresse à volume élevé dans différents scénarios, des tests d'API à la validation d'adresse ponctuelle et récurrente.

Cas d'utilisation

Nous allons maintenant examiner les cas d'utilisation dans lesquels la validation d'adresses à volume élevé est utile.

Tests

Vous souhaitez souvent tester l'API Address Validation en exécutant des milliers d'adresses. Vous pouvez avoir les adresses dans un fichier de valeurs séparées par une virgule et vouloir valider la qualité des adresses.

Validation unique des adresses

Lors de l'intégration à l'API Address Validation, vous souhaitez valider votre base de données d'adresses existante par rapport à la base de données utilisateur.

Validation récurrente des adresses

Plusieurs scénarios nécessitent de valider les adresses de manière récurrente :

  • Vous pouvez avoir planifié des jobs pour valider les adresses des informations collectées au cours de la journée, par exemple à partir des inscriptions de clients, des détails des commandes ou des calendriers de livraison.
  • Vous pouvez recevoir des dumps de données contenant des adresses de différents services, par exemple des ventes au marketing. Le nouveau service qui reçoit les adresses souhaite souvent les valider avant de les utiliser.
  • Vous pouvez collecter des adresses lors d'enquêtes ou de diverses promotions, puis les mettre à jour dans le système en ligne. Vous souhaitez valider l'exactitude des adresses lors de leur saisie dans le système.

Détails techniques

Dans ce document, nous partons du principe que :

  • Vous appelez l'API Address Validation avec des adresses provenant d'une base de données client (c'est-à-dire une base de données contenant des informations sur les clients).
  • Vous pouvez mettre en cache les indicateurs de validité pour des adresses individuelles dans votre base de données.
  • Les indicateurs de validité sont récupérés à partir de l'API Address Validation lorsqu'un client se connecte.

Cache pour une utilisation en production

Lorsque vous utilisez l'API Address Validation, vous souhaitez souvent mettre en cache une partie de la réponse de l'appel d'API. Bien que nos Conditions d'utilisation limitent les données pouvant être mises en cache, toutes les données pouvant être mises en cache à partir de l'API Address Validation doivent être mises en cache pour un compte utilisateur. Cela signifie que dans la base de données, l'adresse ou les métadonnées d'adresse doivent être mises en cache par rapport à l'adresse e-mail de l'utilisateur ou à un autre ID principal.

Pour le cas d'utilisation de la validation d'adresses à volume élevé, la mise en cache des données doit respecter les Conditions spécifiques au service de l'API Address Validation, décrites dans la section 11.3. En fonction de ces informations, vous pourrez déterminer si l'adresse d'un utilisateur n'est pas valide. Dans ce cas, vous l'inviterez à la corriger lors de sa prochaine interaction avec votre application.

  • Données de l'objet AddressComponent
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

Si vous souhaitez mettre en cache des informations sur l'adresse réelle, vous ne devez le faire qu'avec le consentement de l'utilisateur. Cela permet de s'assurer que l'utilisateur sait pourquoi un service particulier stocke son adresse et qu'il accepte les conditions de partage de son adresse.

Par exemple, l'utilisateur peut interagir directement avec un formulaire d'adresse d'e-commerce sur une page de paiement. Il est entendu que vous allez mettre en cache et traiter l'adresse pour expédier un colis.

Avec l'autorisation de l'utilisateur, vous pouvez mettre en cache formattedAddress et d'autres composants clés de la réponse. Toutefois, dans un scénario sans interface graphique, un utilisateur ne peut pas donner son consentement, car la validation de l'adresse s'effectue à partir du backend. Par conséquent, vous ne pouvez mettre en cache que des informations très limitées dans ce scénario sans interface graphique.

Comprendre la réponse

Si la réponse de l'API Address Validation contient les repères suivants, vous pouvez être sûr que l'adresse saisie est de qualité suffisante pour la livraison :

  • Le repère addressComplete de l'objet Verdict est true,
  • Le champ validationGranularity de l'objet Verdict est défini sur PREMISE ou SUB_PREMISE.
  • Aucun des AddressComponent n'est marqué comme suit :
    • Inferred(Remarque : : inferred=truepeut se produire lorsque addressComplete=true)
    • spellCorrected
    • replaced
    • unexpected et
  • confirmationLevel : le niveau de confirmation sur AddressComponent est défini sur CONFIRMED ou UNCONFIRMED_BUT_PLAUSIBLE.

Si la réponse de l'API ne contient pas les repères ci-dessus, l'adresse d'entrée était probablement de mauvaise qualité. Vous pouvez mettre en cache des indicateurs dans votre base de données pour en tenir compte. Les indicateurs mis en cache indiquent que l'adresse dans son ensemble est de mauvaise qualité, tandis que des indicateurs plus détaillés, tels que "Spell Corrected" (Orthographe corrigée), indiquent le type spécifique de problème de qualité de l'adresse. Lors de la prochaine interaction du client avec une adresse signalée comme étant de mauvaise qualité, vous pouvez appeler l'API Address Validation avec l'adresse existante. L'API Address Validation renvoie l'adresse corrigée, que vous pouvez afficher à l'aide d'une invite d'interface utilisateur. Une fois que le client a accepté l'adresse mise en forme, vous pouvez mettre en cache les éléments suivants de la réponse :

  • formattedAddress
  • postalAddress
  • addressComponent componentNamesou
  • UspsData standardizedAddress

Implémenter une validation d'adresse sans interface graphique

D'après la discussion ci-dessus :

  • Il est souvent nécessaire de mettre en cache une partie de la réponse de l'API Address Validation pour des raisons professionnelles.
  • Toutefois, les Conditions d'utilisation de Google Maps Platform limitent les données pouvant être mises en cache.

Dans la section suivante, nous allons voir comment respecter les conditions d'utilisation et implémenter la validation d'adresses à volume élevé en deux étapes.

Étape 1 :

Dans la première étape, nous verrons comment implémenter un script de validation d'adresses à volume élevé à partir d'un pipeline de données existant. Ce processus vous permettra de stocker des champs spécifiques de la réponse de l'API Address Validation d'une manière conforme aux conditions d'utilisation.

Schéma A : le schéma suivant montre comment un pipeline de données peut être amélioré avec une logique de validation d'adresses à volume élevé.

alt_text

Conformément aux conditions d'utilisation, vous pouvez mettre en cache les données suivantes de l'addressComponent :

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

Par conséquent, lors de cette étape de l'implémentation, nous mettrons en cache les champs mentionnés ci-dessus par rapport au UserID.

Pour en savoir plus, consultez les détails sur la structure de données réelle.

Étape 2 :

À l'étape 1, nous avons recueilli des commentaires indiquant que certaines adresses de l'ensemble de données d'entrée n'étaient peut-être pas de haute qualité. À l'étape suivante, nous allons présenter ces adresses signalées à l'utilisateur et obtenir son consentement pour corriger l'adresse stockée.

Diagramme B : ce diagramme montre à quoi pourrait ressembler une intégration de bout en bout du flux de consentement de l'utilisateur :

alt_text

  1. Lorsque l'utilisateur se connecte, vérifiez d'abord si vous avez mis en cache des indicateurs de validation dans votre système.
  2. Si des indicateurs sont présents, vous devez présenter à l'utilisateur une UI lui permettant de corriger et de mettre à jour son adresse.
  3. Vous pouvez appeler à nouveau l'API Address Validation avec l'adresse mise à jour ou mise en cache, et présenter l'adresse corrigée à l'utilisateur pour confirmation.
  4. Si l'adresse est de bonne qualité, l'API Address Validation renvoie un formattedAddress.
  5. Vous pouvez présenter cette adresse à l'utilisateur si des corrections ont été apportées, ou l'accepter sans l'en informer s'il n'y a pas de corrections.
  6. Une fois que l'utilisateur a accepté, vous pouvez mettre en cache le formattedAddress dans la base de données.

Conclusion

La validation d'adresses à volume élevé est un cas d'utilisation courant que vous rencontrerez probablement dans de nombreuses applications. Ce document présente quelques scénarios et un modèle de conception pour implémenter une telle solution conformément aux conditions d'utilisation de Google Maps Platform.

Nous avons également écrit une implémentation de référence de la validation d'adresses à volume élevé sous la forme d'une bibliothèque Open Source sur GitHub. Consultez-le pour commencer à utiliser rapidement la validation d'adresses à volume élevé. Consultez également l'article sur les modèles de conception pour savoir comment utiliser la bibliothèque dans différents scénarios.

Étapes suivantes

Téléchargez le livre blanc Améliorer les processus de paiement, de livraison et les opérations avec des adresses fiables et regardez le webinaire Améliorer les processus de paiement, de livraison et les opérations avec Address Validation .

Suggestions de lecture :

Contributeurs

Google gère cet article. Les contributeurs suivants l'ont rédigé à l'origine.
Auteurs principaux :

Henrik Valve | Ingénieur solutions
Thomas Anglaret | Ingénieur solutions
Sarthak Ganguly | Ingénieur solutions