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

Objectif

En tant que développeur, vous travaillez souvent avec des jeux 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 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. 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'adresse ponctuelle et récurrente.

Cas d'utilisation

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

Test

Il est fréquent de vouloir tester l'API Address Validation en exécutant des milliers d'adresses. Il se peut que les adresses figurent dans un fichier de valeurs séparées par des virgules et que vous souhaitiez en vérifier la qualité.

Validation unique des adresses

Lors de votre intégration à l'API Address Validation, vous souhaitez valider votre base 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 missions pour valider des adresses pour les détails enregistrés au cours de la journée, par exemple les inscriptions de clients, les détails des commandes ou les calendriers de livraison.
• Vous pouvez recevoir des fichiers de dump 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 de clients (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 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.

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

Mise en 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 après 30 jours.

Lorsque vous utilisez l'API Address Validation, vous avez souvent besoin de 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 via 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 ou tout autre identifiant principal de l'utilisateur.

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 est incorrecte, auquel cas vous lui demanderez une adresse corrigée lors de sa prochaine interaction avec votre application.

• Les 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 l'autorisation de l'utilisateur. Cela permet de s'assurer que l'utilisateur sache bien pourquoi un service particulier stocke son adresse et qu'il accepte les conditions de partage de son adresse.

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

Remarque :Vous pouvez également consulter le guide 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 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 CONFIRMEDouUNCONFIRMED_BUT_PLAUSIBLE.

Si la réponse de l'API ne contient pas les marqueurs ci-dessus, l'adresse d'entrée est probablement de mauvaise qualité. Vous pouvez mettre en cache des indicateurs dans votre base de données pour le refléter. 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 l'orthographe corrigée 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 pourrez appeler l'API Address Validation avec l'adresse existante. L'API Address Validation renvoie l'adresse corrigée que vous pouvez afficher via 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

Remarque :Qu'est-ce que le mode headless ? Logiciel capable de fonctionner sur un appareil sans interface utilisateur graphique (par exemple, un script côté serveur ou exécuté en ligne de commande). Nous utiliserons ce terme pour désigner les cas où le logiciel est utilisé sans IUG.

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 vous présenter 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é.

• Conformément aux conditions d'utilisation , vous pouvez mettre en cache addressComplete, validationGranularity and validationFlags lors de la validation d'adresses sans interface graphique.

• Vous pouvez mettre en cache le addressComplete,validationGranularity and validationFlags, PlaceID pour un UserID spécifique dans la base de données client.

Ainsi, lors 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 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 ne sont peut-être pas 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 enregistrée.

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

1. Lorsque l'utilisateur se connecte, vérifiez d'abord si vous avez mis en cache des indicateurs de validation dans votre système, tels que:

   • addressComplete est vrai
   • validationGranularity n'est pas PREMISE ni SUB_PREMISE.
   • validationFlags étant inferred,spellCorrected,replaced,unexpected.
     • Si aucun indicateur ne s'affiche, cela signifie que l'adresse mise en cache existante est de bonne qualité et qu'elle peut être utilisée.

2. Si des indicateurs sont présents, vous devez présenter à l'utilisateur une interface utilisateur permettant de corriger/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 qu'il la confirme.

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 sans notification s'il n'y a pas de correction.

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é.

Étape 2 de l'implémentation du pseudo-code:

If addressComplete is FALSE

OR

If validationGranularity is Not PREMISE OR SUB_PREMISE

OR

If validationFlags is inferred OR spellCorrected OR replaced OR unexpected
  {

    # This means there are issues with the existing cached address

    Call UI to present the address to user

}
Else{

    # This means existing address is good
  Proceed to checkout
}

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 manière de mettre en œuvre une solution de ce type, 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 à volume élevé en tant que bibliothèque Open Source sur GitHub. Consultez-le pour commencer rapidement à utiliser la validation d'adresses à volume élevé. Consultez également l'article sur les modèles de conception sur la façon d'utiliser la bibliothèque dans différents scénarios.

Étapes suivantes

Téléchargez le livre blanc Améliorer le processus de paiement, de livraison et d'exploitation avec des adresses fiables et consultez le webinaire Améliorer le processus de paiement, de livraison et d'exploitation avec Address Validation .

Autres ressources suggérées:

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

Contributeurs

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

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