Сквозная аналитика простыми словами

Зачем смотреть дальше лида

На сайте видно, откуда пришёл человек и что он сделал. В CRM — кто взял обращение, как двигалась сделка и чем всё закончилось. В учётной системе — пришли ли деньги, был ли возврат и что осталось после затрат.

Сквозная аналитика связывает эти кусочки в одну историю. Для связи используются общие идентификаторы, а для расчётов — заранее согласованные правила. Тогда рекламный расход можно сравнить не с отправленной формой, а со сделкой, оплатой и прибылью.

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

Какие решения станут проще

Начинать лучше не с графиков, а с решения. Какой вопрос сейчас мешает распределить бюджет, найти утечку или проверить работу продаж? Например:

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

Пять точек от рекламы до денег

1Рекламарасход, источник, кампания → 2Лидформа, звонок, чат, идентификатор → 3Сделкаэтап, ответственный, причина отказа → 4Оплатафакт денег, возврат, дата → 5Прибыльсогласованный состав доходов и затрат

Чтобы эта цепочка не держалась на догадках, ей нужны связующие ключи. UTM-метки и рекламные идентификаторы показывают источник. Идентификатор посетителя или клика сохраняется в момент обращения и уходит в CRM. У сделки есть свой стабильный ID, а платёж ссылается на заказ или сделку.

В документации Яндекс Метрики для связи офлайн-конверсии с визитом используются `ClientId`, `UserId`, `Yclid` или `PurchaseId`. Термины технические, смысл простой: на каждом шаге должен оставаться след, по которому можно пройти назад.

Главный тест цепочки.

Возьмите одну реальную сделку и вручную пройдите назад: от оплаты к записи в CRM, затем к обращению и источнику. Если на каком-то шаге остаётся только догадка, система пока не сквозная на этом участке.

Минимум данных для первого ответа

Источник	Что забираем	Что проверяем до интеграции
Рекламные кабинеты	Расходы, кампании, объявления, клики	Единый нейминг, валюта, часовой пояс, НДС и история изменений
Сайт и веб-аналитика	Источник визита, метки, ClientID/UserID, события	Сохраняется ли идентификатор до отправки формы и не теряется ли после редиректа
Телефония и чаты	Обращение, источник, время, результат контакта	Передаётся ли идентификатор в CRM и как учитываются повторные обращения
CRM	Лид, сделка, этапы, ответственный, причина отказа	Обязательность полей, стабильность этапов, дубли и история изменений
Оплаты и учёт	Оплата, возврат, товар или услуга, себестоимость	Какой ID связывает платёж со сделкой и что считается фактом оплаты
Справочники	Канал, продукт, регион, менеджер, календарь	Кто владелец справочника и как обрабатываются переименования

Не тащите в первую версию всё, что можно выгрузить. Соберите короткую цепочку под один дорогой вопрос — например, какие кампании приводят оплаченные сделки.

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

Где дешёвый лид становится дорогим

Представим компанию с длинной B2B-сделкой. Кампания А даёт больше заявок и более низкую цену лида, чем кампания Б. Кажется, бюджет пора переносить в А.

Но CRM продолжает историю. В заявках из А чаще нет подходящей задачи, встречаются дубли, а до коммерческого предложения доходит мало обращений. Из Б заявок меньше, зато они чаще проходят квалификацию.

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

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

Подробнее о ловушке дешёвого лида — в материале «Реклама есть. Где прибыль?».

Лид может быть дешёвым в рекламном кабинете и дорогим для бизнеса. Цена становится понятной только после сделки и оплаты.

Если совсем просто: что именно делает сквозная аналитика

Она отвечает на вопрос: какие рекламные расходы в итоге превратились в оплаченные продажи и деньги для бизнеса. Не только сколько было кликов или заявок, а что случилось с человеком дальше.

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

Если часть пути не связалась, отчёт должен честно показать «источник неизвестен». Это не поломка красоты, а полезный сигнал о качестве данных.

Пример с числами: почему дешёвый лид не всегда выгоднее

Условно канал А потратил 200 000 рублей и дал 400 заявок. Канал Б потратил 180 000 и дал 180 заявок.

CPL канала А — 200 000 ÷ 400 = 500 рублей. У Б — 180 000 ÷ 180 = 1 000 рублей. По стоимости заявки А выглядит вдвое лучше.

Теперь добавим CRM. Из А квалификацию прошли 80 обращений, из Б — 72. Стоимость квалифицированной заявки стала 2 500 и 2 500 рублей. Разница исчезла.

До оплаты дошли 20 клиентов А и 30 клиентов Б. Стоимость оплаченного клиента: 10 000 рублей у А и 6 000 у Б.

Средняя маржа одной продажи А — 15 000 рублей, Б — 12 000. Общая маржа: 20 × 15 000 = 300 000 у А и 30 × 12 000 = 360 000 у Б.

