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 pourraient justifier 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 à titre indicatif, mais ne couvrent pas tous les scénarios.

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,
  "possibleNextAction": "CONFIRM"
}

possibleNextAction fournit une indication initiale indiquant qu'il peut être utile de confirmer l'adresse auprès de votre client. Les autres signaux de l'évaluation fournissent plus de détails sur les problèmes potentiels liés à l'adresse. 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 lors de la saisie. La réponse contient également des composants non confirmés et remplacés.

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 voir la réponse pour l'adresse initialement prévue.

Action:Pour cette adresse, vous pouvez demander à l'utilisateur de confirmer si l'adresse renvoyée 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 infère 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 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,
  "possibleNextAction": "CONFIRM"
}

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 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 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: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. Comme toujours, tenez compte de votre niveau de risque pour décider d'inviter ou non votre client avant d'accepter une adresse.

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 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
59 Cherrydown Avenue, Chingford, Londres E4 8DT	Royaume-Uni

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

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

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

"formattedAddress": "59 Cherrydown Avenue, London E4 8DT, UK",

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

{
  "componentName": {
    "text": "Chingford",
    "languageCode": "en"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

Action:Dans ce cas, la sous-localité, qui peut indiquer un quartier ou un lotissement, 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, vous pouvez 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, cette exigence n'est pas imposée par l'autorité postale britannique et 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 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",
   "possibleNextAction": "ACCEPT"
}

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 non obligatoire 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:Dans ce scénario, vous pouvez accepter l'adresse sans autre invite, en fonction de votre niveau de risque.