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 sistema. Consulte a Visão geral do fluxo de trabalho em Criar sua lógica de validação para entender o contexto.
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, Washington, Estados Unidos. No entanto, em vez de Kirkland como a cidade, eles entram inadvertidamente em Seattle.
Endereço inserido | Região |
---|---|
Building D, 451 7th Avenue South, Seattle, WA 98033 | EUA |
Veredito para dados substituídos
O exemplo abaixo enfatiza os indicadores importantes da resposta.
{
"inputGranularity": "SUB_PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete": true,
"hasUnconfirmedComponents": true
"hasReplacedComponents": true
}
O PREMISE_PROXIMITY
indica a proximação de um endereço no nível do edifício, mas não é tão detalhado quanto o SUB_PREMISE
, que é a granularidade fornecida na entrada.
A resposta também contém componentes não confirmados e substituídos,
então a combinação os direciona para a 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, como os componentes não foram confirmados, faz sentido garantir que o usuário pretenda inserir um endereço de Seattle e não outro, como Kirkland.
Exemplos de casos extremos: confirmação
Os exemplos a seguir ilustram os seguintes tipos de casos extremos:
- Inferências menores que foram confirmadas. A API Address Validation infere o país, o código postal ou o estado, mas tudo o mais é fornecido e confirmado. A combinação do nível de granularidade e de confirmação resulta em uma inferência menor que não precisa necessariamente de uma ação de confirmação.
- Componente de endereço inesperado NÃO confirmado. Os componentes de endereço não confirmados aumentam o nível de risco do endereço. Isso pode justificar uma confirmação.
- Componente de endereço inesperado que foi 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 menores que foram confirmadas
Quando combinada com dados confirmados de um nível mais granular, a API ainda pode fazer uma inferência correta se a entrada não tiver apenas um componente dos seguintes tipos:
- Cidade
- Estado
- Código postal
- País
Por exemplo, um cliente informa um endereço válido de um restaurante McDonald's em Springfield, Massachusetts, mas esquece de inserir a cidade e fornece um CEP sem a extensão de quatro dígitos.
Endereço inserido | Região |
---|---|
1402 Allen St, MA 01118 EUA | EUA |
Veredito para a cidade ausente
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"addressComplete": true,
"hasInferredComponents": true
}
Em situações em que a API Address Validation infere 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 ocorre porque os componentes inferidos que representam uma ampla região geográfica são facilmente associados 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 nosso exemplo acima, uma verificação em todos os componentes do endereço mostra que todos os componentes são confirmados, o que significa que ele corresponde aos dados armazenados pela API Address Validation e que o serviço também infere dois componentes de nível mais alto.
{
"componentName": {
"text": "Springfield",
"languageCode": "en"
},
"componentType": "locality",
"confirmationLevel": "CONFIRMED",
"inferred": true
},
{
"componentName": {
"text": "1806"
},
"componentType": "postal_code_suffix",
"confirmationLevel": "CONFIRMED",
"inferred": true
}
Componente de endereço inesperado NÃO confirmado
Este 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 vai removê-lo 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 geralmente inserem 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 |
O veredito do componente de endereço inesperado não foi confirmado
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true
}
Além de um veredito 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
}
Componente de endereço inesperado que foi 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, essa não é uma exigência da autoridade postal do Reino Unido e é basicamente ignorada. Consulte postoffice.co.uk e Como endereçar correspondências no Reino Unido e internacionais.
Como resultado, quando um cliente fornece um condado em um endereço do Reino Unido, o serviço avalia isso como uma entrada inesperada.
Endereço inserido | Região |
---|---|
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | Reino Unido |
Veredicto para componente de endereço inesperado que foi confirmado
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
Aqui, address_complete
é avaliado como falso e uma análise do componente de endereço revela uma sinalização inesperada.
{
"componentName": {
"text": "Gloucestershire",
"languageCode": "en"
},
"componentType": "administrative_area_level_2",
"confirmationLevel": "CONFIRMED",
"unexpected": true
}
Embora Gloucestershire seja o condado correto para o endereço inserido, o endereço está formatado incorretamente. Lembre-se de que a API Address Validation também avalia as informações para formatação adequada.