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 de clients 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 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'adresses à fort volume dans différents scénarios, des tests d'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.

Tests

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 de l'API Address Validation, vous souhaitez valider votre base de données d'adresses existante par rapport à la base de données des utilisateurs.

Validation récurrente des adresses

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

• Vous pouvez planifier des tâches 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 et des horaires de livraison.
• Vous pouvez recevoir des vidages de données contenant des adresses de différents services, par exemple du service commercial au service 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 de diverses promotions, puis les mettre à jour dans le système en ligne. Vous souhaitez vérifier que les adresses sont correctes lorsque vous les saisissez dans le système.

Détails techniques

Pour les besoins de ce document, nous partons du principe que:

• Vous appelez l'API Address Validation avec des adresses issues 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é 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.

Mettre en 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 sur 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 la validation d'adresse à fort volume, le stockage 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. Cela garantit que l'utilisateur est bien conscient de la raison pour laquelle un service particulier stocke son adresse et qu'il accepte les conditions de partage de son adresse.

Un exemple de consentement de l'utilisateur est l'interaction directe 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 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 headless, un utilisateur ne peut pas donner son consentement, car la validation de l'adresse se fait côté 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 saisie est de 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=true peut se produire lorsque addressComplete=true)
  • spellCorrected
  • replaced
  • unexpected et
• confirmationLevel : le niveau de confirmation de 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 le refléter. Les indicateurs mis en cache indiquent que l'adresse dans son ensemble est de mauvaise qualité, tandis que les indicateurs plus détaillés tels que "Orthographe corrigée" indiquent le type spécifique de problème de qualité de l'adresse. Lors de la prochaine interaction avec un client pour 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 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 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 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 allons voir comment implémenter un script de validation d'adresses à fort volume à 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 de validation d'adresses conformément aux conditions d'utilisation.

Diagramme A:le diagramme suivant montre comment un pipeline de données peut être amélioré avec une logique de validation d'adresses à fort volume.

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

• confirmationLevel
• inferred
• spellCorrected
• replaced
• unexpected

Par conséquent, lors de cette étape de l'implémentation, nous allons mettre 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 de données.

Étape 2 :

À l'étape 1, nous avons recueilli des commentaires indiquant que certaines adresses du jeu de données d'entrée pourraient ne pas être de haute qualité. À l'étape suivante, nous allons prendre ces adresses signalées et les présenter à l'utilisateur, puis obtenir son autorisation 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:

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 drapeaux sont affichés, vous devez présenter à l'utilisateur une UI pour qu'il corrige et mette à 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 une formattedAddress.
5. Vous pouvez présenter cette adresse à l'utilisateur si des corrections ont été apportées ou l'accepter sans notification s'il n'y a pas de corrections.
6. Une fois que l'utilisateur a accepté, vous pouvez mettre en cache l'formattedAddress dans la base de données.

Conclusion

La validation d'adresses à fort volume est un cas d'utilisation courant que vous êtes susceptible de rencontrer dans de nombreuses applications. Ce document tente de présenter des scénarios et un modèle de conception pour implémenter une telle solution conforme aux conditions d'utilisation de Google Maps Platform.

Nous avons également écrit une implémentation de référence de la validation d'adresses à fort 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 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 d'exploitation avec des adresses fiables et regardez le webinaire Améliorer les processus de paiement, de livraison et d'exploitation avec la validation des adresses .

Lectures complémentaires suggérées:

• Applications de la validation d'adresses à fort volume
• Bibliothèque Python sur GitHub
• Découvrez la démonstration d'Address Validation.

Contributeurs

Google tient à jour cet article. Les contributeurs suivants l'ont initialement rédigé.
Auteurs principaux:

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