Conferma indirizzo. Esempi

Questo documento descrive una serie di scenari reali in cui l'API Address Validation fornisce indicatori di risposta per gli indirizzi che potrebbero giustificare un comportamento di conferma da parte del sistema. Per un contesto, consulta Flussi di lavoro di esempio in Crea la logica di convalida.

Esempi comuni: conferma

L'esempio seguente illustra il caso delle aree metropolitane con nomi di vie simili. Supponiamo che un utente intenda inserire l'indirizzo dell'edificio D di Google a Kirkland, WA, Stati Uniti. Tuttavia, anziché Kirkland come città, inseriscono inavvertitamente Seattle.

Verdetto per i dati sostituiti

L'esempio riportato di seguito mette in evidenza gli indicatori importanti della risposta.

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

Il possibleNextAction fornisce un'indicazione iniziale che potrebbe valere la pena confermare l'indirizzo con il cliente. Gli altri indicatori nel verdetto forniscono maggiori dettagli su cosa potrebbe non funzionare con l'indirizzo. Il PREMISE_PROXIMITY indica l'approssimazione di un indirizzo a livello di edificio, ma non è dettagliato come SUB_PREMISE, che è la granularità fornita in input. La risposta contiene anche componenti non confermati e sostituiti.

Una query dei componenti dell'indirizzo rivela le seguenti aree di interesse:

{
  "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"
    ]

In questo caso, l'API Address Validation ha trovato un'approssimazione vicina all'indirizzo fornito a Seattle e ha sostituito il codice postale, un componente di livello superiore, per risolvere l'indirizzo di Seattle. Questo potrebbe essere un sostituto valido, ma insieme al fatto che i componenti non sono stati confermati, è opportuno assicurarsi che l'utente intenda inserire un indirizzo di Seattle e non qualcos'altro, come Kirkland.

Esempi di casi limite: conferma

Gli esempi riportati di seguito illustrano i seguenti tipi di casi limite:

• Inferenze minori che SONO confermate. L'API Address Validation deduce il paese, il codice postale o lo stato, ma tutto il resto viene fornito e confermato. La combinazione di granularità e livello di conferma crea un'inferenza minore che non richiede necessariamente un'azione di conferma.
• Elemento dell'indirizzo imprevisto NON confermato. I componenti dell'indirizzo non confermati aumentano il livello di rischio dell'indirizzo. This might warrant a confirm.
• Elemento dell'indirizzo imprevisto che È confermato. Il componente non è strettamente necessario per un indirizzo corretto e l'API Address Validation lo rimuove dall'output. I problemi di formattazione in genere non richiedono una conferma.

Inferenze minori CONFERMATE

Se combinata con dati confermati di un livello più granulare, l'API può comunque fare un'inferenza corretta se nell'input manca solo un componente dei seguenti tipi:

• Città
• Stato
• Codice postale
• Paese

Ad esempio, un cliente fornisce un indirizzo stradale valido per un ristorante McDonald's a Springfield, Massachusetts, ma dimentica di inserire la città e fornisce un codice postale senza l'estensione di 4 cifre.

Verdetto per la città mancante

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

Nelle situazioni in cui l'API Address Validation deduce i componenti di livello superiore per produrre un indirizzo recapitabile, puoi avere un livello di confidenza più elevato che i dati del sistema siano corretti. Questo perché i componenti dedotti che rappresentano un'ampia regione geografica vengono abbinati più facilmente ai componenti dell'indirizzo confermati che sono più granulari. Anche nei paesi in cui i nomi delle città si ripetono, come Springfield negli Stati Uniti, gli altri componenti combinati possono fornire un indirizzo univoco.

Utilizzando l'esempio precedente, una scansione di tutti i componenti dell'indirizzo mostra che ogni componente è confermato, il che significa che corrisponde ai dati memorizzati dall'API Address Validation e che il servizio deduce anche due componenti di livello superiore.

{
  "componentName": {
    "text": "Springfield",
    "languageCode": "en"
  },
  "componentType": "locality",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
},
{
  "componentName": {
    "text": "1806"
  },
  "componentType": "postal_code_suffix",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
}

Componente dell'indirizzo imprevisto NON confermato

Questo scenario illustra l'importanza di verificare quando i componenti non sono confermati. Se un componente dell'indirizzo è imprevisto, l'API Address Validation lo rimuove dall'output. In questi casi, puoi accettare l'indirizzo o riconfermarlo con il cliente, a seconda del tuo livello di rischio e di confidenza.

Ad esempio, un indirizzo potrebbe provenire da una regione in cui i clienti spesso inseriscono informazioni innocue ignorate dall'autorità postale, nel qual caso accetteresti l'indirizzo. Tuttavia, in alcuni casi un componente non confermato potrebbe non essere quello che il cliente desidera.

Verdetto per il componente dell'indirizzo imprevisto non confermato

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

Oltre a un risultato con componenti non confermati, l'API Address Validation restituisce il seguente indirizzo formattato:

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

Una scansione dei componenti non confermati mostra che l'API ha rimosso Chingford dall'indirizzo restituito:

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

Componente dell'indirizzo imprevisto che È confermato

Questo esempio illustra l'inclusione di una contea del Regno Unito nell'indirizzo fornito, il che è una pratica comune. Tuttavia, questo non è un requisito dell'autorità postale del Regno Unito e viene sostanzialmente ignorato. Consulta postoffice.co.uk e Come indirizzare la posta nel Regno Unito e a livello internazionale.

Di conseguenza, quando un cliente fornisce una contea in un indirizzo del Regno Unito, il servizio la valuta come input imprevisto.

Verdetto per il componente dell'indirizzo imprevisto CONFERMATO

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

In questo caso, address_complete restituisce il valore false e un'analisi del componente dell'indirizzo rivela un flag imprevisto.

{
  "componentName": {
    "text": "Gloucestershire",
    "languageCode": "en"
  },
  "componentType": "administrative_area_level_2",
  "confirmationLevel": "CONFIRMED",
  "unexpected": true
}

Sebbene il Gloucestershire sia la contea corretta per l'indirizzo inserito, l'indirizzo stesso non è formattato correttamente. Ricorda che l'API Address Validation valuta anche le informazioni per la corretta formattazione.