Confirmer l'adresse - exemples

Ce document décrit un certain nombre de scénarios réels dans lesquels l'API Address Validation fournit des signaux de réponse pour les adresses qui justifient un comportement de confirmation de la part de votre système. Pour en savoir plus, consultez la section Présentation du workflow dans Créer votre logique de validation.

Remarque :Les exemples ci-dessous sont illustratifs, mais non exhaustifs.

Exemples courants: confirmer

L'exemple suivant illustre le cas des zones métropolitaines avec des noms de rues similaires. Supposons qu'un utilisateur souhaite saisir l'adresse du bâtiment D de Google à Kirkland (Washington, États-Unis). Toutefois, au lieu de saisir Kirkland comme ville, il saisit par inadvertance Seattle.

Adresse saisie	Région
Building D, 451 7th Avenue South, Seattle, WA 98033	États-Unis

Évaluation des données remplacées

L'exemple ci-dessous met en avant les signaux importants de la réponse.

{
  "inputGranularity": "SUB_PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete": true,
  "hasUnconfirmedComponents": true
  "hasReplacedComponents": true
}

PREMISE_PROXIMITY indique une approximation d'une adresse au niveau du bâtiment, mais n'est pas aussi détaillé que SUB_PREMISE, qui est la précision fournie à l'entrée. La réponse contient également des composants non confirmés et remplacés. La combinaison indique donc qu'elle appartient à la catégorie confirm (confirmer).

Une requête sur les composants de l'adresse révèle les problèmes suivants:

{
  "componentName": {
    "text": "451",
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
  "componentName": {
    "text": "98104",
  },
  "componentType": "postal_code",
  "confirmationLevel": "CONFIRMED",
  "replaced": true
}
...
{
  "componentName": {
    "text": "Building D",
    "language_code": "en"
  },
  "componentType": "subpremise",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......

    "unconfirmedComponentTypes": [
      "street_number",
      "subpremise"
    ]

Dans ce cas, l'API de validation des adresses a trouvé une adresse proche de celle fournie à Seattle et a remplacé le code postal, un composant de niveau supérieur, pour obtenir une adresse à Seattle. Il peut s'agir d'un remplacement valide, mais étant donné que les composants n'ont pas été confirmés, il est logique de s'assurer que l'utilisateur a l'intention de saisir une adresse à Seattle et non autre chose, comme Kirkland.

Conseil :Vérifiez l'adresse correcte dans la démonstration, en utilisant 451 7th Avenue South, Kirkland, WA 98033 pour afficher la réponse pour l'adresse initialement prévue.

Action:Vérifiez avec le client que l'adresse est correcte.

Exemples de cas particuliers: confirmation

Les exemples suivants illustrent les types de cas particuliers suivants:

• Inférences mineures qui SONT confirmées L'API Address Validation déduit le pays, le code postal ou l'État, mais tout le reste est fourni et confirmé. La combinaison de la granularité et du niveau de confirmation permet d'obtenir une inférence mineure qui ne nécessite pas nécessairement une action de confirmation.
• Composant d'adresse inattendu NON confirmé Les composants d'adresse non confirmés augmentent le niveau de risque de l'adresse. Cela nécessite peut-être une confirmation.
• Composant d'adresse inattendu qui EST confirmé Le composant n'est pas strictement obligatoire pour une adresse correcte, et l'API Address Validation le supprime de la sortie. Les problèmes de mise en forme ne nécessitent généralement pas de confirmation.

Inférences mineures qui sont confirmées

Lorsqu'elle est combinée à des données confirmées à un niveau plus précis, l'API peut toujours effectuer une inférence correcte si l'entrée ne manque que d'un seul composant des types suivants:

• Ville
• État
• Code postal
• Pays

Par exemple, un client fournit une adresse valide pour un restaurant McDonald's à Springfield (Massachusetts), mais oublie d'indiquer la ville et fournit un code postal sans l'extension à quatre chiffres.

Adresse saisie	Région
1402 Allen St, MA 01118	États-Unis

Évaluation de la ville manquante

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true,
  "hasInferredComponents": true
}

Lorsque l'API Address Validation infère des composants de niveau supérieur pour générer une adresse de livraison, vous pouvez avoir plus confiance dans l'exactitude des données du système. En effet, les composants inférés qui représentent une vaste région géographique sont plus facilement mis en correspondance avec les composants d'adresse confirmés plus précis. Même dans les pays où les noms de villes se répètent, comme Springfield aux États-Unis, les autres composants associés peuvent fournir une adresse unique.

Dans notre exemple ci-dessus, une analyse de tous les composants d'adresse montre que chaque composant est confirmé, ce qui signifie qu'il correspond aux données stockées par l'API Address Validation et que le service infère également deux composants de niveau supérieur.

{
  "componentName": {
    "text": "Springfield",
    "languageCode": "en"
  },
  "componentType": "locality",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
},
{
  "componentName": {
    "text": "1806"
  },
  "componentType": "postal_code_suffix",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
}

Action:acceptez. De telles adresses fournissent une granularité confirmée suffisante, ainsi que la confirmation des composants inférés, de sorte que votre logique puisse les accepter comme valides sans avoir à demander au client.

Composant d'adresse inattendu NON confirmé

Ce scénario illustre l'importance de vérifier quand les composants ne sont pas confirmés. Si un composant d'adresse est inattendu, l'API Address Validation le supprime de la sortie. Dans ce cas, vous pouvez accepter l'adresse ou la reconfirmer auprès du client, en fonction de votre niveau de risque et de votre niveau de confiance.

Par exemple, une adresse peut provenir d'une région où les clients saisissent souvent des informations inoffensives ignorées par les autorités postales. Dans ce cas, vous acceptez l'adresse. Toutefois, dans certains cas, un composant non confirmé peut ne pas être ce que le client souhaite.

Adresse saisie	Région
1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry	France

Évaluation de l'élément d'adresse inattendu non confirmée

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "unconfirmedComponents": true
}

