Офлайн-конверсии в Директе: как передать сделки из CRM и научить алгоритм оптимизировать на прибыль

Почему заявка — плохая цель для алгоритма

В большинстве ниш воронка продаж устроена так: клик → заявка → звонок менеджера → квалификация → коммерческое предложение → договор. Директ видит только первые два шага. Всё остальное происходит по телефону, в офисе или в переписке: пиксель Метрики туда не дотягивается.

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

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

Решение: передать в Метрику данные о том, что произошло после заявки. Технически это называется офлайн-конверсия: событие, которое не зафиксировано на сайте, но может быть связано с конкретным кликом в Директе.

Что такое офлайн-конверсия в Метрике

Обычная цель в Метрике срабатывает прямо на сайте: пользователь нажал кнопку «Отправить», открылась страница «Спасибо», пиксель зафиксировал событие. Офлайн-конверсия работает иначе: вы сами загружаете в Метрику запись о том, что произошло за пределами сайта, и система связывает это событие с конкретным кликом по рекламе.

Связующее звено: идентификаторы посетителя, которые нужно сохранить в CRM в момент получения заявки. Без них Метрика не сможет понять, чья это сделка и к какому рекламному клику её приписать.

После загрузки офлайн-конверсия становится обычной целью Метрики: её можно передать в Директ, настроить на неё автостратегию и использовать как основу для обучения алгоритма. Разница только в том, что данные появляются с задержкой (не в реальном времени, а по мере того как менеджеры закрывают сделки в CRM).

Что нужно хранить в CRM: два идентификатора

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

ClientID Метрики

ClientID — уникальный идентификатор браузера пользователя в Яндекс.Метрике. Хранится в cookies, Метрика по нему распознаёт «своего» посетителя и связывает его визиты в единую сессию. Значение выглядит как длинная числовая строка вида 12345678.1234567890.

Как получить ClientID при отправке формы: добавьте скрытое поле в форму на сайте и заполните его через JavaScript с помощью метода ym(XXXXXX, 'getClientID', ...), где XXXXXX — номер вашего счётчика Метрики. При отправке формы значение придёт вместе с остальными полями и его можно сохранить в CRM.

ClientID работает для всех посетителей сайта, независимо от того, пришли они из рекламы или из органического поиска. Это более широкий идентификатор, но он не привязан к конкретному клику в Директе.

yclid — идентификатор клика в Директе

yclid — уникальный параметр, который Яндекс.Директ автоматически добавляет к URL посадочной страницы при каждом клике по рекламному объявлению. Выглядит так: https://сайт.ru/?yclid=1234567890.

yclid позволяет атрибутировать офлайн-конверсию не просто к пользователю, а к конкретному клику: дате, ключевой фразе, объявлению, кампании. Это точнее, чем ClientID, но работает только для пользователей, пришедших через Директ.

Как сохранить yclid: считайте параметр из URL страницы с помощью JavaScript при загрузке формы и передайте его скрытым полем вместе с остальными данными заявки. В CRM создайте отдельное поле «yclid» и заполняйте его автоматически при создании лида.

Какой идентификатор приоритетнее

Если лид пришёл через рекламу в Директе, используйте yclid: он даёт точную привязку к конкретному клику. Если yclid не сохранился (пользователь вернулся позже, очистил cookies, переключился с устройства), Метрика попробует атрибутировать конверсию по ClientID.

Хранить оба идентификатора надёжнее: у Метрики будет больше шансов правильно связать сделку с кликом даже в сложных случаях.

Два способа передать данные в Метрику

Яндекс.Метрика принимает офлайн-конверсии двумя способами: через загрузку CSV-файла вручную в интерфейсе и через API. Выбор зависит от того, как часто у вас закрываются сделки и есть ли техническая возможность настроить автоматическую выгрузку.

Для старта рекомендуем начать с файла: так проще проверить, правильно ли сохраняются идентификаторы, корректно ли Метрика связывает конверсии с кликами, и убедиться, что схема вообще работает, а затем подключать API.

Пошаговая загрузка через файл CSV

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

Формат файла

Файл должен быть в формате CSV (значения через запятую) или TSV (значения через табуляцию), кодировка UTF-8. Обязательные столбцы:

• Идентификатор посетителя. Один из двух: заголовок столбца Client-Id для ClientID Метрики или yclid для идентификатора клика в Директе. Можно передать оба — это повышает точность атрибуции.
• Дата и время конверсии. Заголовок Target, формат даты и времени по ISO 8601: 2026-09-01 14:30:00. Это момент, когда произошло событие: подписание договора, оплата, закрытие сделки в CRM.
• Название цели. Заголовок Target или отдельный столбец с именем цели из Метрики. Название должно точно совпадать с тем, как цель называется в интерфейсе Метрики.

Пример строки в файле:

