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 ne sont pas toujours 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 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 à volume élevé dans différents scénarios, des tests d'API à la validation d'adresses unique 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. Vous disposez peut-être des adresses dans un fichier de valeurs séparées par une virgule et vous souhaitez 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 des utilisateurs.

Validation récurrente des adresses

Il existe plusieurs scénarios qui nécessitent de valider les adresses de manière récurrente :

• Vous avez peut-être planifié des tâches pour valider les adresses des informations collectées au cours de la journée (par exemple, les inscriptions de clients, les détails des commandes ou les plannings de livraison).
• Vous pouvez recevoir des dumps de données contenant des adresses provenant de différents services (ventes, marketing, etc.). 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 lorsque vous les saisissez 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 sur les clients).
• Vous pouvez mettre en cache des 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 individuel se connecte.

Essayer maintenant : accédez à la console Google Cloud et activez l'API Address Validation.

Cache pour une utilisation en production

Remarque : Les éléments de réponse spécifiques décrits dans la section suivante peuvent être stockés pendant 30 jours calendaires consécutifs maximum. Tous ces éléments de réponse DOIVENT être supprimés au bout de 30 jours.

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 l'être par rapport à 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 ou à un autre ID principal de l'utilisateur.

Pour le cas d'utilisation de la validation d'adresses à volume élevé, la mise en cache des données doit respecter les Conditions d'utilisation 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 est peut-être incorrecte. Dans ce cas, vous lui demanderez de 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, ces données ne doivent être mises en cache qu'avec le consentement de l'utilisateur. Cela permet de s'assurer 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.

Par exemple, l'interaction directe d'un utilisateur avec un formulaire d'adresse e-commerce sur une page de paiement constitue un exemple de consentement de l'utilisateur. Vous êtes censé 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 headless, un utilisateur ne peut pas donner son consentement, car la validation de l'adresse s'effectue depuis le backend. Par conséquent, vous ne pouvez mettre en cache que des informations très limitées dans ce scénario sans interface utilisateur.

Comprendre la réponse

Remarque : Il existe également un guide très utile, Créer votre logique de validation, qui explique comment interpréter la réponse.

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

• Le repère addressComplete dans l'objet Verdict est true.
• La valeur validationGranularity dans l'objet Verdict est PREMISE ou SUB_PREMISE.
• Aucun des AddressComponent n'est marqué comme :
  • Inferred(Remarque :: inferred=truepeut se produire lorsqueaddressComplete=true)
  • spellCorrected
  • replaced
  • unexpected et
• confirmationLevel : le niveau de confirmation de AddressComponent est défini surCONFIRMEDouUNCONFIRMED_BUT_PLAUSIBLE

Si la réponse de l'API ne contient pas les marqueurs ci-dessus, il est probable que l'adresse saisie soit de mauvaise qualité. Vous pouvez mettre en cache des indicateurs dans votre base de données pour refléter cela. 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 dont l'adresse a été 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 headless

Remarque : Qu'est-ce que le headless ? Logiciel capable de fonctionner sur un appareil sans interface utilisateur graphique, tel qu'un script exécuté côté serveur ou en ligne de commande. Nous utiliserons ce terme pour décrire le moment où le logiciel est utilisé sans interface utilisateur graphique.

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 allons aborder un processus en deux étapes pour respecter les conditions d'utilisation et implémenter la validation d'adresses à volume élevé.

Étape 1 :

Dans la première étape, nous allons voir 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 de 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é.

Selon les 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 par rapport à l'ID utilisateur.

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

Étape 2 :

À l'étape 1, nous avons recueilli des commentaires indiquant que certaines adresses du jeu de données d'entrée peuvent ne pas être de bonne qualité. À l'étape suivante, nous allons prendre ces adresses signalées et les présenter à l'utilisateur pour obtenir son autorisation de corriger l'adresse enregistrée.

Schéma B : ce schéma montre à quoi pourrait ressembler une intégration de bout en bout du flux 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 indicateurs sont présents, vous devez présenter à l'utilisateur une interface utilisateur 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 silencieusement si aucune correction n'a été effectuée.
6. Une fois que l'utilisateur a accepté, vous pouvez mettre en cache le formattedAddress dans la base de données.

Remarque : Une fois ce workflow terminé, le validationFlags mis en cache doit être supprimé.

Conclusion

La validation d'adresses à volume élevé est un cas d'utilisation courant que vous rencontrerez probablement dans de nombreuses applications. Ce document tente de présenter certains 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 forme de bibliothèque Open Source sur GitHub. Consultez-le pour commencer rapidement à créer des applications avec 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 sur l'amélioration du paiement, de la livraison et des opérations grâce à des adresses fiables et regardez le webinaire sur l'amélioration du paiement, de la livraison et des opérations grâce à la validation des adresses .

Lectures complémentaires suggérées :

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

Contributeurs

Google gère cet article. Les contributeurs suivants en sont les auteurs originaux.
Auteurs principaux :

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