Сквозная аналитика: как связать рекламу, заявки и реальные продажи

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

Коротко о ключевых выводах по сквозной аналитике

Начинайте со схемы данных: один идентификатор визита/клика должен доживать до сделки в CRM.
Без дисциплины UTM и единого справочника источников настройка сквозной аналитики быстро превращается в ручные правки.
Минимальный набор: рекламные расходы + события лидов + статусы/выручка из CRM + звонки (если есть).
Выберите модель атрибуции под цикл сделки и управленческие вопросы, а не "как у всех".
Внедрение сквозной аналитики нужно сопровождать контролями: дедупликация, задержки, расхождения между системами.
Сквозная аналитика для бизнеса окупается, когда решения о бюджете принимаются по валовой/маржинальной прибыли, а не по CPL.

Почему сквозная аналитика жизненно необходима для оценки ROI рекламы

Цель: считать ROI/ROMI не по "лидам", а по реальным продажам и выручке (или марже) с учётом источника, кампании, объявления, ключа.

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

Когда не стоит делать прямо сейчас (коротко):

Нет CRM или в CRM не ведутся статусы/суммы сделок - сначала наладьте учёт продаж.
Слишком малый объём (единичные сделки) и нет возможности корректно размечать трафик - начните с базовой веб-аналитики и UTM-дисциплины.
Нет доступа к рекламным кабинетам/телефонии/сайту - без доступов сквозная аналитика будет неполной и спорной.

Ожидаемый результат: отчёт "расходы → лиды → продажи → выручка/маржа" с возможностью отключать убыточные связки и масштабировать прибыльные.

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

Сбор данных: какие источники подключать и какие метрики фиксировать

Цель: обеспечить полный путь данных от показа/клика до оплаты и возврата, с едиными справочниками и временными зонами.

Что подключать (минимум → расширение)

Реклама: расходы, показы, клики, кампании/группы/объявления, ключевые слова (где применимо).
Сайт/лендинги: сессии, события лидов (отправка формы, клик по телефону/мессенджеру), client_id/cookie, параметры UTM.
Коллтрекинг/телефония: источник звонка, номер подмены, длительность, статус "целевой", запись (если допустимо политикой), идентификатор визита.
CRM: лид/сделка, статусы, ответственный, сумма, дата создания/закрытия, причина отказа, признак оплаты, валюта.
Офлайн (при наличии): касса/1С/эквайринг/маркетплейсы - факт оплаты, возвраты, себестоимость/маржа (если считаете маржинальный ROI).

Какие поля зафиксировать как стандарт (чтобы потом не переделывать)

Идентификаторы: click_id (gclid/yclid и аналоги), client_id, session_id, lead_id, deal_id.
Маркировка: utm_source, utm_medium, utm_campaign, utm_content, utm_term.
Справочники: нормализованные значения "Источник/Канал/Кампания" (единые правила именования).
Время: event_time в одном часовом поясе, плюс дата загрузки (loaded_at) для контроля задержек.
Деньги: расход, выручка, скидки, возвраты; при необходимости - маржа/COGS.

Доступы и инструменты, которые обычно нужны

Доступ к рекламным кабинетам (чтение статистики/расходов).
Доступ к системе аналитики и возможность настроить события/конверсии.
Доступ к CMS/GTМ или к разработчику для передачи идентификаторов в формы.
Доступ к CRM (API/вебхуки/выгрузки), права на поля и статусы.
Доступ к коллтрекингу/телефонии (API/экспорт, настройка подмены номера).

Связывание кликов и лидов: методы трекинга и маркировки трафика

Цель: чтобы каждый лид (форма/звонок/чат) содержал исходный источник, кампанию и идентификаторы клика/сессии, а CRM могла однозначно связать лид со сделкой и оплатой.