En plus d'un résultat avec des composants non confirmés, l'API Address Validation renvoie l'adresse formatée suivante:

"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",

Une analyse des composants non confirmés montre que l'API a supprimé la caritat 2 de l'adresse renvoyée:

{
  "componentName": {
    "text": "la caritat 2",
    "languageCode": "fr"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

Action:confirmez. Dans ce cas, la sous-localité, qui peut indiquer un quartier résidentiel ou un quartier, peut être correcte, mais elle est toujours ignorée par les autorités postales. Toutefois, étant donné que ces informations ne sont **pas** confirmées par l'API Address Validation, il est logique de les vérifier auprès du client. À ce stade, vous pouvez ignorer la suppression ou la confirmer.

Composant d'adresse inattendu qui EST confirmé

Cet exemple illustre l'inclusion d'un comté du Royaume-Uni dans l'adresse fournie, ce qui est une pratique courante. Toutefois, ce n'est pas une exigence de la poste britannique et cette règle est essentiellement ignorée. Consultez postoffice.co.uk et Comment adresser un courrier au Royaume-Uni et à l'étranger.

Par conséquent, lorsqu'un client fournit un comté dans une adresse au Royaume-Uni, le service l'interprète comme une entrée inattendue.

Adresse saisie	Région
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP	Royaume-Uni

Évaluation du composant d'adresse inattendu qui est confirmé

{
   "inputGranularity": "PREMISE",
   "validationGranularity": "PREMISE",
   "geocodeGranularity": "PREMISE"
}

Ici, address_complete renvoie la valeur "false", et une analyse du composant d'adresse révèle un indicateur inattendu.

{
  "componentName": {
    "text": "Gloucestershire",
    "languageCode": "en"
  },
  "componentType": "administrative_area_level_2",
  "confirmationLevel": "CONFIRMED",
  "unexpected": true
}

Ce composant est à la fois inattendu et confirmé, ce qui signifie ce qui suit :

• Données confirmées comme correctes Cela indique que le comté indiqué dans le composant est le bon.
• Données inattendues en entrée Indique un composant non requis pour la mise en forme correcte de l'adresse.

Bien que le comté Gloucestershire soit le bon pour l'adresse saisie, le format de l'adresse elle-même est incorrect. N'oubliez pas que l'API Address Validation évalue également si les informations sont correctement mises en forme.

Action:Pour ce scénario, l'action recommandée consiste à ignorer ce signal et à accepter l'adresse.