Почему заявка не равна продаже — и что теряется без связки
Рекламный канал может давать много заявок и мало денег. Или наоборот — мало заявок, но почти все они закрываются в сделки. Без связки CRM и Метрики эту разницу не видно. Деньги уходят туда, где больше заявок, а не туда, где больше выручки.
Вот типичная ситуация. Компания ведёт трафик из двух источников.
| Канал | Заявок | Продаж | Конверсия лид → продажа | Выручка |
|---|---|---|---|---|
| Поиск | 50 | 3 | 6% | 75 000 ₽ |
| РСЯ | 10 | 8 | 80% | 280 000 ₽ |
Если смотреть только на заявки, поиск выглядит в пять раз эффективнее РСЯ. На самом деле всё ровно наоборот: РСЯ приносит почти в четыре раза больше выручки при гораздо меньшем количестве лидов. Стандартный отчёт Метрики без данных из CRM покажет первую строку и скроет вторую.
Проблема в том, что Метрика видит только то, что происходит на сайте: заполнение формы, нажатие кнопки, переход на страницу «Спасибо». Дальше клиент уходит в CRM — и Метрика о нём больше ничего не знает. Было это нецелевым лидом или закрытой сделкой на 100 000 рублей — снаружи не видно. Именно эту слепоту и ликвидирует механизм офлайн-конверсий.
Важно не путать эту связку с полноценной сквозной аналитикой через сторонние платформы вроде Roistat или Calltouch: в них общая концепция и дополнительные сервисы. Здесь конкретная техническая реализация одной связки: Метрика и CRM напрямую, без посредников.
ClientID: ключ, который связывает Метрику и CRM
Яндекс.Метрика присваивает каждому посетителю уникальный идентификатор — ClientID. Это число записывается в cookie браузера при первом визите и сохраняется там на длительный срок. Когда тот же человек возвращается на сайт, Метрика узнаёт его по этому идентификатору и объединяет все его визиты в единую историю.
ClientID — это связующее звено между рекламным кликом и фактом оплаты. Если в момент отправки формы захватить значение идентификатора и сохранить его в CRM вместе с данными заявки, а потом при закрытии сделки передать этот идентификатор обратно в Метрику — система «сошьёт» рекламный источник и деньги в одну цепочку.
Как захватить ClientID в форму
Самый распространённый способ — скрытое поле в форме заявки. Разработчик добавляет в форму поле типа hidden, а на странице выполняется небольшой JavaScript, который читает значение ClientID из объекта счётчика Метрики и записывает его в это поле. Когда пользователь нажимает «Отправить», значение вместе с именем и телефоном уходит в CRM.
После этого каждая новая заявка в CRM содержит ClientID отправителя. Этот идентификатор нужно хранить в карточке сделки до момента её закрытия: именно он позволит потом передать факт оплаты обратно в Метрику.
Некоторые конструкторы форм и CRM-системы умеют захватывать ClientID без написания кода, через встроенную интеграцию с Метрикой. Это удобнее, но работает только там, где такая возможность предусмотрена платформой.
Если заявки приходят не только через формы
Звонки, мессенджеры, письма на почту — всё это источники заявок, в которых ClientID захватить через форму невозможно. В таком случае можно использовать альтернативный способ идентификации: SHA-256-хэши телефона или email. Метрика принимает хэши контактных данных и пытается сопоставить их с пользователями, авторизованными в сервисах Яндекса.
Хэши работают с меньшим охватом: сопоставление происходит только там, где пользователь залогинен в Яндексе и его данные совпадают с переданными. ClientID точнее и предпочтительнее. Подробнее об инфраструктуре сбора first-party данных — в статье про аналитику без сторонних cookies.
Офлайн-конверсии в Метрике: что это и как работает
Офлайн-конверсии — инструмент Метрики, который позволяет загрузить данные о событиях, произошедших вне сайта: клиент из заявки оплатил счёт, менеджер закрыл сделку, договор подписан. Метрика принимает эти данные, связывает их с конкретными сессиями через ClientID и отображает в отчётах как обычные конверсии — с разбивкой по источникам, кампаниям и объявлениям.
Принципиальное отличие от обычной цели: обычная цель срабатывает в момент действия на сайте (форма отправлена, страница «Спасибо» открыта). Офлайн-конверсия появляется в Метрике позже — когда менеджер закрыл сделку в CRM и данные были переданы в систему.
Что нужно передавать в Метрику
Для каждой офлайн-конверсии нужны несколько ключевых полей:
- ClientID: идентификатор посетителя, захваченный при отправке формы. Без него конверсия не может быть привязана к рекламному источнику.
- Идентификатор цели: ссылка на цель в счётчике Метрики, которой соответствует событие. Цель нужно заранее создать в настройках счётчика.
- Дата и время события: когда произошла сделка. Метрика принимает стандартные форматы даты и времени.
- Ценность конверсии: сумма сделки в рублях. Формально необязательное поле, но именно оно позволяет обучать автостратегию по выручке, а не по количеству конверсий. Без ценности алгоритм не различает, сколько стоила каждая сделка.
Передавать эти данные можно тремя способами — от простого к автоматическому.
Три способа технической реализации
Способ 1: ручная загрузка CSV
Самый доступный вариант — без программирования. Маркетолог или аналитик выгружает из CRM список закрытых сделок за период в виде файла с нужными полями (ClientID, цель, дата, ценность) и загружает его в раздел офлайн-конверсий в интерфейсе Метрики.
Подходит, если нужно проверить гипотезу: сначала настроить захват ClientID, несколько недель собирать данные в CRM, потом загрузить один файл и посмотреть, изменится ли картина в отчётах. Разработчик нужен только для настройки захвата ClientID, всё остальное маркетолог делает сам.
Ограничения. Данные появляются в Метрике только после ручной загрузки, то есть с задержкой. Для автостратегий это важно: чем позже данные о конверсиях попадают в систему, тем хуже обучается алгоритм. Если цикл сделки короткий (один-три дня), загружать данные нужно не реже раза в несколько дней. При длинном цикле (несколько недель) ручная загрузка раз в неделю ещё приемлема: сигналы всё равно успевают дойти до алгоритма.
Способ 2: автоматическая передача через API или вебхуки
При этом способе CRM сама отправляет данные в Метрику в момент изменения статуса сделки — без участия человека. Технически это реализуется через API Метрики: когда сделка переходит в статус «Выиграна», CRM делает автоматический запрос к API с нужными параметрами. Разработчик пишет код один раз; дальше процесс идёт автоматически.
Главное преимущество — данные попадают в Метрику практически в реальном времени. Алгоритм автостратегии получает актуальную информацию и обучается точнее. После первоначальной настройки маркетолог не тратит на это время.
Что потребуется. Разработчик для написания кода интеграции. Если CRM меняется или API Метрики обновляется — интеграцию нужно будет поддерживать. Большинство популярных CRM поддерживают вебхуки (HTTP-запросы при изменении статуса записи). Если в системе есть вебхуки, разработчик сможет использовать их как триггер для отправки данных в API Метрики.
Способ 3: нативная интеграция CRM с Метрикой
Ряд CRM-систем поддерживает встроенную интеграцию с Метрикой, которая настраивается в интерфейсе самой CRM без написания кода. Это наиболее удобный вариант там, где он доступен — нужно лишь указать номер счётчика и выбрать статус сделки, при котором срабатывает конверсия.
| Способ | Сложность | Нужен разработчик | Задержка данных | Подходит для |
|---|---|---|---|---|
| CSV вручную | Низкая | Нет | Дни или недели | Проверки гипотезы, длинный цикл сделки |
| API / вебхуки | Высокая | Да | Минуты | Любые CRM с вебхуками, точная оптимизация |
| Нативная интеграция | Низкая | Нет | Минуты | amoCRM, Битрикс24, RetailCRM и другие |
Нативные интеграции: amoCRM, Битрикс24, RetailCRM
Три наиболее распространённые CRM в российском сегменте рынка предлагают разный уровень встроенной интеграции с Яндекс.Метрикой.
amoCRM
В amoCRM есть интеграция с Яндекс.Метрикой через виджеты и встроенный модуль настроек. После активации интеграции система начинает передавать данные о конверсиях при смене статуса сделки. Базовая настройка доступна без разработчика: нужно указать номер счётчика Метрики и выбрать, при каком статусе воронки считать конверсию закрытой.
Передача ценности конверсии (суммы сделки) также поддерживается, но конкретный способ настройки зависит от версии и конфигурации аккаунта. В ряде случаев может потребоваться использование вебхуков amoCRM или обращение к технической поддержке для уточнения текущих возможностей.
Битрикс24
Битрикс24 поддерживает передачу данных в Яндекс.Метрику через собственный раздел настроек аналитики. При правильной конфигурации система передаёт в Метрику информацию о закрытых сделках, включая ценность конверсии. Битрикс24 также умеет захватывать ClientID через CRM-формы, встроенные в платформу.
Нюанс возникает при нестандартных воронках: если в компании несколько воронок с разными этапами и нужно разделить типы конверсий (например, «первая продажа» и «повторная покупка»), конфигурацию придётся настраивать тщательнее. В таких случаях иногда проще использовать вебхуки Битрикс24 и передавать данные через API Метрики.
RetailCRM
RetailCRM ориентирована на e-commerce и хорошо приспособлена для передачи данных о заказах. Интеграция с Метрикой встроена в модуль аналитики: при смене статуса заказа данные уходят в Метрику автоматически. Передача ценности конверсии поддерживается.
RetailCRM умеет работать с несколькими счётчиками Метрики одновременно — это удобно для магазинов с несколькими сайтами или отдельными посадочными страницами под разные категории товаров.
Если ваша CRM не в этом списке
Большинство других CRM-систем поддерживают вебхуки. Если они есть — разработчик сможет настроить передачу данных в API Метрики (Способ 2). Если CRM не поддерживает ни нативной интеграции, ни вебхуков — остаётся ручная выгрузка CSV. Для длинных циклов продаж (несколько недель от первой заявки до оплаты) это вполне работающий вариант.
Как выглядит результат в Метрике и Директе
После того как офлайн-конверсии начали поступать в Метрику, данные о продажах появляются в отчётах так же, как обычные конверсии, но с важной особенностью: они привязаны к исходному визиту, а не к моменту закрытия сделки. Если человек пришёл с рекламы в понедельник, а оплатил в четверг — конверсия засчитается рекламному источнику понедельника.
В отчётах по источникам трафика
В стандартных отчётах по источникам появится разбивка не только по заявкам, но и по офлайн-конверсиям с ценностью. Теперь виден полный путь: из 50 заявок с поиска получилось 3 продажи на 75 000 рублей, а из 10 заявок с РСЯ — 8 продаж на 280 000 рублей. Обе строки теперь в одном отчёте, а не в двух разных системах.
Важно правильно разделить цели. Для связки CRM нужны как минимум две отдельные цели в Метрике: «Заявка получена» (срабатывает при заполнении формы на сайте) и «Сделка закрыта» (офлайн-конверсия из CRM). Их нельзя смешивать в одну цель — иначе Директ не сможет различить лид и продажу при обучении автостратегии.
Обучение автостратегии по реальной выручке
Главный практический результат — возможность передать в Директ ценность конверсии и обучить автостратегию по реальной выручке, а не по количеству лидов. В терминологии Директа это называется «Целевые действия и их ценность». Алгоритм начинает искать не «больше заявок», а «больше выручки». В примере из первого раздела это означает, что Директ сам начнёт перераспределять бюджет в пользу тех объявлений и аудиторий, которые приводят более ценных клиентов.
Для работы автостратегии нужен устойчивый поток данных: рекомендуется не менее 10 конверсий по оптимизируемой цели в неделю. Это официальная рекомендация Яндекса для обучения алгоритма. Если продаж в неделю меньше — алгоритм не накапливает достаточно данных и работает нестабильно. В таком случае имеет смысл оптимизировать по промежуточной цели с более высокой частотой: например, «Квалифицированный лид» — статус в CRM, присвоенный менеджером после первого разговора с клиентом.
После того как данные начнут поступать системно, их можно агрегировать в наглядном дашборде — по каналам, кампаниям и выручке. Как это сделать через DataLens или Таблицы — в статье про дашборд маркетолога.
Типичные ошибки при настройке связки
ClientID не захвачен в формы
Самая частая ошибка: интеграция с API Метрики настроена, данные из CRM передаются — но в Метрике они ни к чему не привязываются. Офлайн-конверсии без ClientID поступают в систему «вхолостую»: Метрика не может сопоставить их с конкретными сессиями и не знает, какой рекламный канал привёл этого клиента.
Проверить захват ClientID просто: открыть форму заявки, отправить тестовую заявку и найти её в CRM. Если в карточке заявки нет поля с ClientID или оно пустое — захват не настроен. Устраняется задачей разработчику на один-два часа работы.
Данные передаются с большой задержкой
При ручной загрузке CSV, которую делают раз в месяц, алгоритм автостратегии получает устаревшие сигналы. Он может принять решения, которые уже не актуальны: канал был эффективным три недели назад, а за это время всё изменилось. Для коротких циклов продажи данные нужно загружать минимум раз в несколько дней.
Метрика принимает данные об офлайн-конверсиях с определённым ограничением по ретроспективе: слишком старые события система может не принять или не учесть при обучении. Конкретные ограничения стоит проверить в актуальной справке Метрики.
Перепутаны цели: лид и продажа в одном счётчике
Типичная ситуация: маркетолог настраивает одну цель «Обращение» и записывает туда и отправку формы на сайте, и закрытую сделку из CRM. В итоге Директ видит 120 «конверсий» и обучается на смешанном сигнале, где 90% — это заявки, а 10% — реальные продажи с суммой. Алгоритм не понимает разницы и оптимизируется по тому, чего больше, — по заявкам.
Правильно — разделить цели. Одна цель для первичного лида (срабатывает на сайте), другая — для закрытой сделки (приходит из CRM как офлайн-конверсия). Только тогда можно настроить автостратегию конкретно по продажам, а не по заявкам.
ClientID захвачен не во всех формах
На сайте может быть несколько форм захвата: основная на посадочной странице, всплывающий поп-ап, форма в конце статьи, быстрая форма в шапке. ClientID нужно захватывать во всех них. Если хотя бы одна форма работает без захвата, часть заявок в CRM окажется без идентификатора — и офлайн-конверсии по ним передать в Метрику не получится.
Перед запуском связки стоит составить список всех форм на сайте и проверить каждую тестовой отправкой с последующей проверкой карточки в CRM.
С чего начать: план на первые три шага
Если связки не было и нужно выстроить её с нуля, разумная последовательность выглядит так:
- Настроить захват ClientID. Нулевой шаг без которого ничего не заработает. Задача для разработчика: небольшой JavaScript-код и скрытое поле в каждой форме на сайте. После этого каждая новая заявка в CRM будет содержать идентификатор посетителя.
- Создать в Метрике отдельную цель для офлайн-конверсии. Это делается в настройках счётчика. Цель «Сделка закрыта» (или «Оплата получена») должна быть отдельной от цели «Заявка получена». Если передаёте ценность — это тоже настраивается здесь.
- Выбрать способ передачи данных. Если используете amoCRM или Битрикс24 — проверьте нативную интеграцию. Если другая CRM с вебхуками — Способ 2 (API). Если ни того ни другого — начните с ручной загрузки CSV: это позволит проверить концепцию без разработки и понять, изменится ли картина в отчётах.
После того как первые офлайн-конверсии начнут поступать в Метрику, появится возможность принимать решения по рекламе, опираясь не на число заявок, а на реальную выручку от каждого канала. Это фундаментальная смена угла: оптимизируем не стоимость лида, а стоимость продажи.
О том, как читать данные об источниках трафика в ежедневной работе — в статье про семь ежедневных отчётов Яндекс.Метрики. Там же: как работать с отчётом по конверсиям и правильно его читать в связке с данными из рекламного кабинета.