Client-Id,Target,DateTime
12345678.1234567890,Договор подписан,2026-09-01 14:30:00

Временно́е окно атрибуции

Важный момент: офлайн-конверсия может быть привязана к клику только в том случае, если с момента клика до момента конверсии прошло не больше определённого времени. Это окно атрибуции. После его истечения связать сделку с конкретным кликом технически невозможно.

Для большинства ниш окно в несколько недель покрывает цикл от заявки до договора. При более длинном цикле продаж это нужно учитывать при настройке.

Как загрузить файл в Метрику

1. Откройте нужный счётчик в Яндекс.Метрике.
2. Перейдите в раздел «Настройка» → «Загрузка данных» (или «Офлайн-конверсии» — точное название зависит от версии интерфейса).
3. Нажмите «Загрузить файл» и выберите подготовленный CSV.
4. Метрика проверит формат и покажет, сколько строк прошло валидацию, а сколько содержат ошибки.
5. Подтвердите загрузку. Данные попадут в статистику в течение нескольких часов.

После загрузки зайдите в отчёт «Конверсии» в Метрике и убедитесь, что цель появилась и по ней зафиксированы события. Если строк много, но конверсий в отчёте нет, проверьте идентификаторы: скорее всего, yclid или ClientID в файле не совпадают с теми, что Метрика записала при визите.

Загрузка через API: когда и зачем

API загрузки офлайн-конверсий Метрики позволяет передавать данные автоматически, без ручного скачивания и загрузки файлов. Это актуально, когда сделки закрываются ежедневно: задержка в передаче данных напрямую влияет на скорость обучения алгоритма в Директе.

Технически интеграция выглядит так: CRM-система при смене статуса сделки (например, «Договор подписан» или «Оплата получена») отправляет POST-запрос на API Метрики с данными о конверсии. Для этого нужен OAuth-токен с доступом к счётчику и разработчик, который настроит вызов API на стороне CRM.

Формат данных в API аналогичен формату CSV-файла: те же идентификаторы, название цели, дата и время. Разница только в способе доставки: вместо загрузки файла данные отправляются HTTP-запросом.

Большинство CRM-систем (amoCRM, Битрикс24, Salesforce) поддерживают вебхуки — автоматические триггеры при изменении данных. Они позволяют настроить передачу без написания кода с нуля: вебхук срабатывает при смене статуса сделки и отправляет данные в Метрику.

Как использовать офлайн-конверсию как цель в Директе

После того как офлайн-конверсии появились в Метрике, их нужно подключить к кампании в Директе. Сама по себе загрузка данных ничего не меняет: алгоритм должен знать, что именно эта цель теперь является приоритетной.

Шаг 1. Убедитесь, что Метрика привязана к Директу

Счётчик Метрики должен быть подключён к рекламному кабинету Директа. Это делается в настройках кампании: раздел «Целевые действия», поле «Метрика». Если счётчик уже подключён, проверьте, что офлайн-цель в нём видна.

Шаг 2. Выберите офлайн-цель в настройках стратегии

В настройках автостратегии (например, «Максимум конверсий») в разделе «Целевые действия и их ценность» найдите офлайн-цель по названию: она отображается наравне с обычными целями Метрики. Поставьте её как основную цель оптимизации.

Если у вас несколько офлайн-целей с разной ценностью (например, «Квалифицированный лид» и «Договор подписан»), можно передать все и указать ценность каждой в рублях. Алгоритм сам будет взвешивать, чем выгоднее пожертвовать бюджетом.

Шаг 3. Учтите минимальный объём данных

Для нормальной работы автостратегии нужно не менее 10 конверсий по выбранной цели в неделю. Это общий порог для любых конверсионных стратегий Директа. Если сделок меньше, алгоритм работает на «базе аналогий» без полноценного обучения на ваших данных и точность прогноза снижается.

В этом и состоит основная сложность офлайн-конверсий: заявок на сайте может быть сто в неделю, но реальных сделок только пять. Алгоритм в таком случае не наберёт нужный объём, и стратегия будет работать хуже, чем при оптимизации по более частому событию.

Выход: двухуровневая схема целей. Более частое и менее ценное событие (например, «Лид квалифицирован») даёт алгоритму сигналы для обучения. Более редкое, но прибыльное событие («Договор подписан») передаёт ценность. Директ взвешивает оба и оптимизирует под общую ценность, а не просто под количество.

Когда схема работает, а когда нет

Благоприятные условия

