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 de confirmer le comportement de votre système. Pour en savoir plus, consultez la section Présentation du workflow dans Créer votre logique de validation.
Exemples courants: confirmation
L'exemple suivant illustre le cas de zones métropolitaines ayant des noms de rue similaires. Supposons qu'un utilisateur a l'intention de saisir l'adresse du Google Building D à Kirkland, WA, États-Unis. Cependant, au lieu de Kirkland comme ville, ils entrent par inadvertance à Seattle.
| Adresse saisie | Région |
|---|---|
| Building D, 451 7th Avenue South, Seattle, WA 98033 | US |
Verdict des données remplacées
L'exemple ci-dessous met l'accent sur 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 un proximité d'une adresse au niveau du bâtiment, mais n'est pas aussi détaillé que SUB_PREMISE, qui correspond au niveau de précision fourni à l'entrée.
La réponse contient également des composants non confirmés et remplacés. La combinaison indique donc la présence de composants dans la catégorie confirm (confirmer).
Une requête portant sur les composants de l'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 en plus des composants non confirmés, il est logique de s'assurer que l'utilisateur a l'intention de saisir une adresse à Seattle et non une autre adresse, comme Kirkland.
Exemples de cas limites: confirmer
Les exemples suivants illustrent les types de cas limites 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é. En raison de la combinaison de la précision et du niveau de confirmation, une inférence mineure 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 associé à l'adresse. Cela peut justifier une confirmation.
- Composant d'adresse inattendu qui EST confirmé. Ce composant n'est pas strictement nécessaire pour obtenir une adresse correcte. L'API Address Validation le supprime de la sortie. Les problèmes de mise en forme ne justifient généralement pas de confirmation.
Inférences mineures 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 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 | US |
Verdict de la ville manquante
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"addressComplete": true,
"hasInferredComponents": true
}
Dans les cas où l'API Address Validation déduit des composants de niveau supérieur afin de produire une adresse livrable, vous pouvez avoir davantage de certitude que les données du système sont correctes. En effet, les composants déduits qui représentent une région géographique large 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 ville sont répétés, tels que 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
}
Composant d'adresse inattendu NON confirmé
Ce scénario illustre l'importance de vérifier lorsque 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 dans laquelle les clients saisissent souvent des informations inoffensives ignorées par l'autorité postale, auquel cas vous devez accepter 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 |
L'verdict du composant d'adresse inattendu n'est pas confirmé.
{
"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
}
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. Cependant, ce n'est pas une exigence de l'autorité postale britannique et elle est essentiellement ignorée. Consultez postoffice.co.uk et Comment adresser le courrier au Royaume-Uni et à l'international.
Par conséquent, lorsqu'un client indique un comté avec une adresse au Royaume-Uni, le service considère cela comme une entrée inattendue.
| Adresse saisie | Région |
|---|---|
| 33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | Royaume-Uni |
Verdict du composant d'adresse inattendu 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
}
Bien que le comté de Gloucestershire soit correct pour l'adresse saisie, le format de l'adresse elle-même est incorrect. Rappelez-vous que l'API Address Validation évalue les informations pour s'assurer qu'elles sont mises en forme.