Руководства

Пакетное геокодирование адресов из выгрузки CRM

Экспорт из CRM обычно представляет собой плоский файл с записями клиентов, в котором есть поле адреса и больше ничего, связанного с местоположением: ни координат, ни проверенных компонентов. Чтобы превратить его в то, что можно показать на карте или сегментировать по регионам, нужно геокодировать весь экспорт.

Подготовка экспорта

Извлеките столбец адресов из экспорта CRM в виде простого массива, сохраняя соответствие идентификатора клиента каждому адресу по позиции, поскольку потом вам нужно будет сопоставить результаты с записями.

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

Запись результатов обратно в CRM

Сопоставьте каждый результат с клиентом по позиции, которую вы отслеживали перед отправкой запроса, затем запишите координаты и компоненты обратно в CRM через её собственный API или через массовый импорт, в зависимости от того, что поддерживает ваша CRM. Сохраняйте также поля confidence и precision, чтобы всё со слабым совпадением можно было пометить для доработки, а не считать проверенным.

Второй пример: международная клиентская база

CRM с клиентами из нескольких стран выигрывает от передачи параметра countries вместе с пакетом каждого региона: это ограничивает возможные совпадения ожидаемой страной и сокращает редкие случаи, когда название улицы, распространённое в нескольких странах, сопоставляется не с той. Разбить экспорт на пакеты по странам и отправить каждый отдельным пакетным запросом это разумный способ применить это, ничего больше не меняя в рабочем процессе.

Распространённая ошибка, которой стоит избегать

Не удаляйте дубликаты и не меняйте порядок в массиве адресов перед отправкой, не сохранив отдельное соответствие исходным идентификаторам клиентов. Результаты возвращаются в том же порядке, что и отправленный массив, и если этот порядок оторван от записей клиентов без сохранённого индекса, надёжно сопоставить пару координат с нужным клиентом потом уже не получится. Храните соответствие позиций и идентификаторов в памяти или во временном столбце на всё время выполнения задания.

Повторный запуск только для новых записей

После того как первоначальный экспорт геокодирован, нет необходимости позже заново обрабатывать всю клиентскую базу. Отслеживайте, у каких записей уже есть координаты, и при последующих запусках отправляйте в эндпоинт только новые записи или записи с обновлённым адресом, чтобы текущий расход запросов был пропорционален новой активности, а не общему числу клиентов.

Обработка плохо распознанных записей

Запись с низкой оценкой достоверности или без нескольких ожидаемых компонентов стоит пометить и поставить в очередь на проверку, а не молча записывать рядом с полностью проверенными записями. Так плохой адрес не испортит незаметно региональный отчёт или карту, построенную на основе дозаполненных данных.

Сколько это стоит

Разовое дозаполнение существующей CRM стоит один запрос на каждую запись клиента с адресом и выполняется одним пакетным вызовом или несколькими частями. CRM с несколькими тысячами клиентов может за один раз израсходовать больше, чем 2 500 бесплатных запросов в день, и это подходящий момент либо растянуть задание на пару дней, либо перейти на предоплаченный баланс для разовой обработки.

Когда дозаполнение завершено, текущее геокодирование новых клиентов идёт небольшим и равномерным потоком, а не повторяющимся массовым заданием. Полную структуру запроса и ответа смотрите в документации по прямому геокодированию.