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

Objectifs

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

L'API Address Validation est un produit de Google Maps Platform qui vous permet de valider une adresse. Cependant, il ne traite qu'une adresse à la fois. Dans ce document, nous allons voir comment utiliser la validation d'adresses à haut volume dans différents scénarios, du test de l'API à la validation d'adresses 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 se trouvent peut-être dans un fichier de valeurs séparées par des virgules et vous souhaitez peut-être valider leur 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 appellent une validation des adresses sur une base récurrente:

  • Vous avez peut-être planifié des tâches pour valider des adresses pour 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 vidages de données contenant des adresses de différents services (par exemple, des ventes au marketing). Le nouveau service recevant les adresses veut souvent les valider avant de les utiliser.
  • Vous pouvez collecter des adresses lors d'enquêtes, ou lors de diverses promotions, puis lors d'une mise à jour dans le système en ligne. Vous souhaitez vérifier que les adresses sont correctes lors de leur saisie dans le système.

Détails techniques

Pour les besoins du présent 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 le client).
  • Vous pouvez mettre en cache les indicateurs de validité associés à 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 individuel 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 avec 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 d'un utilisateur ou à tout autre ID principal.

Pour le cas d'utilisation de High Volume Address Validation, 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 n'est pas valide. Dans ce cas, vous inviterez l'utilisateur à fournir 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. Ainsi, l'utilisateur sait pourquoi un service particulier stocke son adresse et accepte les conditions de partage de son adresse.

Une interaction directe avec un formulaire d'adresse e-commerce sur une page de paiement est un exemple de consentement de l'utilisateur. Il est entendu que vous allez mettre en cache et traiter l'adresse dans le but 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, un 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 sera de qualité livrable:

  • Le repère addressComplete dans l'objet Verdict est true.
  • 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 de AddressComponent est défini sur CONFIRMEDouUNCONFIRMED_BUT_PLAUSIBLE.

Si la réponse de l'API ne contient pas les repères ci-dessus, cela signifie que l'adresse d'entrée était probablement de mauvaise qualité. Pour le refléter, vous pouvez mettre en cache les indicateurs dans votre base de données. 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é 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 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 componentNames ou
  • UspsData standardizedAddress

Implémenter une validation d'adresse sans adresse IP de cluster

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 commerciales.
  • Toutefois, les Conditions d'utilisation de Google Maps Platform limitent les données pouvant être mises en cache.

Dans la section suivante, nous vous expliquerons comment respecter les conditions d'utilisation et mettre en œuvre la validation d'un grand nombre d'adresses en deux étapes.

Étape 1 :

Dans la première étape, nous verrons comment mettre en œuvre un script de validation d'adresses volumineux à 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 tout en respectant les 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 à haut volume.

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 en fonction du User-ID.

Pour en savoir plus, consultez les détails sur la structure réelle de 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 bonne qualité. À l'étape suivante, nous allons récupérer ces adresses signalées, les présenter à 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 parcours 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. S'il y a des indicateurs, vous devez présenter à l'utilisateur une interface utilisateur pour corriger et mettre à jour son adresse.
  3. Vous pouvez appeler à nouveau l'API Address Validation avec l'adresse mise à jour ou mise en cache, puis présenter l'adresse corrigée à l'utilisateur pour qu'il la confirme.
  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 en silence s'il n'y a pas de corrections.
  6. Une fois que l'utilisateur a accepté, vous pouvez mettre en cache formattedAddress dans la base de données.

Conclusion

La validation d'adresses à haut volume est un cas d'utilisation courant que vous êtes susceptible de rencontrer dans de nombreuses applications. Ce document tente de présenter 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 rédigé une implémentation de référence de la validation des adresses en grand volume en tant que bibliothèque Open Source sur GitHub. Consultez-le pour commencer à créer rapidement avec High Volume Address Validation. Consultez également l'article sur les modèles de conception pour l'utilisation de la bibliothèque dans différents scénarios.

Étapes suivantes

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

Documentation complémentaire suggérée:

Contributeurs

Google tient à jour cet article. Ce message a été initialement rédigé par les contributeurs suivants.
Auteurs principaux:

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