Criar sua lógica de validação

Este documento descreve o processo de criação de um sistema de verificação de endereços para lidar com várias respostas da API Address Validation. Ele aborda como criar sua lógica para usar corretamente a resposta e investigar outros sinais da API e quando e como solicitar mais informações aos clientes.

Em geral, a resposta da API determina as seguintes maneiras pelas quais o seu sistema deve lidar com um endereço:

  • Corrigir: o endereço está de baixa qualidade. Você vai precisar pedir mais informações.
  • Confirme: o endereço é de alta qualidade, mas mudanças do endereço de entrada. Você pode solicitar confirmação.
  • Aceitar: o endereço é de alta qualidade. Você pode aceitar o endereço fornecido.

Finalidade de chave

Este documento ajuda você a modificar seu sistema para melhor analisar a resposta da API e determinar as próximas ações a serem tomadas com os endereços fornecidos. O seguinte o pseudocódigo ilustra um fluxo possível.

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

A lógica exata depende da sua situação. Consulte as orientações para implementação. para mais detalhes. Você também pode usar nossa implementação de código aberto dessa lógica, que está na biblioteca de componentes estendida.

Visão geral do fluxo de trabalho

A tabela abaixo resume duas ações do seu sistema:

  1. O fluxo de trabalho a ser usado com base no comportamento de corrigir, confirmar e aceitar.
  2. Os primeiros indicadores a serem verificados na resposta. Indicadores descritas aqui vêm da propriedade verdict e não são as únicas sinais a serem verificados, mas fornecem um indicador inicial do endereço de qualidade. Cada tipo de comportamento corresponde a uma seção neste documento. descrevendo outros sinais que você também pode precisar investigar.
Comportamento do seu sistema
Corrigir o endereço

A resposta do verdict indica informações importantes ausentes informações que devem ser fornecidas. O endereço retornado pelo A API Address Validation pode não ter qualidade de entrega.

Fluxo de trabalho

  1. Investigue os componentes do endereço, se necessário.
  2. Peça para o cliente corrigir os problemas de endereço.
  3. Solicite a validação do endereço atualizado.
  4. (Opcional) Envie uma solicitação ao endpoint de feedback da API. Consulte Processar endereços atualizados.
  5. Prossiga com o endereço.

Indicadores de veredito

Qualquer uma das seguintes opções se aplica:

Confirme o endereço

A resposta de verdict indica uma entrega mas mudou a entrada original, inferindo dados que tem a ortografia corrigida ou dados que podem ser confirmados.

Fluxo de trabalho

  1. Correções necessárias:
    1. Investigue os componentes do endereço, se necessário.
    2. Solicite a validação do endereço atualizado.
    3. (Opcional) Envie uma solicitação ao endpoint de feedback da API. Consulte Processar endereços atualizados.
    4. Prossiga com o endereço.
  2. Nenhuma correção necessária:
    1. (Opcional) Envie uma solicitação ao endpoint de feedback da API. Consulte Processar endereços atualizados.
    2. Prossiga com o endereço.

Indicadores de veredito

Todas as alternativas a seguir se aplicam:

  • validationGranularity contém ROUTE ou melhor. Consulte granularidade e a distribuição dos valores dos dados.
  • addressComplete é true.
  • O campo hasInferredComponents está true OU O campo hasReplacedComponents é true.
Aceitar o endereço

A resposta da API Address Validation indica um endereço de qualidade excelente.

Fluxo de trabalho

Continue com o endereço devolvido.

Indicadores de veredito

Todas as alternativas a seguir se aplicam:

  • validationGranularity contém PREMISE ou melhor. Consulte valores de granularity.
  • addressComplete é true.
  • Nenhum componente inferido ou substituído.

Diretrizes para implementação

Ao projetar como seu sistema responde aos sinais da API Address Validation, as recomendações a seguir podem ajudá-lo a criar uma resposta mais eficaz um modelo de machine learning. No entanto, estas são apenas recomendações. Lembre-se de que suas precisa estar adequada ao seu modelo de negócios.

Orientação Detalhes
Nível de risco

Considere o nível de tolerância para sua situação ao equilibrar entre pedir para e aceitando o endereço como ele foi inserido.

A API Address Validation retorna vários indicadores que você pode incorporar ao seu nível de risco para otimizar sua validação de desenvolvimento de software.

Por exemplo, se um endereço tiver um número não confirmado, você poderá ainda o aceitem. Por outro lado, se as operações comerciais maior precisão de endereço, você pode solicitar ao usuário. Para um exemplo que podem se enquadrar em qualquer categoria, consulte Número de rua não confirmado nos EUA em Aceitar endereço - exemplos.

Aceitar endereços

É recomendável permitir que o sistema aceite a entrada original quando o cliente não responde aos comandos.

Nesses casos, o cliente pode ter inserido um endereço que não está no do sistema, como para novas construções.