• Короткий цикл продаж. Если от заявки до оплаты проходит несколько дней, сделки попадают в окно атрибуции, алгоритм получает данные быстро и может нормально обучаться.
• Достаточный объём сделок. Минимум 10 закрытых сделок в неделю по целевому событию, или чуть меньше при условии дополнительных промежуточных целей с большей частотой.
• Чёткий критерий «качественного лида». Менеджеры однозначно помечают в CRM, какие сделки закрылись и с какой ценностью. Хаотичные статусы и ручная разметка с ошибками дадут алгоритму плохие данные и обучение пойдёт в неверную сторону.
• Стабильная передача yclid/ClientID. Идентификаторы сохраняются при каждой заявке автоматически. Если треть лидов приходит без идентификатора, атрибуция будет неполной.

Когда схема не помогает

• Длинный цикл продаж — месяцы. В enterprise B2B решение о покупке принимается спустя три-шесть месяцев после первого контакта. Связать сделку с конкретным кликом в Директе технически сложно: окно атрибуции уже закрылось, а кликов за полгода было несколько. Алгоритм получает сигналы с огромной задержкой и не успевает нормально обучаться.
• Мало сделок в нише. Если в месяц закрывается пять сделок и все они на разных людей: данных катастрофически мало. Офлайн-конверсии в такой ситуации есть, но на обучение алгоритма не хватает.
• CRM ведётся непоследовательно. Если часть сделок вносится задним числом, статусы обновляются нерегулярно или yclid не сохраняется в половине случаев, данные будут неполными и алгоритм будет обучаться только на части выборки.
• Нет разделения онлайн- и офлайн-продаж. Если часть покупателей оплачивает сразу на сайте, а часть после переговоров, смешивать обе группы в одной цели не стоит. Лучше настроить отдельные цели для каждого сценария с разными ценностями.

Что делает агентство в этой схеме

Технически настройка офлайн-конверсий — задача на стыке рекламы, веб-разработки и CRM: рекламный специалист не всегда имеет доступ к коду сайта или к CRM-системе, поэтому схема часто требует координации нескольких команд.

Роль агентства в этой схеме: поставить задачу разработчику сайта (добавить yclid и ClientID в форму), объяснить отделу продаж правила заполнения полей в CRM, настроить цель в Метрике и подключить её к стратегии в Директе. Если CRM поддерживает вебхуки, можно помочь настроить автоматическую передачу данных без ручной выгрузки файлов.

Полезно проверять схему через тестовую заявку: заполните форму на сайте, убедитесь, что yclid попал в CRM, загрузите тестовую конверсию в Метрику и посмотрите, появилась ли она в статистике. Это займёт час, но избавит от неприятных открытий через месяц, когда выяснится, что идентификаторы не сохранялись с самого начала.

Связь с автостратегиями: что меняется после подключения

После того как офлайн-конверсии начали поступать в Метрику и вы переключили стратегию на их оптимизацию, нужно заново пройти период обучения. Смена целевого события — это всегда перезапуск алгоритма: он заново строит прогноз, на этот раз основанный на реальных сделках, а не на заявках.

Первые две недели после переключения — режим наблюдения. Объём конверсий в Директе формально упадёт: там, где раньше засчитывалась каждая заявка, теперь засчитывается только закрытая сделка. Это нормально и правильно. Оценивать результат раньше чем через 7–14 дней после смены целей не стоит: алгоритм ещё не набрал данных.

Ещё один важный момент: если вы переходите от оптимизации по заявкам к оптимизации по сделкам, убедитесь, что CPA-ориентир тоже пересмотрен. Сделка стоит дороже заявки, и целевая цена конверсии в стратегии должна это отражать. Если оставить прежнее значение, стратегия будет искать сделки по цене заявки и не сможет выигрывать нужные аукционы. Подробнее о логике автостратегий в Директе — в отдельной статье.

Частые ошибки при настройке

• yclid не сохраняется для повторных визитов. Пользователь кликнул по рекламе, сохранил сайт в закладки, вернулся на следующий день: в этот второй визит yclid в URL уже нет. Нужно сохранить yclid при первом визите (в cookies или localStorage) и прикреплять его ко всем последующим заявкам с того же браузера.
• Дата конверсии в файле совпадает с датой загрузки, а не сделки. Это искажает статистику: Метрика видит, что все сделки произошли в один день, хотя на самом деле они закрывались на протяжении нескольких недель. Используйте реальную дату закрытия сделки из CRM.
• Название цели в файле не совпадает с названием в Метрике. Регистр, пробелы, кириллица — всё должно совпадать до символа: Метрика тогда создаст новую цель вместо того чтобы наполнить существующую.
• Загрузка данных раз в месяц. При таком режиме алгоритм три недели работает без свежих данных о сделках. За это время он успевает «забыть» сигналы и переобучиться на косвенных признаках. Оптимальная частота — раз в неделю или чаще.
• Смешивание качественных и некачественных лидов. Если в CRM всё помечается как «сделка», включая звонки «не то пальто», алгоритм обучается на шуме. Выгружайте только те события, которые реально представляют ценность: квалифицированные лиды, оплаченные счета, подписанные договоры — в зависимости от вашей воронки.