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 présentés ici sont illustratifs, mais non exhaustifs.

Exemples courants : confirmer

L'exemple suivant illustre le cas de zones métropolitaines ayant des noms de rue 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 d'un immeuble, 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'il s'agit de 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 en plus des composants non confirmés, il est judicieux de s'assurer que l'utilisateur a l'intention de saisir une adresse à Seattle et non une autre adresse, comme Kirkland.

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

Action:Confirmez la saisie de l'adresse avec le client.

Exemples de cas limites: confirmer

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é Ce 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 s'il manque à l'entrée 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 de validation des adresses infère des composants de niveau supérieur pour générer une adresse de livraison, vous pouvez avoir plus de certitude que les données du système sont correctes. 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 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 que la confirmation des composants déduits, pour que votre logique puisse les accepter comme valides sans qu'il soit nécessaire d'interroger le 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 soit accepter l'adresse, soit la confirmer à nouveau avec le 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 pouvez accepter 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'une évaluation comportant 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 rester 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 l'autorité postale britannique et est essentiellement ignoré. Consultez postoffice.co.uk et Comment adresser le courrier au Royaume-Uni et à l'international.

Par conséquent, lorsqu'un client indique 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 pour un 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. Indique un composant qui n'est pas nécessaire au bon formatage de l'adresse.

Bien que le comté de 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.