Enviar feedback

Ao emitir novamente uma solicitação de validação de endereço, é possível: também envie uma solicitação para o endpoint provideValidationFeedback.

Isso permite que o Google saiba como você lidou com a resposta final. Consulte Processar endereços atualizados.

Corrigir um endereço

Corrigir um endereço quando os resultados indicarem claramente que ele não está entrega. Seu sistema pode solicitar que o cliente forneça as informações necessárias informações; depois disso, você reemite seu fluxo de trabalho para obter uma entrega endereço IP.

Corrigir indicadores

A API Address Validation fornece vários sinais para informar se um deve ser corrigido.

1. Granularidade de validação e componentes ausentes

Esses dois sinais são a melhor indicação de um endereço com problemas:

  • Sempre que o campo validationGranularity for OTHER, o sistema vai investigar os sinais dos componentes de endereço para saber mais sobre onde o erro e como corrigi-lo.
  • Sempre que o objeto address pós-processado retorna uma missingComponentTypes, o sistema vai verificar esse componente. A falta de componentes também resulta na renderização de endereços incompleto e na entrega.

2. Outros indicadores

A API Address Validation também fornece outros sinais para ajudar diagnosticar problemas específicos:

Componentes suspeitos Quando o tipo enumerado de nível de confirmação de um componente UNCOMFIRMED_AND_SUSPICIOUS, é provável que o componente seja incorreto.
Componente não resolvido Um unresolvedToken é uma parte da entrada não reconhecida como parte válida de um endereço.

3. Indicadores de endereço dos EUA

Alguns campos aplicáveis somente a endereços dos EUA fornecem um sinal útil de que o o endereço IP não é uma entrega e deve ser corrigido. Para um endereço que exige corrigindo o problema, você verá o seguinte:

dpvConfirmation N, D ou vazio.

Para mais detalhes sobre dpvConfirmation, consulte Processar endereços dos Estados Unidos.

Corrigir exemplos de endereços

Confirmar um endereço

Você confirma um endereço quando o veredito indica que a API Address Validation inferiu ou fez alterações em componentes de endereço para produzir uma endereço validado. Nesses casos, você tem um endereço de entrega, mas prefere maior confiança de que o endereço resultante é o pretendido pelo para o cliente.

Para fornecer o comando correto ao cliente, sua lógica identificaria os componentes sinalizados pelo serviço para determinar qual ação ou sinalização a API aplicada ao componente, como inferred, replaced ou spellCorrected. Consulte AddressComponent na referência.

Confirmar indicadores

A API Address Validation fornece vários sinais para informar se um deve ser confirmado.

1. Granularidade de validação

Um validationGranularity de ROUTE ou superior é aceitável, mas PREMISSÃO ou ENVIO fornece um indicador mais forte de entrega.

2. Outros indicadores

Ao decidir confirmar a inserção do endereço com o cliente, o veredito também fornece o seguinte para determinar quais componentes devem ser investigados:

Dados inferidos Quando o campo hasInferredComponents é true, você sabe que a API preencheu informações coletadas de outro endereço componentes de solução.
Dados substituídos Quando o campo hasReplacedComponents é true, a A API substituiu os dados inseridos por dados considerados válidos para tornar o endereço válido.

3. Indicadores de endereço dos EUA

Alguns campos aplicáveis somente a endereços dos EUA indicam que sua lógica deve confirmar os detalhes com o cliente. Uma das seguintes opções se aplica:

dpvConfirmation S

Para mais detalhes sobre dpvConfirmation, consulte Processar endereços dos Estados Unidos.

Resposta do endereço Contém o campo missingComponentType com o valor de subpremise.

Confirmar exemplos de endereço

Aceitar um endereço

Você aceita um endereço quando o veredito fornece um alto grau de confiança de que o endereço é uma entrega e pode ser usado sem mais interação com o cliente no processo downstream.

Aceitar indicadores

A API Address Validation fornece vários sinais para informar se um deve ser confirmado.

1. Granularidade de validação

Um validationGranularity de PREMISE ou mais é aceitável, mas em alguns casos, ROUTE ainda indica um endereço de entrega.

2. Outros indicadores

Um veredito para um endereço de alta qualidade também precisa fornecer o seguinte:

  • Nenhum dado substituído. Nesse caso, hasReplacedComponents: FALSE.
  • Nenhum componente inferido. Nesse caso, hasInferredComponents: FALSE.

3. Indicadores de endereço dos EUA

Alguns campos aplicáveis somente a endereços dos EUA indicam um endereço de alta qualidade que podem ser entregues. Para obter um endereço aceitável nos EUA, você deve ver seguinte:

dpvConfirmation Y

Para mais detalhes sobre dpvConfirmation, consulte Processar endereços dos Estados Unidos.

Aceitar exemplos de endereço