Monitore o uso da sua chave antes de atingir um limite
Acompanhar seus cabeçalhos de cota ao longo do caminho mostra quando um limite está se aproximando, bem antes de uma requisição ser realmente rejeitada.
Uma exportação de CRM costuma ser um arquivo simples de registros de clientes com um campo de endereço e nada mais relacionado à localização: sem coordenadas, sem componentes verificados. Transformar isso em algo que você possa colocar em um mapa ou segmentar por região significa geocodificar a exportação inteira.
Extraia a coluna de endereços da exportação do seu CRM como um array simples, mantendo o ID do cliente alinhado a cada endereço pela posição, já que você precisará relacionar os resultados aos registros depois.
POST /v1/forward
Content-Type: application/json
["1600 Pennsylvania Avenue, Washington", "221B Baker Street, London"]{
"status": "ok",
"results": [
{"formatted": "1600 Pennsylvania Avenue NW, Washington, DC 20500", "lat": 38.8977, "lon": -77.0365, "type": "address", "precision": "house", "confidence": 0.97, "place_id": "def456", "components": {}},
{"formatted": "221B Baker Street, London, UK", "lat": 51.5237, "lon": -0.1585, "type": "address", "precision": "house", "confidence": 0.95, "place_id": "abc123", "components": {}}
]
}Relacione cada resultado ao seu cliente pela posição que você registrou antes de enviar a requisição e, em seguida, grave as coordenadas e os componentes de volta no seu CRM, pela API dele ou por uma importação em massa, dependendo do que o seu CRM suporta. Armazene também os campos confidence e precision, para que qualquer registro com correspondência fraca possa ser sinalizado para limpeza em vez de tratado como verificado.
Um CRM com clientes em vários países se beneficia de passar o parâmetro countries junto com o lote de cada região, restringindo as correspondências candidatas ao país esperado e reduzindo o caso raro em que um nome de rua comum em mais de um país é resolvido para o país errado. Dividir a exportação em lotes por país antes de enviar cada um como sua própria requisição em massa é uma forma razoável de aplicar isso sem mudar mais nada no fluxo de trabalho.
Não remova duplicatas nem reordene o array de endereços antes de enviá-lo sem manter um mapeamento separado de volta aos IDs originais dos clientes. Os resultados voltam na mesma ordem do array que você enviou e, quando essa ordem se desvincula dos seus registros de clientes sem um índice salvo, não há uma forma confiável de relacionar depois um par de coordenadas ao cliente certo. Mantenha o mapeamento de posição para ID na memória ou em uma coluna temporária durante toda a execução do job.
Depois que a exportação inicial for geocodificada, não há necessidade de reprocessar toda a base de clientes novamente mais tarde. Acompanhe quais registros já têm coordenadas e envie ao endpoint, nas execuções seguintes, apenas os registros novos ou com endereço atualizado, mantendo o uso contínuo de requisições proporcional à nova atividade, e não ao total de clientes.
Um registro com pontuação de confiança baixa ou sem vários dos componentes esperados merece ser sinalizado em uma fila de revisão, em vez de gravado silenciosamente junto com os seus registros totalmente verificados. Isso impede que um endereço ruim contamine discretamente um relatório regional ou uma visualização de mapa construída a partir dos dados preenchidos.
Um preenchimento único de um CRM existente custa uma requisição por registro de cliente com endereço, executado como uma única chamada em massa ou em alguns blocos. Um CRM com alguns milhares de clientes pode usar mais do que as 2.500 requisições gratuitas por dia de uma só vez, o que é um bom momento para distribuir o job ao longo de alguns dias ou passar para o crédito pré-pago para um esforço pontual.
Depois que o preenchimento estiver concluído, a geocodificação contínua de novos clientes é pequena e constante, e não um job em massa recorrente. Consulte a documentação de geocodificação direta para ver a estrutura completa de requisição e resposta.