Corriger l'adresse – Exemples

Ce document décrit plusieurs scénarios réels dans lesquels l'API Address Validation fournit des signaux de réponse qui peuvent justifier un comportement de correction de la part de votre système. Pour en savoir plus, consultez la section Exemples de workflows dans Créer votre logique de validation.

Exemples courants : correction

Cette section décrit des exemples courants dans lesquels l'API Address Validation fournit des signaux de réponse indiquant des informations d'adresse de qualité inférieure.

Ville et code postal manquants

Cet exemple illustre une entrée ne comportant que l'adresse postale, sans ville ni code postal.

Verdict pour la ville et le code postal manquants

L'exemple ci-dessous met en évidence les signaux importants de la réponse.

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true,
  "possibleNextAction": "FIX"
}

possibleNextAction fournit une première indication que l'adresse n'est peut-être pas livrable. Les autres composants mis en évidence sont également compatibles avec cette possibilité. Vous pouvez donc interroger addressComponents pour en savoir plus :

{
  "componentName": {
    "text": "21",
    "languageCode": "en"
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
  "componentName": {
    "text": "45 40th street",
    "languageCode": "en"
  },
  "componentType": "route",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
  "componentName": {
    "text": "United States",
    "languageCode": "en"
  },
  "componentType": "country",
  "confirmationLevel": "CONFIRMED"
}

L'API Address Validation ne renvoie que le pays (États-Unis) en tant que CONFIRMED. Il renvoie tous les autres composants d'adresse sous la forme UNCONFIRMED_BUT_PLAUSIBLE, avec des omissions importantes dans les données, telles que la localité et le code postal.

Numéro de rue manquant

Dans cet exemple, le numéro de rue est manquant.

Verdict pour un numéro de rue manquant

{
    "inputGranularity": "PREMISE_PROXIMITY",
    "validationGranularity": "ROUTE",
    "geocodeGranularity": "ROUTE",
    "possibleNextAction": "FIX"
}

Là encore, possibleNextAction fournit une première indication que l'adresse n'est peut-être pas livrable. De plus, le validationGranularity est ROUTE, ce qui indique une correspondance avec la rue, mais pas assez d'informations pour accéder au bâtiment. De plus, la propriété addressComplete est manquante dans le verdict, qui est donc false. Une autre requête de l'objet address révèle un type de composant manquant :

"missingComponentTypes": [
        "street_number"
      ]

Exemples de cas limites : correction

Dans certains cas, la correction, la confirmation ou l'acceptation d'une adresse dépend de votre scénario d'entreprise particulier. Les exemples ci-dessous illustrent des scénarios qui n'entrent pas strictement dans une catégorie de correction.

Numéro de rue non confirmé

Dans ce scénario, l'API Address Validation ne peut pas confirmer le numéro de rue fourni, mais elle indique que l'adresse est complète.

Verdict pour un numéro de rue non confirmé

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

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete" : true,
  "hasUnconfirmedComponents": true,
  "possibleNextAction": "ACCEPT"
}

Il est intéressant d'étudier la combinaison d'une précision de validation limitée à une approximation au niveau du site avec des composants non confirmés. Une requête de la propriété addressComponents affiche l'élément componentType non confirmé suivant :

{
  "componentName": {
    "text": "84",
    "languageCode": "en"
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
}

Ici, l'confirmation_level de street_number est défini sur UNCONFIRMED_BUT_PLAUSIBLE. Unconfirmed signifie que le service ne trouve pas le numéro de rue 84 dans son ensemble de données, et plausible signifie que les données du composant peuvent toujours être valides.

Sous-bâtiment manquant

Ce scénario décrit une adresse à laquelle il ne manque qu'un sous-bâtiment, comme un numéro d'appartement ou de service. Sinon, l'API Address Validation peut valider entièrement l'adresse. Comme c'est le cas lorsqu'un composant d'adresse est manquant, le addressComplete est false et n'est donc pas présent lors de l'inspection manuelle du verdict.

Par exemple, supposons qu'un client saisisse une adresse valide pour le bureau de l'assesseur de la ville de San Francisco, mais qu'il omette le numéro de bureau.

Verdict pour un sous-bâtiment manquant

Dans cet exemple, le verdict n'affiche pas la propriété addressComplete. Elle est donc false. Vous savez donc qu'au moins un élément d'adresse est inattendu, non résolu ou manquant.

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "hasInferredComponents": true,
  "possibleNextAction": "CONFIRM_ADD_SUBPREMISES"
}

Une requête address révèle les informations suivantes :

"missingComponentTypes": [
        "subpremise"
      ]

Après examen, les données USPS fournissent un code dpvConfirmation de D, qui indique également qu'un sous-bâtiment est manquant.