Сквозная аналитика

Что такое сквозная аналитика

Сквозная аналитика — не отчёт и не инструмент, а модель данных. Её задача — соединить в одну строку то, что в компании разложено по четырём разным системам:

Рекламная система → Сайт / приложение → CRM → Учётная система
     клик, расход      сессия, события    заказ    оплата, возврат

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

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

Три уровня зрелости

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

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

Проблема склейки идентификаторов

Главная техническая сложность сквозной аналитики не в отчётах, а в том, что «клиент» в каждой системе — это разный объект.

Один человек, который посмотрел товар с телефона, вернулся с рабочего ноутбука, оформил заказ на e-mail жены и забрал его в магазине по карте лояльности, породит четыре несвязанных записи. Без склейки первый визит с телефона будет приписан «прямым заходам», а рекламный канал, который его привёл, останется без выручки.

Эту задачу решает слой identity resolution — обычно внутри CDP. Он сопоставляет анонимные идентификаторы с известными (e-mail, телефон, ID клиента) в момент авторизации или оформления заказа и задним числом привязывает предыдущие анонимные сессии к профилю. Смежная задача — дедупликация клиентов: один человек в CRM часто существует в двух-трёх карточках.

Что считать выручкой

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

Оформлено 100%
  − не подтверждено / недозвон
  − отменено до отгрузки
  − не выкуплено (для доставки с примеркой)
  − возвращено после покупки
= Оплаченная и не возвращённая выручка

Практические правила:

• Выручка признаётся по оплате, а не по оформлению. Для предоплатных моделей разница мала, для fashion с примеркой и постоплатой — принципиальна.
• Возвраты вычитаются из того канала и той механики, которые привели к покупке, а не из общей кучи текущего месяца. Иначе канал с высокой долей возвратов выглядит лучше, чем есть.
• Окно возврата закладывается в отчётность. Если возвраты приходят до 30 дней, недельный ROAS всегда предварительный.
• Маржа важнее выручки, когда каналы приводят разные категории. Один канал даёт оборот на технике с низкой маржой, другой — меньший оборот на аксессуарах с высокой.

Игнорирование возвратов — самый дешёвый способ систематически завысить ROAS и недооценить долю рекламных расходов по всем каналам сразу.

Где здесь платформа персонализации

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

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

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

Важная оговорка: атрибуция клика по виджету — слабое доказательство. Она показывает связь, но не причинность. Настоящий вклад измеряется A/B-тестом или holdout-группой, а сквозная аналитика нужна, чтобы посчитать разницу между группами не в оформленных заказах, а в деньгах.

Чек-лист внедрения

1. Разметка трафика. Все платные и рассылочные переходы с UTM-метками по единому справочнику. Проверить, что редиректы и мобильные приложения метки не теряют.
2. Единая схема событий. Согласованный список событий сайта и приложения с одинаковыми названиями и параметрами — фундамент для отслеживания событий.
3. Общий ключ заказа. Один и тот же order_id на сайте, в CRM и в учётной системе. Это дешевле любой последующей эвристики сопоставления по сумме и времени.
4. Идентификатор клиента. Передача известного ID при авторизации и оформлении, склейка с анонимными сессиями, единый профиль клиента.
5. Статусы заказа во времени. Не текущий статус, а история изменений — иначе пересчёт возвратов задним числом невозможен.
6. Правило признания выручки. Зафиксировано письменно и одинаково применяется в маркетинге, финансах и продуктовой команде.
7. Сверка контрольных сумм. Ежемесячно: выручка в модели против выручки в бухгалтерии. Расхождение больше 2–3% — повод искать разрыв, а не округлять.
8. Проверка причинности. Для инструментов и изменений на сайте — эксперимент с контрольной группой, а не только отчёт по атрибуции.