Controla el uso de tu clave antes de alcanzar un límite
Vigilar las cabeceras de cuota sobre la marcha te indica cuándo te acercas a un límite, mucho antes de que se rechace realmente una solicitud.
Una exportación de CRM suele ser un archivo plano de registros de clientes con un campo de dirección y nada más relacionado con la ubicación: sin coordenadas y sin componentes verificados. Convertir eso en algo que puedas mapear o segmentar por regiones significa geocodificar toda la exportación.
Extrae la columna de direcciones de tu exportación de CRM como un array simple, manteniendo el ID de cliente alineado con cada dirección por posición, ya que después tendrás que emparejar los resultados con los registros.
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": {}}
]
}Empareja cada resultado con su cliente según la posición que registraste antes de enviar la solicitud y luego vuelve a escribir las coordenadas y los componentes en tu CRM, ya sea a través de su propia API o de una importación masiva, según lo que admita tu CRM. Guarda también los campos confidence y precision, para que cualquier coincidencia débil pueda marcarse para depurarla en lugar de tratarse como verificada.
Un CRM con clientes en varios países se beneficia de pasar el parámetro countries junto con el lote de cada región, lo que limita las coincidencias candidatas al país esperado y reduce el caso poco frecuente en que un nombre de calle común en más de un país se resuelve en el equivocado. Dividir la exportación en lotes por país antes de enviar cada uno como su propia solicitud masiva es una forma razonable de aplicar esto sin cambiar nada más del flujo de trabajo.
No elimines duplicados ni reordenes el array de direcciones antes de enviarlo sin conservar una correspondencia aparte con los ID de cliente originales. Los resultados vuelven en el mismo orden que el array que enviaste y, una vez que ese orden se desvincula de tus registros de clientes sin un índice guardado, no hay forma fiable de emparejar después un par de coordenadas con el cliente correcto. Mantén la correspondencia entre posición e ID en memoria o en una columna temporal mientras dure el trabajo.
Una vez geocodificada la exportación inicial, no hace falta volver a procesar toda la base de clientes más adelante. Lleva un control de qué registros ya tienen coordenadas y envía por el endpoint solo los registros nuevos o con la dirección actualizada en las ejecuciones siguientes, de modo que el uso continuo de solicitudes sea proporcional a la nueva actividad y no a tu número total de clientes.
Un registro con una puntuación de confianza baja o al que le faltan varios de los componentes esperados merece marcarse en una cola de revisión en lugar de escribirse sin más junto a tus registros totalmente verificados. Así evitas que una dirección errónea contamine sin que nadie lo note un informe regional o una vista de mapa construida con los datos completados.
Completar de una sola vez un CRM existente cuesta una solicitud por cada registro de cliente con dirección, ejecutado como una sola llamada masiva o en unos pocos bloques. Un CRM con unos miles de clientes podría usar más de las 2.500 solicitudes gratuitas al día en una sola sesión, lo que es un buen momento para repartir el trabajo en un par de días o pasar al crédito prepago para ese impulso puntual.
Una vez completado ese relleno inicial, la geocodificación continua de clientes nuevos es pequeña y constante, no un trabajo masivo recurrente. Consulta la documentación de geocodificación directa para ver la estructura completa de solicitud y respuesta.