После рекламного расхода осталось 100 000 рублей у А и 180 000 у Б. Канал с более дорогим лидом дал бизнесу на 80 000 рублей больше результата. Это не универсальный вывод про «дорогие лиды». Это объяснение, зачем проходить всю цепочку.

Как я собираю первый рабочий контур

Вместе с собственником выбираем одно решение: например, куда перенести бюджет.
Фиксируем, что считаем заявкой, новым клиентом, оплатой и маржой.
Берём один зрелый период и один-два канала.
Связываем расходы, обращения, сделки, оплаты и возвраты.
Несколько цепочек проходим вручную от банковской операции назад до рекламы.
Показываем непривязанные данные и причины разрывов.
Только после сверки автоматизируем обновление и расширяем контур.

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

Так сквозная аналитика становится не ещё одним экраном, а общей картой решений. Следующее действие: возьмите одну недавнюю оплату и попробуйте за десять минут пройти назад до кампании. Место, где закончились точные ответы, и будет первой задачей.

Где заканчивается дашборд и начинается сквозность

Подход	На что отвечает	Чего недостаточно без связки
Веб-аналитика	Как люди пришли и что делали на сайте или в приложении	Не всегда видит работу менеджера, оплату, возврат и себестоимость
CRM-отчёты	Как обращения превращаются в сделки и кто с ними работает	Без источника и расхода сложно оценить экономику привлечения
Дашборд	Как удобно показать выбранные показатели	Красивый экран не создаёт отсутствующие связи и правила
Сквозная аналитика	Как источник связан с последующими событиями и финансовым результатом	Требует устойчивых идентификаторов, качества процессов и согласованных определений

Microsoft называет дашборд Power BI одностраничным холстом с визуализациями. Проще говоря, это экран, на котором удобно смотреть показатели.

Но красивый экран не склеит то, что не связалось в данных. Сквозность появляется раньше: в идентификаторах, правилах связи, модели данных и проверке качества.

Семь разрывов, которые портят выводы

Начать с инструмента. Новый сервис не ответит на вопрос, который бизнес ещё не сформулировал.
Склеивать по телефону или email как получится. Форматы меняются, контакты дублируются, один человек может обращаться несколько раз. Нужны правила нормализации и стабильные ID.
Считать созданную сделку продажей. Воронка должна различать обращение, квалификацию, договор, отгрузку, оплату и возврат — в той детализации, которая соответствует бизнесу.
Смешивать выручку, деньги и прибыль. Эти показатели отвечают на разные вопросы. До расчёта нужно письменно определить состав доходов, затрат, налогов, возвратов и период признания.
Не показывать непривязанные записи. Доля данных без источника — не мусор, который удобно скрыть, а показатель качества системы.
Менять правила задним числом без версии. После изменения этапов CRM или классификации каналов старые и новые периоды могут стать несопоставимыми.
Автоматизировать до ручной сверки. Если одна сделка не проходит путь вручную, автоматическая загрузка лишь быстрее размножит ошибку.

Когда пора — и когда можно не спешить

Скорее рано

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

Пора разбираться

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

«Пора» не означает «строим идеальную систему к понедельнику». Первый шаг спокойнее: выписать события, источники, ключи связи и вручную проверить несколько сделок. Уже после этого видно, что чинить и что автоматизировать.

Проверьте готовность за десять пунктов

Есть конкретный управленческий вопрос и человек, который примет решение по ответу.
Рекламные ссылки размечаются по единому правилу, а расходы доступны по кампаниям.
Все ключевые обращения попадают в CRM или другой единый реестр.
Идентификатор источника можно передать от сайта, звонка или чата в карточку лида.
У сделки есть стабильный ID, история этапов и обязательная причина закрытия.
Оплата и возврат связаны с заказом или сделкой, а не только с названием клиента.
Письменно определено, что бизнес называет лидом, продажей, выручкой и прибылью.
Известны владелец каждого источника, частота обновления и допустимая задержка.
Можно вручную проверить несколько цепочек от оплаты до рекламного источника.
В отчёте будет видна доля непривязанных и ошибочных записей.

Если половина пунктов пока не выполняется, аналитика не отменяется. Просто план меняется: сначала закрываем ранние разрывы, потом автоматизируем устойчивый путь. Иначе получится очень быстрый отчёт о старых ошибках.

Что обычно спрашивают перед стартом

Сквозная аналитика нужна только крупному бизнесу?

Нет. Размер решения должен соответствовать цене вопроса и сложности пути клиента. Небольшому бизнесу иногда достаточно регулярной связки расходов, сделок и оплат без отдельного хранилища и BI-платформы.

Можно ли сделать её только в Яндекс Метрике?

Метрика умеет принимать офлайн-конверсии и данные CRM и связывать их с визитами по идентификаторам. Но финансовые определения, полнота CRM, себестоимость и внутренние правила всё равно остаются ответственностью бизнеса.

Нужна ли сложная атрибуция с первого дня?

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

Что считать итогом первого этапа?

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