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 giustificano un comportamento di conferma da parte del tuo sistema. Per contesto, consulta Panoramica del flusso di lavoro in Creazione di una logica di convalida.

Nota: gli esempi qui riportati sono illustrativi, ma non esaustivi.

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 di Google Edificio D a Kirkland, WA, Stati Uniti. Tuttavia, invece di Kirkland come città, inavvertitamente entrano a Seattle.

Indirizzo inserito	Regione
Building D, 451 7th Avenue South, Seattle, WA 98033	US

Verdetto per la sostituzione dei dati

L'esempio seguente mette in evidenza gli indicatori importanti della risposta.

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

PREMISE_PROXIMITY indica la prossimità di un indirizzo a livello di edificio, ma non è dettagliato come SUB_PREMISE, ovvero la granularità fornita nell'input. La risposta contiene anche i componenti non confermati e sostituiti, quindi la combinazione inserisce questo elemento nella categoria confirm.

Una query sui componenti dell'indirizzo rivela le seguenti aree di preoccupazione:

{
  "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 molto vicina all'indirizzo fornito a Seattle e ha sostituito il codice postale, un componente di livello superiore, per risolversi in un indirizzo di Seattle. Questa potrebbe essere una valida sostituzione, ma oltre al fatto che i componenti non sono stati confermati, ha senso assicurarsi che l'utente intenda inserire un indirizzo di Seattle e non altro, come Kirkland.

Suggerimento: controlla l'indirizzo corretto nella demo utilizzando 451 7th Avenue South, Kirkland, WA 98033 per vedere la risposta relativa all'indirizzo previsto originariamente.

Azione:conferma l'inserimento dell'indirizzo con il cliente.

Esempi di casi limite: conferma

I seguenti esempi 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 è fornito e confermato. La combinazione di granularità e livello di conferma rende un'inferenza minore che non richiede necessariamente un'azione di conferma.
• Componente dell'indirizzo imprevisto NON confermato. I componenti dell'indirizzo non confermati si aggiungono al livello di rischio dell'indirizzo. Ciò potrebbe giustificare una conferma.
• Componente dell'indirizzo imprevisto che è stato confermato. Il componente non è strettamente necessario per un indirizzo corretto e l'API Address Validation lo rimuove dall'output. I problemi di formattazione generalmente non giustificano una conferma.

Inferenze minori che sono confermate

Se combinata con dati confermati di un livello più granulare, l'API può comunque eseguire 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 valido per un ristorante McDonald's a Springfield, nel Massachusetts, ma dimentica di inserire la città e fornisce un codice postale senza l'estensione di quattro cifre.

Indirizzo inserito	Regione
1402 Allen St, MA 01118	US

Verdetto per città scomparsa

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

Nelle situazioni in cui l'API Address Validation deduce componenti di livello superiore per produrre un indirizzo da inviare, puoi avere un maggiore livello di affidabilità che i dati del sistema siano corretti. Questo perché i componenti dedotti che rappresentano un'ampia regione geografica vengono abbinati più facilmente a componenti degli indirizzi confermati più granulari. Anche nei paesi in cui i nomi delle città sono ripetuti, come Springfield negli Stati Uniti, la combinazione degli altri componenti può fornire un indirizzo univoco.

Utilizzando l'esempio precedente, un'analisi di tutti i componenti degli indirizzi mostra che ogni componente è confermato, il che significa che corrisponde ai dati archiviati 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
}

Azione: accetta. Indirizzi come questi forniscono una granularità confermata sufficiente, insieme alla conferma dei componenti dedotti, che la tua logica potrebbe accettarli come validi senza la necessità di chiedere al cliente.

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 che vengono ignorate dall'autorità postale e in questo caso devi accettare l'indirizzo. Tuttavia, in alcuni casi un componente non confermato potrebbe non essere ciò che il cliente vuole.

Indirizzo inserito	Regione
1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry	Francia

Verdetto per componente dell'indirizzo imprevisto non confermato

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

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

"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",

Un'analisi dei componenti non confermati mostra che l'API ha rimosso la caritat 2 dall'indirizzo restituito:

{
  "componentName": {
    "text": "la caritat 2",
    "languageCode": "fr"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

Azione: conferma. In questo caso, la località secondaria, che può indicare un distretto abitativo o un quartiere, potrebbe essere corretta ma comunque ignorata dall'autorità postale. Tuttavia, poiché queste informazioni **non** sono confermate dall'API Address Validation, ha senso confermarla con il cliente. A questo punto, puoi ignorare la rimozione o confermarla.

Componente dell'indirizzo imprevisto che è stato confermato

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

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

Indirizzo inserito	Regione
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP	Regno Unito

Verdetto per componente dell'indirizzo imprevisto che è stato confermato

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

Qui, address_complete restituisce 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
}

Questo componente è imprevisto e confermato, il che significa che:

• I dati confermati come corretti. Indica che il componente è la contea corretta che contiene l'indirizzo.
• Imprevisti come input. Indica un componente non necessario per la corretta formattazione dell'indirizzo.

Il Gloucestershire è la contea corretta per l'indirizzo inserito, ma il formato dell'indirizzo non è corretto. Ricorda che l'API Address Validation anche valuta le informazioni per una formattazione corretta.

Azione:in questo scenario, l'azione consigliata è ignorare questo indicatore e accettare l'indirizzo.