Confirmer l'adresse - exemples

Ce produit ou cette fonctionnalité est en Preview (pré-DG). La prise en charge des fonctionnalités et produits pré-DG peut être limitée, et il se peut que les modifications apportées à ces fonctionnalités ou produits ne soient pas compatibles avec d'autres versions pré-DG. Les offres en pré-DG sont couvertes par les Conditions spécifiques du service Google Maps Platform. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Ce document décrit plusieurs scénarios concrets dans lesquels l'API Address Validation fournit des signaux de réponse pour les adresses qui nécessitent un comportement confirm de votre système. Les exemples présentés ici sont fournis à titre d'illustration, mais ne sont pas exhaustifs. Pour plus de contexte, consultez 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 : 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 Google Building D à Kirkland, WA, États-Unis. Toutefois, au lieu de saisir Kirkland comme ville, il saisit par erreur Seattle.

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

Verdict pour les données remplacées

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

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

Le niveau de précision 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 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 confirm.

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 obtenir 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émonstration en utilisant 451 7th Avenue South, Kirkland, WA 98033 pour voir la réponse à l'adresse initialement prévue.

Action : Confirmez l'adresse saisie avec le client.

Exemples de cas particuliers : confirmer

Les exemples suivants illustrent les types de cas extrêmes suivants :

• Inférences mineures 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 de déduire une information mineure qui ne nécessite pas forcément d'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 nécessiter une confirmation.
• Composant d'adresse inattendu qui EST confirmé. Ce composant n'est pas strictement nécessaire pour une adresse correcte. 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 CONFIRMÉES

Combinée à des données confirmées plus précises, l'API peut toujours faire une inférence correcte si l'entrée ne comporte qu'un seul composant manquant parmi les types suivants :

• Ville
• État
• Code postal
• Pays

Par exemple, un client fournit une adresse postale 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

Verdict pour une 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 pour générer une adresse pouvant être livrée, vous pouvez être plus sûr 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 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 notre exemple ci-dessus, une analyse de tous les composants d'adresse montre que chacun d'eux est confirmé, ce qui signifie qu'il correspond aux données stockées par l'API Address Validation. 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 : Accepter. Les adresses de ce type fournissent une précision suffisante, ainsi qu'une confirmation des composants inférés, pour que votre logique puisse les accepter comme valides sans avoir besoin d'inviter 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 du résultat. Dans ce cas, vous pouvez soit accepter l'adresse, soit la reconfirmer avec le client, en fonction de votre niveau de risque et de confiance.

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

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

Verdict pour un composant d'adresse inattendu non confirmé

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

En plus d'une évaluation 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 : Confirmer. Dans ce cas, la sous-localité, qui peut indiquer un quartier résidentiel ou un quartier, peut être correcte, mais toujours ignorée par l'autorité postale. Toutefois, étant donné que ces informations ne sont **pas** confirmées par l'API Address Validation, il est judicieux 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é britannique dans l'adresse fournie, ce qui est une pratique courante. Toutefois, cela n'est pas obligatoire pour l'autorité postale britannique et est essentiellement ignoré. Consultez postoffice.co.uk et Comment adresser le courrier au Royaume-Uni et à l'étranger.

Par conséquent, lorsqu'un client fournit un comté dans une adresse au Royaume-Uni, le service considère qu'il s'agit d'une entrée inattendue.

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

Verdict 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 :

• Données confirmées comme correctes. Cela indique que le composant correspond au bon comté contenant l'adresse.
• Entrée inattendue Indique un composant qui n'est pas nécessaire à la mise en forme correcte de l'adresse.

Le comté de Gloucestershire est correct pour l'adresse saisie, mais l'adresse elle-même n'est pas au bon format. N'oubliez pas que l'API Address Validation évalue également les informations pour vérifier qu'elles sont correctement mises en forme.

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