Утвердите единый стандарт UTM и именования кампаний.
Заранее закрепите правила, чтобы один и тот же канал не появлялся в отчётах в десяти вариантах. Это снижает ручную "чистку" и ошибки атрибуции.
- Шаблон: utm_source=площадка, utm_medium=тип трафика, utm_campaign=продукт/гео/этап, utm_content=креатив, utm_term=ключ/сегмент.
- Запретите произвольные значения; используйте справочник допустимых вариантов.
Соберите и сохраните идентификаторы клика и визита на сайте.
На входе фиксируйте gclid/yclid и UTM, сохраняйте в cookie/localStorage и прокидывайте в формы. Так вы связываете рекламный клик и будущий лид даже при переходах по страницам.
- Сохраняйте минимум: gclid/yclid, UTM, client_id, landing_page, referrer, first_visit_at.
- TTL хранения выбирайте под цикл сделки; важно, чтобы он не обрывал "длинные" продажи.
Настройте события лидов и контрольные конверсии.
Отслеживайте отправку формы, успешный callback, клик по номеру/мессенджеру, отправку заявки в чат. События должны содержать те же идентификаторы, что и формы.
- Имена событий делайте стабильными: lead_submit, callback_request, chat_start, phone_click.
- Обязательно логируйте ошибки отправки (например, lead_submit_error), иначе будете "терять" лиды без объяснений.
Прокиньте поля трекинга в CRM через формы, API или вебхуки.
В карточке лида/сделки создайте поля для UTM, click_id, client_id и посадочной. Передавайте их при создании лида; при создании сделки - наследуйте из лида.
- Через форму: скрытые поля (без интерактива на странице), которые заполняются скриптом из cookie.
- Через сервер: вебхук "лид создан" → обогащение данными трекинга → запись в CRM.
Соедините звонки с сессией через коллтрекинг.
Включите динамическую подмену номера (DNI), чтобы каждому визиту назначался свой номер/идентификатор. При создании звонка отправляйте в CRM источник, кампанию и идентификатор визита.
- Минимум в CRM: call_id, is_target, call_start_at, utm_*, client_id/session_id.
- Правило: один звонок → одна сущность в журнале коммуникаций, связь с лидом/сделкой - по номеру и идентификатору визита.
Проверьте связку на "сквозном тесте" от клика до оплаты.
Сделайте несколько тестовых прогонов: переход по размеченной ссылке → заявка/звонок → лид в CRM → сделка → статус "оплачено". Сверьте, что в сделке сохранились UTM/click_id и они совпадают с исходным визитом.

Быстрый режим: сокращённый алгоритм за один спринт

Зафиксируйте UTM-стандарт и справочник каналов, запретите "вольные" значения.
Сохраняйте UTM + click_id + client_id на сайте и передавайте их в каждую заявку.
Добавьте в CRM обязательные поля источника и настройте наследование из лида в сделку.
Подключите коллтрекинг с DNI и передачей параметров в CRM.
Прогоните тест "клик → лид → сделка → оплата" и закройте расхождения до запуска отчётов.

Сжатые шаблоны логики (для проверки и внедрения)

Сквозная аналитика: как связать рекламу, заявки и реальные продажи - иллюстрация

Правило нормализации источника: если gclid заполнен - источник = google / cpc; если yclid заполнен - источник = yandex / cpc; иначе - берём utm_source/utm_medium; если пусто - direct / none.
Псевдо-SQL для дедупликации лидов по контакту: оставляйте лид с минимальным created_at в окне и переносите атрибуцию на сделку по этому лид-"первичнику".

Интеграция CRM, телефонии и офлайна: схема передачи и нормализация данных

Цель: обеспечить непрерывную цепочку "канал → лид → сделка → оплата" и единые правила преобразования данных (каналы, статусы, деньги, время).

Базовая схема передачи: реклама/аналитика → (UTM, click_id, client_id) → сайт/коллтрекинг → CRM (лид/контакт/сделка) → источник оплат (касса/1С/эквайринг) → хранилище/BI.

Проверка результата интеграции (чек-лист)

В CRM у лида/сделки есть заполненные utm_* и хотя бы один идентификатор (click_id или client_id).
Статусы CRM однозначно маппятся в стадии воронки (например: "Новый", "В работе", "Успешно/Оплачено", "Проиграно").
Сумма сделки и валюта хранятся в одном формате; есть поле "факт оплаты" или дата оплаты.
Звонки попадают в CRM как события с call_id и привязкой к лиду/сделке.
Повторные заявки одного клиента не "ломают" атрибуцию: есть правило объединения/связи контакта с несколькими сделками.
Офлайн-оплата (если есть) привязывается к сделке по устойчивому ключу (номер заказа/сделки), а не по ФИО.
Часовой пояс синхронизирован между системами; нет "переезда" событий на соседний день.
Есть журнал ошибок интеграции (неуспешные вебхуки/лимиты API) и процедура повторной отправки.

Проверка качества данных: дедупликация, задержки и согласование показателей

Цель: сделать отчёты устойчивыми: чтобы "вчера" в разных системах означало одно и то же, а изменения статусов корректно пересчитывались.

Частые ошибки, из-за которых сквозная аналитика расходится с реальностью

