Confirmar endereço - exemplos

Este produto ou recurso está em pré-lançamento (pré-GA). Os produtos e recursos em pré-GA têm suporte limitado, e é possível que as mudanças neles não sejam compatíveis com versões anteriores. Todos os itens em pré-GA são cobertos pelos Termos de Serviço da Plataforma Google Maps. Para mais detalhes, consulte as descrições da fase de lançamento.

Este documento descreve vários cenários reais em que a API Address Validation fornece indicadores de resposta para endereços que exigem um comportamento de confirmação do seu sistema. Os exemplos aqui são ilustrativos, mas não incluem todas as possibilidades. Consulte Visão geral do fluxo de trabalho em Criar sua lógica de validação para contexto.

Dica: abra a demonstração da Address Validation e valide os endereços de exemplo por conta própria.

Exemplos comuns: confirmar

O exemplo a seguir ilustra o caso de áreas metropolitanas com nomes de ruas semelhantes. Suponha que um usuário queira inserir o endereço do Google Building D em Kirkland, WA, Estados Unidos. No entanto, em vez de Kirkland como a cidade, eles inserem inadvertidamente Seattle.

Endereço inserido	Região
Edifício D, 451 7th Avenue South, Seattle, WA 98033	EUA

Verificação para dados substituídos

O exemplo abaixo enfatiza os indicadores importantes do verdict.

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

O nível de granularidade PREMISE_PROXIMITY indica a aproximação de um endereço no nível do edifício, mas não é tão detalhado quanto SUB_PREMISE, que é a granularidade fornecida na entrada. A resposta também contém componentes não confirmados e substituídos. Portanto, a combinação a coloca na categoria confirmar.

Uma consulta dos componentes de endereço revela as seguintes áreas de preocupação:

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

Nesse caso, a API Address Validation encontrou uma aproximação do endereço fornecido em Seattle e substituiu o CEP, um componente de nível superior, para resolver um endereço de Seattle. Essa pode ser uma substituição válida, mas, junto com o fato de que os componentes não foram confirmados, faz sentido garantir que o usuário pretende inserir um endereço de Seattle e não algo mais, como Kirkland.

Dica: confira o endereço correto na demonstração, usando 451 7th Avenue South, Kirkland, WA 98033 para ver a resposta do endereço originalmente pretendido.

Ação:confirme a entrada do endereço com o cliente.

Exemplos de casos extremos: confirmar

Os exemplos a seguir ilustram os seguintes tipos de casos extremos:

• Inferências secundárias CONFIRMADAS. A API Address Validation deduz o país, o CEP ou o estado, mas todo o resto é fornecido e confirmado. A combinação da granularidade e do nível de confirmação resulta em uma inferência secundária que não precisa necessariamente de uma ação de confirmação.
• Componente de endereço inesperado NÃO confirmado. Componentes de endereço não confirmados aumentam o nível de risco do endereço. Isso pode exigir uma confirmação.
• Componente de endereço inesperado CONFIRMADO. O componente não é estritamente necessário para um endereço adequado, e a API Address Validation o remove da saída. Problemas de formatação geralmente não exigem uma confirmação.

Inferências secundárias CONFIRMADAS

Quando combinada com dados confirmados de um nível mais granular, a API ainda pode fazer uma inferência correta se a entrada estiver faltando apenas um componente dos seguintes tipos:

• Cidade
• Estado
• Código postal
• País

Por exemplo, um cliente informa um endereço de rua válido para um restaurante McDonald's em Springfield, Massachusetts, mas esquece de inserir a cidade e informa um CEP sem a extensão de quatro dígitos.

Endereço inserido	Região
1402 Allen St, MA 01118	EUA

Verificação para cidade ausente

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

Em situações em que a API Address Validation deduz componentes de nível superior para produzir um endereço de entrega, você pode ter um nível maior de confiança de que os dados do sistema estão corretos. Isso acontece porque os componentes inferidos que representam uma região geográfica ampla são mais facilmente correspondidos a componentes de endereço confirmados que são mais granulares. Mesmo em países em que os nomes das cidades são repetidos, como Springfield nos Estados Unidos, os outros componentes combinados podem fornecer um endereço exclusivo.

Usando o exemplo acima, uma verificação em todos os componentes de endereço mostra que cada um deles é confirmado, o que significa que corresponde aos dados armazenados pela API Address Validation e que o serviço também infere dois componentes de nível superior.

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

Ação:aceite. Endereços como esses fornecem granularidade confirmada suficiente, além da confirmação de componentes inferidos, para que sua lógica possa aceitá-los como válidos sem precisar pedir ao cliente.

Componente de endereço inesperado NÃO confirmado

Esse cenário ilustra a importância de verificar quando os componentes não são confirmados. Se um componente de endereço for inesperado, a API Address Validation o removerá da saída. Nesses casos, você pode aceitar o endereço ou reconfirmá-lo com o cliente, dependendo do seu nível de risco e de confiança.

Por exemplo, um endereço pode ser de uma região em que os clientes costumam inserir informações inofensivas ignoradas pela autoridade postal. Nesse caso, você aceitaria o endereço. No entanto, em alguns casos, um componente não confirmado pode não ser o que o cliente quer.

Endereço inserido	Região
1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry	França

Verificação para componente de endereço inesperado não confirmada

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

Além de um veredicto com componentes não confirmados, a API Address Validation retorna o seguinte endereço formatado:

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

Uma verificação de componentes não confirmados mostra que a API removeu la caritat 2 do endereço retornado:

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

Ação:confirme. Nesse caso, a sublocalidade, que pode indicar um distrito residencial ou um bairro, pode estar correta, mas ainda ser ignorada pela autoridade postal. No entanto, como essas informações **não** são confirmadas pela API Address Validation, é recomendável confirmar com o cliente. Nesse momento, você pode ignorar ou confirmar a remoção.

Componente de endereço inesperado CONFIRMADO

Este exemplo ilustra a inclusão de um condado do Reino Unido no endereço fornecido, o que é uma prática comum. No entanto, isso não é uma exigência da autoridade postal do Reino Unido e é essencialmente ignorado. Consulte postoffice.co.uk e Como endereçar correspondências nacionais e internacionais do Reino Unido.

Como resultado, quando um cliente informa um condado em um endereço do Reino Unido, o serviço avalia isso como uma entrada inesperada.

Endereço inserido	Região
Rua Dunalley, 33, Cheltenham, Gloucestershire, GL50 4AP	Reino Unido

Verificação para componente de endereço inesperado CONFIRMADO

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

Aqui, address_complete é avaliado como falso, e uma análise do componente de endereço revela uma flag inesperada.

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

Esse componente é inesperado e confirmado, o que significa o seguinte:

• Confirmado como dados corretos. Isso indica que o componente é o município correto que contém o endereço.
• Inesperado como entrada. Indica um componente não necessário para a formatação correta do endereço.

Embora Gloucestershire seja o condado correto para o endereço inserido, o endereço em si está formatado incorretamente. A API Address Validation também avalia as informações para garantir a formatação adequada.

Ação:nesse cenário, a ação recomendada é ignorar esse indicador e aceitar o endereço.