Следите за использованием ключа, пока не упёрлись в лимит
Наблюдение за заголовками квоты по ходу работы показывает приближение к лимиту задолго до того, как запрос будет отклонён.
Экспорт из 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 через её собственный API или через массовый импорт, в зависимости от того, что поддерживает ваша CRM. Сохраняйте также поля confidence и precision, чтобы всё со слабым совпадением можно было пометить для доработки, а не считать проверенным.
CRM с клиентами из нескольких стран выигрывает от передачи параметра countries вместе с пакетом каждого региона: это ограничивает возможные совпадения ожидаемой страной и сокращает редкие случаи, когда название улицы, распространённое в нескольких странах, сопоставляется не с той. Разбить экспорт на пакеты по странам и отправить каждый отдельным пакетным запросом это разумный способ применить это, ничего больше не меняя в рабочем процессе.
Не удаляйте дубликаты и не меняйте порядок в массиве адресов перед отправкой, не сохранив отдельное соответствие исходным идентификаторам клиентов. Результаты возвращаются в том же порядке, что и отправленный массив, и если этот порядок оторван от записей клиентов без сохранённого индекса, надёжно сопоставить пару координат с нужным клиентом потом уже не получится. Храните соответствие позиций и идентификаторов в памяти или во временном столбце на всё время выполнения задания.
После того как первоначальный экспорт геокодирован, нет необходимости позже заново обрабатывать всю клиентскую базу. Отслеживайте, у каких записей уже есть координаты, и при последующих запусках отправляйте в эндпоинт только новые записи или записи с обновлённым адресом, чтобы текущий расход запросов был пропорционален новой активности, а не общему числу клиентов.
Запись с низкой оценкой достоверности или без нескольких ожидаемых компонентов стоит пометить и поставить в очередь на проверку, а не молча записывать рядом с полностью проверенными записями. Так плохой адрес не испортит незаметно региональный отчёт или карту, построенную на основе дозаполненных данных.
Разовое дозаполнение существующей CRM стоит один запрос на каждую запись клиента с адресом и выполняется одним пакетным вызовом или несколькими частями. CRM с несколькими тысячами клиентов может за один раз израсходовать больше, чем 2 500 бесплатных запросов в день, и это подходящий момент либо растянуть задание на пару дней, либо перейти на предоплаченный баланс для разовой обработки.
Когда дозаполнение завершено, текущее геокодирование новых клиентов идёт небольшим и равномерным потоком, а не повторяющимся массовым заданием. Полную структуру запроса и ответа смотрите в документации по прямому геокодированию.