Разные правила источника: в CRM одно, в BI другое (например, по UTM vs по click_id), из-за чего один лид "переезжает" между каналами.
Дубли лидов: один клиент оставил форму и позвонил - считаются два лида без объединения по контакту/сделке.
Склейка по телефону без нормализации: разные форматы номера (+7, 8, пробелы) дают ложные "новые" контакты.
Задержки загрузки расходов: расходы подтягиваются позже лидов, отчёт по ROI на коротких окнах становится "скачущим".
Переотнесение выручки: сделка переоткрыта/перенесена между менеджерами или воронками, а отчёт не учитывает историю изменений.
Неполные поля в заявках: часть форм не передаёт UTM/click_id (новый лендинг, A/B, виджет), и доля "unknown" растёт.
Смешение дат: лид учитывается по дате создания, продажа - по дате оплаты, а в отчёте они "сравниваются" как одно и то же без выбранного правила.
Неучтённые возвраты/отмены: ROI завышается, если не вычитать возвраты или отменённые оплаты.

Таблица: модели атрибуции и какие поля нужны, чтобы они работали

Модель атрибуции	Когда уместна	Что нужно хранить в данных (минимум)	Типовые риски и искажения
Last click (последний платный/последний клик)	Короткий цикл сделки, управление перформансом "здесь и сейчас"	click_id (gclid/yclid), utm_*, timestamp визита, связь lead_id → deal_id	Недооценивает верх воронки и ретаргетинг может "перетягивать" продажи
First click (первый клик)	Оценка каналов привлечения и "открывающих" касаний	first_utm_*, first_click_id, first_visit_at, идентификатор пользователя/контакта	Завышает вклад первого касания, игнорирует дожим и бренд
Linear (линейная по всем касаниям)	Длинный цикл и много касаний, нужен "компромисс" по каналам	Лог касаний (touchpoints) с utm_* и временем, единый user_key	Требует качественного хранения цепочки касаний; "размазывает" вклад
Time-decay (с убыванием по времени)	Когда последние касания важнее, но первые нельзя игнорировать	Лог касаний + timestamps, правило веса по времени, user_key	Чувствительна к неполным логам и задержкам данных
Position-based (U-образная)	Есть выраженные "первое касание" и "лид", между ними - поддержка	first_touch, lead_touch, остальные касания, user_key, lead_created_at	Нужно чётко определить событие "лид" и границы сессий/пользователей

Как автоматизировать отчёты и построить панель принятия решений

Цель: перейти от разовых выгрузок к регулярной панели, где маркетинг и продажи смотрят одни и те же числа и понимают расхождения.

Варианты реализации (что выбрать и когда)

"Лёгкая" сборка на коннекторах + BI. Уместно, если источников немного, логика атрибуции простая, а требуется быстрый запуск. Риск - ограничения коннектора и сложнее контролировать качество.
Хранилище данных (DWH) + витрины + BI. Уместно, если нужны устойчивые правила, история изменений, несколько воронок, офлайн и продвинутая атрибуция. Это самый управляемый вариант для роста.
CRM-ориентированная аналитика (всё вокруг сделок). Уместно, если основная правда - в CRM, и вы готовы жёстко регламентировать заполнение полей менеджерами. Риск - потеря части веб-сигналов и касаний.
Серверный трекинг (server-side) как надстройка. Уместно при ограничениях браузерного трекинга и необходимости повысить полноту данных. Требует аккуратной работы с приватностью и согласиями.

Минимальный состав управленческой панели

Расходы, лиды, продажи, выручка/маржа, ROI по каналу/кампании (и по продукту/гео при необходимости).
Конверсия по этапам воронки: визит → лид → сделка → оплата.
Время до продажи (лаг), чтобы корректно сравнивать периоды.
Доля "unknown/нет источника" как KPI качества данных.

Ответы на типичные практические сомнения

Можно ли сделать сквозную аналитику без CRM?

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

Что важнее в начале: расходы или лиды?

Для запуска - лиды с корректной атрибуцией (UTM/click_id) и последующая связь со сделками. Расходы можно подтянуть следом, но без лидов склейка "расход → результат" невозможна.

Как понять, что настройка сквозной аналитики сделана правильно?

Сделайте тестовый путь "клик → заявка/звонок → лид → сделка → оплата" и убедитесь, что в сделке есть исходные UTM/click_id. Затем проверьте, что отчёт повторяемо собирается за один и тот же период без ручных правок.

Нужно ли внедрение сквозной аналитики, если цикл сделки больше месяца?

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

Почему в отчётах много "прямых заходов" и "не определено"?

Чаще всего это отсутствие UTM на части объявлений/переходов, не сохранённые параметры в cookie или заявки из виджетов без передачи полей. Решение - аудит всех точек входа и обязательные поля трекинга в каждой форме/интеграции.

От чего зависит сквозная аналитика цена в реальном проекте?

От количества источников и глубины интеграций: сайт, несколько рекламных систем, CRM, телефония, офлайн-оплаты, требования к атрибуции и качеству данных. Чем больше "краёв" (офлайн, возвраты, несколько воронок), тем больше работ по нормализации и контролям.