все разделы
Реклама расходует бюджет, сайт принимает визиты, менеджеры обрабатывают обращения, а деньги появляются уже в CRM или платёжной системе. Если эти цифры живут отдельно, компания видит стоимость клика и заявки, но не понимает, какой источник довёл клиента до оплаты. Сквозная аналитика собирает путь расход → визит → обращение → CRM → сделка → оплата → управленческий отчёт. В этой статье разберём, как построить такую связь, встроить в неё Метрику, Директ и Битрикс24, выбрать подходящий инструмент и принять настройку по тестовому маршруту.
Проблема начинается не с отсутствия ещё одного графика, а с разрыва между этапами. Поэтому полезно смотреть на аналитику как на одну историю клиента, а не как на набор отчётов.
Компания запускает рекламную кампанию и фиксирует расход. Пользователь переходит на сайт, веб-аналитика записывает визит и источник, затем человек оставляет форму, звонит или пишет в чат. Обращение попадает в CRM, где ему находят контакт, назначают ответственного и ведут к сделке. После оплаты в цепочку добавляются сумма, дата и финансовый статус. Управленческий отчёт показывает, какой расход привёл к какому результату.
Эта последовательность выглядит так:
рекламный источник → посещение сайта → обращение → CRM → сделка → оплата → выручка → отчёт об эффективности рекламы.
Связь держится на нескольких идентификаторах. UTM передаёт контекст рекламного перехода, ClientID помогает узнать браузерный визит, а ID обращения, сделки и оплаты продолжают путь в CRM и финансовой системе. Один параметр не заменяет остальные: если хотя бы одно звено не передано, связь придётся восстанавливать по журналу обмена. ClientID относится к браузеру, а не к человеку, поэтому после удаления cookie или смены устройства сопоставление может потеряться.
В начале пути находятся данные о визите: реферер, источник, рекламная система, кампания, объявление, UTM, посадочная страница, дата, устройство и доступные действия пользователя. Рядом должны быть расходы: показы, клики, бюджет, комиссии и НДС, если они входят в принятую формулу.
Следующий слой составляют обращения. Это формы, callback, звонки, чаты, сообщения в мессенджерах, лид-формы и обращения с классифайдов. Для каждого нужен понятный идентификатор, чтобы одно событие не стало двумя лидами. В CRM хранятся клиент, контакт, лид, сделка, ответственное лицо, стадия, причина проигрыша, источник и дата создания.
Замыкают контур продажи и финансы: заказ, сумма, валюта, дата оплаты, частичный платёж, отмена, возврат. Выручка показывает сумму продаж по выбранному правилу учёта. Прибыль требует дополнительных данных о себестоимости, комиссиях, логистике и других затратах, поэтому выручку нельзя автоматически называть прибылью.
До настройки зафиксируйте словарь событий. Что считается обращением, квалифицированным лидом, продажей, оплатой и возвратом? Какая система является источником истины и кто меняет статус? Такие договорённости превращают разрозненные поля в рабочую цепочку.
Маркетолог получает возможность сравнивать каналы по квалифицированным лидам, сделкам и выручке, а не только по CPL. Руководитель видит, как бюджет связан с продажами и где отчётность перестаёт быть надёжной. Отдел продаж замечает задержки ответа, провалы на стадиях и повторные обращения.
Это не автоматический механизм оценки сотрудников и не обещание стопроцентной атрибуции. На результат влияют цикл сделки, распределение лидов, качество обработки, неполнота идентификаторов и выбранная модель атрибуции. Практическая ценность появляется там, где цифра помогает принять решение: перераспределить бюджет, исправить форму, сократить время ответа или восстановить передачу оплаты.
Когда цель сформулирована, цепочку можно собрать по порядку. Каждый шаг закрывает одно звено и создаёт условия для следующего, поэтому начинать с красивого дашборда не стоит.
Начните с карты текущего контура: рекламные кабинеты, сайты и лендинги, формы, телефония, чаты, CRM, платёжная или учётная система и будущий отчёт. На ней отметьте поля каждого слоя, направление передачи и ключ, по которому продолжается связь. Здесь же зафиксируйте бизнес-результат: стоимость обращения, квалифицированного лида, сделки, выручку или маржу.
Период отчёта, валюта, часовой пояс и модель атрибуции должны быть частью той же схемы. Расход может относиться к одному месяцу, сделка появиться в другом, а оплата прийти позже. Если описать сущности source, campaign, ad, session, client, lead, deal, payment и их связи до подключения интеграций, пропущенное поле станет заметно ещё до сборки дашборда.
На страницах проверьте счётчик веб-аналитики, мобильные формы, поддомены, редиректы и переходы между доменами. Для рекламных ссылок закрепите единый словарь utm_source, utm_medium, utm_campaign, utm_content, utm_term, общий регистр и одинаковые разделители.
Сохраняйте параметры не только в браузере. Backend должен передать в CRM источник, кампанию, посадочную страницу и доступные идентификаторы вместе с обращением. Проверьте авторизацию, корзину и страницу благодарности: на этих участках метки часто теряются.
Для Яндекс Метрики можно использовать ClientID: получить его через getClientID, записать в скрытое поле и отправить в CRM. Это анонимный идентификатор браузера, а не универсальный ID клиента. После удаления cookie, смены браузера или устройства сопоставление может исчезнуть. Такую границу нужно учитывать в отчёте, а не пытаться заменить её предположением.
Теперь каждый канал должен иметь понятный маршрут. Форма создаёт лид или сделку по утверждённому правилу, звонок передаёт ID вызова, чат связывается с контактом, а обращение с классифайда получает ID объявления или диалога, если этот идентификатор доступен. Исходное обращение не удаляйте после создания сделки.
В карточке храните UTM, посадочную страницу, ClientID, ID звонка или чата, источник, кампанию и время. Определите ключ повторного обращения и правила дедупликации. Статусы «новый», «квалифицирован», «выиграна», «проиграна» и «возврат» должны иметь один смысл для маркетинга, продаж и отчёта. Сделка, созданная в CRM, ещё не означает полученные деньги.
Если продажа проходит в другой системе, передайте ID заказа, сумму, дату оплаты, валюту и финансовый статус. Тогда связь продолжится от карточки клиента к фактическому результату, а не остановится на обещании менеджера.
Заявки являются промежуточным сигналом. Расходы загружаются с учётом периода, валюты, комиссий и НДС по правилам компании. Продажи передаются по статусу, сумме и дате оплаты; частичные платежи, отмены и возвраты должны быть отдельными состояниями или событиями.
В отчёте разделите стоимость обращения, квалифицированного лида, сделки и выручку. Если нужна прибыль, добавьте себестоимость и другие затраты либо явно укажите способ их расчёта. Показатель ROI или ROMI, рассчитанный по выручке, не становится показателем прибыли только из-за названия.
Приёмка должна воспроизводить путь от расхода до отчёта. Создайте уникальную тестовую ссылку с UTM-метками, откройте её и убедитесь, что визит получил нужный источник. Затем отправьте форму и выполните тестовый звонок, если телефония входит в контур.
После этого проверьте, что CRM создала одну сущность без дубля, сохранила UTM, посадочную страницу, ClientID, дату, время и ID обращения. Переведите запись через согласованные стадии, зафиксируйте тестовую оплату или имитацию финансового результата и сравните отчёт с заранее записанными контрольными значениями.
Завершите приёмку тремя пограничными сценариями: повторная форма, отмена или возврат и обращение без UTM. Если запись пропала, сопоставьте журнал передачи, карточку CRM и отчёт. Так обнаруживается конкретное звено сбоя, а не просто расхождение на дашборде.
Метрика и Директ закрывают верхнюю часть уже собранного контура: визит, рекламное касание и расход. Чтобы эти данные дошли до денег, следующий ключ должен сохраниться в CRM, где обращение превращается в сделку и получает финансовый статус.
Метрика определяет источники по рефереру и рекламным меткам, фиксирует посещения, цели и события. Ошибка в UTM, потерянный редирект или самореферал меняют распределение трафика, поэтому счётчика на странице недостаточно.
Для последующего сопоставления используют ClientID, телефон и email. ClientID можно получить через getClientID и передать в CRM, но он относится к браузеру и не объединяет одного человека на всех устройствах. Цели проверяйте на тестовом визите, сопоставляя источник в Метрике, параметры формы и запись CRM. Подробнее о целях и событиях рассказано в материале «Цели в Яндекс Метрике».
Для Директа рабочая цепочка начинается с расхода кампании и продолжается кликом, лидом, CRM-заказом, оплатой, доходом и отчётом. В зависимости от способа передачи используются ClientID, UserID, yclid или данные CRM. Набор обязательных полей и частота обновления зависят от конкретной интеграции, поэтому любую сделку из любой CRM нельзя обещать передать автоматически.
Оценка по оплате полезнее фиксированной цены заявки, если компания действительно передаёт финансовый результат и связывает его с рекламным касанием. Показатели Директа и Метрики могут расходиться из-за периода, целей, часового пояса и модели атрибуции. Для офлайн-конверсий Яндекс устанавливает специальные сроки атрибуции и обновления; их указывают вместе со способом передачи, а не выдают за универсальное окно.
В этой архитектуре Битрикс24 чаще всего хранит рабочую середину пути: обращения, контакты, сделки, стадии и результаты менеджеров. Рекламные и финансовые системы остаются источниками отдельных данных, которые нужно согласованно передать в CRM.
Схема выглядит так: источник или UTM → форма, звонок, чат или другой канал → лид, контакт или сделка → стадии → результат и сумма. При корректной метке источник может записаться в CRM-сущность. Для ручных сделок действует отдельная логика окна атрибуции, заданная настройками портала. Её нельзя смешивать с правилами Метрики или Директа.
Звонок становится частью цепочки только при работающей телефонии или коллтрекинге, номере, операторе, ID вызова и правилах определения источника. Сам Битрикс24 не превращает каждый входящий звонок в доказанную рекламную конверсию. В отчёте также учитывайте дату среза: расход, создание сделки и оплата могут попасть в разные периоды.
Начните с проверки типа портала, тарифа, доступности приложений, рекламного кабинета и телефонии. Облачная и коробочная конфигурации, лимиты и состав интеграций различаются и могут меняться, поэтому актуальные возможности нужно сверять для конкретного портала.
Далее согласуйте UTM-словарь, подключите источники и сайт, настройте CRM-формы, телефонию, открытые линии и чаты. Проверьте связи лида, контакта и сделки, окно атрибуции, ручные расходы, успешные и проигранные статусы, суммы и даты оплат. Завершите тестовым путём от источника до отчёта, сравнив карточку CRM, журнал передачи и итоговые данные. О внедрении можно узнать на странице «Внедрение CRM Битрикс24».
После схемы важен вопрос ответственности: где хранится связь между касаниями и кто отвечает за финансовый результат. Один и тот же набор инструментов может работать по-разному в зависимости от этого решения.
CRM как центр подходит, если обращений немного, продажи ведутся в одной системе, а финансовые поля заполняются регулярно. Готовый облачный сервис удобен при множестве каналов, звонков и рекламных кабинетов, но наличие интеграции ещё не означает передачу оплат и возвратов.
Связка веб-аналитики, CRM, телефонии и коннектора даёт гибкость, однако добавляет точки отказа, задержки и зависимость от API. Хранилище данных и BI оправданы при нескольких сайтах или CRM, сложных правилах выручки и длинной истории. Это не обязательный первый шаг: сначала нужно согласовать модель данных, ключи и владельцев полей.
Базовый контур включает веб-аналитику, рекламные кабинеты, CRM, телефонию и коллтрекинг, сервис сквозной аналитики, коннекторы или API. В зависимости от бизнеса добавляются платёжная система, ERP, CDP, call-центр, классифайд, хранилище и BI.
Веб-аналитика отвечает за визиты и источники, рекламный кабинет за расходы, CRM за обращения и сделки, телефония за звонки, финансовая система за оплаты и возвраты. Сервис соединяет эти сведения по правилам, но не восстанавливает непереданное поле. Поэтому в проекте нужна таблица источников истины, ключей связи, частоты обмена и правил повторной доставки.
Выбирайте не по числу функций, а по самому слабому звену цепочки. Проверьте количество сайтов и рекламных каналов, используемую CRM, долю звонков и чатов, длину цикла сделки, повторные продажи и офлайн-оплату. Уточните, нужна ли детализация до кампании, объявления или ключевой фразы, а также доступ к API, сырым данным и собственным BI-дашбордам.
В смете учитывайте тариф, внедрение, маппинг, поддержку и контроль качества. На демонстрации попросите показать тестовый маршрут с исходными идентификаторами, сделкой, оплатой и возвратом. Если виден только сводный график, полноценно принять связку нельзя.
Сервисы ниже удобнее сравнивать по участку, который требуется усилить: общая мультиканальность, звонки, длинная воронка недвижимости, телефония или компактный мультитрекинг. Это не рейтинг: решающим остаётся собственный тест от источника до оплаты.
Roistat объединяет рекламные расходы, источники, обращения, заказы и CRM-данные. Такой сценарий подходит компаниям с несколькими каналами, если нужные сущности и финансовые поля действительно передаются. Ссылка партнёрская, актуальные условия проверяйте при регистрации.
Колтач (Calltouch) имеет смысл рассматривать, если слабое звено контура – телефонные обращения. Подмена номеров, ID вызова и передача звонка в CRM определяют, продолжится ли путь от рекламного источника до сделки. Ссылка реферальная; подходы к коллтрекингу можно сопоставить в отдельном обзоре сервисов, а условия подключения и срок хранения проверить перед внедрением.
Смартис (Smartis) ориентирован на недвижимость и длинную воронку, где важны связь лида со сделкой, этапы работы с объектом и когортный анализ. Здесь указана официальная страница, потому что подтверждённой реферальной ссылки KeyClient нет. До старта нужно проверить поддержку конкретной CRM, классифайдов, статусов и финансовых полей.
UIS и Mango Office закрывают задачи телефонии, коллтрекинга и передачи обращений в CRM. Ссылки партнёрские. Сравнивайте ID звонка, пропущенные обращения, поля CRM, API и условия подключения, а не только наличие рекламного кабинета.
Callibri (Колибри) связывает обращения сайта с рекламой и CRM, поддерживает мультитрекинг и работу с лидами. Здесь также указана официальная страница: подтверждённой реферальной ссылки KeyClient нет. При выборе важны тип интеграции, состав полей и задержка обновления. Финансовый результат появится только после передачи сделок и оплат.
Когда стандартного отчёта не хватает, тот же маршрут можно вынести в отдельные сценарии. Принцип остаётся прежним: сначала фиксируется источник, затем обращение или заказ, после чего подтверждается оплата.
BI нужен при нескольких сайтах, CRM и рекламных кабинетах, разных правилах выручки, длинной истории и отдельных дашбордах для руководителя, маркетинга и продаж. До загрузки данных в хранилище согласуйте сущности, ключи, валюту, часовой пояс, статусы, атрибуцию и возвраты. BI расширяет отчётность, но не исправляет неверную UTM-разметку, дубли и потерянные оплаты.
В GetCourse путь может выглядеть так: рекламный источник и UTM → регистрация → источник заказа → заказ → платёж → полученная сумма → отчёт по выручке. Первый источник пользователя и источник конкретного заказа лучше хранить отдельно: регистрация после органики не означает, что последующая покупка не связана с рекламой.
GetCourse предоставляет API и механизмы обмена событиями, но схема зависит от аккаунта, тарифа и способа интеграции. До запуска проверьте поля UTM, ID пользователя и заказа, частичную оплату, отмену, возврат, повторный заказ, дату и валюту. Полную нативную аналитику нельзя обещать без проверки обмена.
Для Авито связка начинается с аккаунта и объявления, продолжается чатом, звонком или другой доступной сущностью и заканчивается CRM-сделкой и подтверждённой оплатой. В зависимости от официального API, CRM-коннектора или телефонии могут быть доступны ID объявления, диалога, сообщения и вызова.
Разделяйте источники «Avito chat», «Avito call» и «Avito form», храните объявление, ответственного и статус квалификации. Сообщение или звонок являются обращением, а не продажей. Авито не следует называть штатным источником расходов Битрикс24: набор данных зависит от аккаунта и тарифа, поэтому используйте официальные API и поддерживаемые коннекторы, а не scraping.
Все решения выше можно проверить на одной контрольной сборке. Это учебный сценарий, а не кейс KeyClient.
Главная блога
Интернет-маркетинг
Отдел продаж
ТОП сервисы.svg)
Новости
ClientID.ClientID.В результате видны расход, стоимость обращения, сделка и выручка 120 000 ₽. Это расчёт по выручке, а не по прибыли, поскольку себестоимость не передавалась. Для контрольной приёмки добавьте дубль формы, обращение без UTM и возврат. Так пример проверяет всю цепочку, а не только наличие записи в дашборде.
Перед запуском проведите короткий preflight. В CRM должны быть единые стадии, причины проигрыша и обязательные поля; сумма, дата оплаты, частичные платежи и возвраты не должны зависеть от памяти менеджера. UTM-словарь должен сохраняться на редиректах и между доменами, а для каждого перехода между формой, обращением, сделкой и платежом нужен понятный ключ связи.
Назначьте владельца контроля и срок реакции на сбой. В итоговом отчёте должны быть видны модель атрибуции, период, задержка и доля обращений без источника. Пустой источник нельзя превращать в органику, а отсутствующую оплату – в нулевую прибыль.
Первый практический шаг прост: провести аудит текущей цепочки расход → визит → обращение → CRM → сделка → оплата и отметить, на каком переходе теряется поле или меняется смысл статуса. После этого настройку можно принимать тем же тестовым маршрутом и улучшать по конкретным разрывам.
27.08.2026
25
22 мин
00000
