Utiliser l'API Address Validation pour traiter des adresses à volume élevé

Objectif

En tant que développeur, vous travaillez souvent avec des ensembles de données contenant des adresses client qui peuvent ne pas être de bonne qualité. Vous devez vous assurer que les adresses sont correctes pour les cas d'utilisation allant de la validation du numéro client à la livraison, etc.

L'API Address Validation est un produit de Google Maps Platform qui vous permet de valider une adresse. Cependant, il ne traite qu'une seule adresse à la fois. Dans ce document, nous allons voir comment utiliser la validation d'adresses à 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 comprendre les cas d'utilisation dans lesquels la validation d'adresses à volume élevé est utile.

Test

Vous souhaitez souvent tester l'API Address Validation en exécutant des milliers d'adresses. Les adresses peuvent figurer dans un fichier de valeurs séparées par des virgules et vous souhaitez peut-être en valider la qualité.

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

Un certain nombre de scénarios nécessitent de valider des adresses de manière récurrente:

  • Vous avez peut-être planifié des tâches pour valider des adresses pour les détails capturés au cours de la journée (inscriptions des clients, détails des commandes, calendriers de livraison, etc.).
  • Vous pouvez recevoir des vidages de données contenant des adresses de différents services (des ventes au marketing, par exemple). 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 lors de diverses promotions, puis lors des mises à jour du système en ligne. Vous voulez vérifier que les adresses sont correctes lors de leur saisie dans le système.

Détails techniques

Dans le cadre de 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 client).
  • Vous pouvez mettre en cache des indicateurs de validité pour des adresses individuelles de votre base de données.
  • Les indicateurs de validité sont récupérés depuis 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 depuis l'API Address Validation doivent être mises en cache pour un compte utilisateur. Cela signifie que dans la base de données, les métadonnées d'adresse ou d'adresse doivent être mises en cache pour l'adresse e-mail de l'utilisateur ou tout autre ID principal.

Pour le cas d'utilisation de la validation d'adresses en 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. Grâce à ces informations, vous pourrez déterminer si l'adresse d'un utilisateur peut être incorrecte. Dans ce cas, vous lui demanderez une adresse corrigée 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, ces données ne doivent être mises en cache 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.

L'interaction directe avec un formulaire d'adresse d'e-commerce sur une page de paiement est un exemple de consentement de l'utilisateur. Il est entendu que vous mettrez en cache et traiterez l'adresse afin d'expédier un colis.

Avec le consentement 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, l'utilisateur ne peut pas donner son consentement, car la validation de l'adresse s'effectue à partir du backend. Par conséquent, vous pouvez mettre en cache 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 d'entrée est de bonne qualité:

  • Le repère addressComplete dans l'objet Verdict est true,
  • Le validationGranularity dans l'objet Verdict est PREMISE ou SUB_PREMISE.
  • Aucun des éléments AddressComponent n'est marqué comme :
    • Inferred(Remarque: inferred=truepeut se produire lorsque addressComplete=true)
    • spellCorrected
    • replaced
    • unexpected et
  • confirmationLevel : le niveau de confirmation du 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 refléter cela. Les indicateurs en cache indiquent que l'adresse dans son ensemble est de mauvaise qualité, tandis que les indicateurs plus détaillés tels que "Correcteur orthographique" indiquent le type spécifique de problème de qualité d'adresse. Lors de la prochaine interaction client avec une adresse signalée comme 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 de l'interface utilisateur. Une fois que le client a accepté l'adresse formatée, vous pouvez mettre en cache les éléments suivants à partir de la réponse:

  • formattedAddress
  • postalAddress
  • addressComponent componentNamesou
  • UspsData standardizedAddress

Implémenter une validation d'adresse headless

Sur la base de 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 métier.
  • Cependant, les Conditions d'utilisation de Google Maps Platform limitent les données pouvant être mises en cache.

Dans la section suivante, nous allons aborder un processus en deux étapes visant à vous conformer aux conditions d'utilisation et à implémenter la validation d'adresses à grande échelle.

Étape 1 :

Dans la première étape, nous allons voir comment implémenter un script de validation d'adresses volumineux à partir d'un pipeline de données existant. Ce processus vous permet de stocker des champs spécifiques de la réponse de l'API Address Validation dans le respect des conditions d'utilisation.

Diagramme A:Le schéma suivant montre comment améliorer un pipeline de données 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 à partir de addressComponent:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

Ainsi, au cours de cette étape de l'implémentation, nous mettrons en cache les champs mentionnés ci-dessus avec l'ID utilisateur.

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

Étape 2 :

À l'étape 1, nous avons recueilli des commentaires indiquant que certaines adresses de l'ensemble de données d'entrée peuvent ne pas être de haute qualité. À l'étape suivante, nous prendrons ces adresses signalées et nous les présenterons à l'utilisateur et nous demanderons son consentement pour corriger l'adresse stockée.

Diagramme B: ce diagramme montre comment une intégration de bout en bout du flux de consentement de l'utilisateur pourrait se présenter comme suit:

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 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 confirmer.
  4. Si l'adresse est de bonne qualité, l'API Address Validation renvoie une erreur formattedAddress.
  5. Vous pouvez soit présenter cette adresse à l'utilisateur si des corrections ont été apportées, soit l'accepter silencieusement 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 êtes susceptible de rencontrer dans de nombreuses applications. Ce document tente de montrer certains scénarios et un modèle de conception sur la mise en œuvre d'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 des adresses à volume élevé en tant que bibliothèque Open Source sur GitHub. Consultez-la pour commencer à créer rapidement des adresses à haut volume. Consultez également l'article sur les modèles de conception expliquant comment utiliser la bibliothèque dans différents scénarios.

Étapes suivantes

Téléchargez le livre blanc Améliorer le règlement, la livraison et les opérations avec des adresses fiables et consultez le webinaire Améliorer le règlement, la livraison et les opérations avec la validation d'adresses .

Autres ressources suggérées:

Contributeurs

Cet article est mis à jour par Google. Ce commentaire a été écrit initialement par les contributeurs suivants.
Auteurs principaux:

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