Confirmer l'adresse - exemples

Ce document décrit plusieurs scénarios concrets 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. Les exemples présentés ici sont illustratifs, mais non exhaustifs. Pour plus de contexte, consultez la section Présentation du workflow dans Créer votre logique de validation.

**Conseil** : Ouvrez la démo de l'API Address Validation et essayez de valider vous-même les exemples d'adresses.

Exemples courants : confirmation

L'exemple suivant illustre le cas des zones métropolitaines dont les noms de rues sont similaires. Supposons qu'un utilisateur souhaite saisir l'adresse du Google Building D à Kirkland, dans l'État de Washington, aux États-Unis. Toutefois, au lieu de Kirkland comme ville, il saisit par inadvertance Seattle.

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

Résultat pour les données remplacées

L'exemple ci-dessous met en évidence les signaux importants du résultat.

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

Le PREMISE_PROXIMITY niveau de précision indique la proximité d'une adresse au niveau du bâtiment, mais n'est pas aussi détaillé que SUB_PREMISE, qui est la précision fournie en entrée. La réponse contient également des composants non confirmés et remplacés. La combinaison de ces éléments la fait basculer dans la catégorie confirmation.

Une requête sur les composants d'adresse révèle les points 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 Address Validation a trouvé une approximation proche de l' adresse fournie à Seattle et a remplacé le code postal, un composant de niveau supérieur , pour résoudre une adresse à Seattle. Il peut s'agir d'un remplacement valide, mais compte tenu du fait que les composants n'ont pas été confirmés, il est judicieux de s'assurer que l'utilisateur souhaite saisir une adresse à Seattle et non une autre, comme Kirkland.

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

Action : Confirmez l'adresse saisie auprès du client.

Exemples de cas limites : confirmation

Les exemples suivants illustrent les types de cas limites suivants :

• Inférances 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 du niveau de précision 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 peut justifier une confirmation.
• Composant d'adresse inattendu QUI EST confirmé. Le composant n'est pas strictement requis pour une adresse correcte, et l'API Address Validation le supprime de la sortie. Les problèmes de mise en forme ne justifient généralement pas une confirmation.

Inférences mineures qui SONT confirmées

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

• Ville
• État
• Code postal
• Pays

Par exemple, un client fournit une adresse de rue valide pour un restaurant McDonald's à Springfield, dans le Massachusetts, mais oublie de saisir la ville et fournit un code postal sans l'extension à quatre chiffres.

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

Résultat pour la ville manquante

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

Dans les situations où l'API Address Validation déduit des composants de niveau supérieur afin de produire une adresse livrable, vous pouvez être plus sûr que les données du système sont correctes. En effet, les composants déduits qui représentent une vaste région géographique sont plus facilement mis en correspondance avec des composants d'adresse confirmés plus précis. Même dans les pays où les noms de villes sont répétés, comme Springfield aux États-Unis, les autres composants combinés peuvent fournir une adresse unique.

En reprenant l'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 déduit é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. Les adresses de ce type fournissent une précision confirmée suffisante, ainsi qu'une confirmation des composants déduits, pour que votre logique puisse les accepter comme valides sans avoir à inviter le client à les confirmer.

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 services postaux. Dans ce cas, vous accepterez l'adresse. Toutefois, dans certains cas, un composant non confirmé peut ne pas correspondre à ce que le client souhaite.

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

Résultat pour un composant d'adresse inattendu non confirmé

{
  "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 mise en forme 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 voisinage, peut être correcte, mais toujours ignorée par les services postaux. Toutefois, étant donné que ces informations **ne sont pas** confirmées par l'API Address Validation, il est judicieux de les confirmer auprès du client. À ce stade, vous ignorez la suppression ou vous la confirmez.

Composant d'adresse inattendu QUI EST confirmé

Cet exemple illustre l'inclusion d'un comté britannique dans l'adresse fournie, ce qui est une pratique courante. Toutefois, cela n'est pas une exigence des services postaux britanniques et est essentiellement ignoré. Consultez postoffice.co.uk et How to address UK and international mail.

Par conséquent, lorsqu'un client fournit un comté dans une adresse britannique, le service évalue cela comme une entrée inattendue.

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

Résultat pour un composant d'adresse inattendu qui EST confirmé

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

Ici, address_complete est évalué sur "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 :

• Données confirmées comme correctes. Cela indique que le composant est le comté correct qui contient l'adresse.
• Entrée inattendue. Indique un composant qui n'est pas requis pour une mise en forme correcte de l'adresse.

Bien que le Gloucestershire soit le comté correct pour l'adresse saisie, l'adresse elle-même n'est pas correctement mise en forme. Rappelons que l'API Address Validation évalue également les informations pour une mise en forme correcte.

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