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

Сквозная аналитика связывает рекламный клик, заявку и оплату в одну цепочку: видно, какой канал принёс маржу, а какой сжёг бюджет. Без CRM, UTM-меток и склеивания клиента это отчёт по трафику, а не по деньгам. Считать нужно ROMI от маржи, с явной моделью атрибуции и владельцем контура в компании.

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

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

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

Касанием считается любое взаимодействие, которое можно привязать к клиенту: клик, заход на сайт, звонок, письмо, визит в офис. Онлайн и офлайн живут в одном окне, если есть идентификатор — ClientID, телефон или email.

Веб-аналитика заканчивается там, где появилась заявка. Сквозная начинается там, где заявка стала сделкой, отказом или возвратом. Система не заменяет CRM и не чинит воронку продаж. Если менеджеры не ставят стадии и источник, отчёт покажет дыру в данных — не «какой канал лучше».

Веб-аналитика считает визиты и заявки. Сквозная аналитика считает маржу по каналу после сделки и возврата.

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

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

Собственнику нужен срез «канал -> маржа»: что отключить. Маркетологу — кампания, объявление, ключ: куда долить. РОПу — какие заявки доходят до оплаты, а какие менеджеры справедливо бракуют. Один отчёт на троих не работает: разные решения, разные поля.

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

Пока канал не доведён до маржи, перераспределение бюджета — гадание по заявкам.

Как устроен контур данных: от кабинета до оплаты

Склейка рвётся не в дашборде, а на стыке систем. Рекламный канал отдаёт клик из кабинета. UTM-метки маркируют этот канал в ссылке. Яндекс Метрика фиксирует визит. Коллтрекинг ловит звонок и передаёт его в CRM.

Заявка фиксируется в CRM. Оплаты, возвраты и склад закрывают контур. Выпал один узел — канал в отчёте становится «не определён».

Склеивают человека три идентификатора: ClientID счётчика, телефон, email. Визит без ClientID не догонит сделку. Звонок без номера не догонит карточку. Сделка, которую менеджер завёл руками, часто идёт без источника.

Статический коллтрекинг даёт один подменный номер на канал или кампанию. Его хватает, когда каналов мало и звонок не нужно доводить до объявления. Динамический подменяет номер на визит и склеивает звонок с заявкой через ClientID. Его берут, когда кампаний много и звонок — основной лид. Ошибка выбора статики при десятках кампаний сваливает все звонки в «канал» без ключа.

Чаще всего контур рвётся в трёх местах. Форма без UTM — заявка без канала. Нет динамического коллтрекинга — звонок без ClientID. Менеджер создал сделку вручную — сделка без источника. Счётчик без CRM не ответит, кто купил, какая маржа и кто вернул товар. Срок жизни cookie и лимиты счётчика берите из справки Яндекс Метрики: в статье их нет, чтобы не соврать.

Цепочка на схеме: кабинет -> UTM и счётчик -> коллтрекинг -> CRM -> оплата и возврат -> ROMI по каналу.

Модели атрибуции: какая искажает ROMI

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

Last click занижает верх воронки, когда цикл длинный и касаний несколько: контент остаётся без заслуги, бренд-запрос забирает всё. First click переоценивает баннеры: человек увидел, ушёл и купил позже по бренду — баннер выглядит героем. Data-driven не лучшая «вообще»: на малом числе сделок она усиливает случайность. На длинном B2B-цикле стадия сделки в CRM важнее последнего клика.

Мнение. Если сделка закрывается в одну сессию, берите last click и не усложняйте. Если цикл тянется неделями и касаний несколько — last click вам не подходит.

Какие метрики считать и как не перепутать ROMI с ROI

Путают две формулы — принимают два разных решения по бюджету. Сквозная аналитика рассчитывает ROMI от маржи рекламного контура: (маржа затраты на канал) / затраты на канал. ROI считают от прибыли бизнеса в целом.

CPC — стоимость клика, CPL — заявки, CAC — привлечённого покупателя. Конверсия в сделку — доля заявок, ставших оплатой. AOV — средний чек. LTV копят в CRM по повторным покупкам, а не по одному заказу.

Для лидогена, магазина и B2B в числитель ставят маржу после возвратов, не выручку. Выручка без себестоимости и возврата рисует «успешный» канал, который отдаёт товар в минус.

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

РСЯ выигрывает по CPL и проигрывает по деньгам. Карты выглядят дорогими на заявке и выигрывают по ROMI. Сильнее всего результат двигают конверсия в сделку, маржа, возвраты и модель атрибуции, а не ставка за клик. Детализация до объявления и ключа нужна, когда каналов уже несколько и по каналу решение принято. На десяток заявок в месяц ключ рано: шум больше сигнала.

ROMI считают от маржи после возвратов, ROI — от прибыли. Путать их нельзя: это разные решения по бюджету.

Практический стек без привязки к вендору

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

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

Факт. Офлайн-конверсии загружаются в Яндекс Директ из CRM. Без идентификатора визита кабинет не знает, какая кампания закрылась офлайном.

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

Выбирать сервис по лендингу бессмысленно. Сравнивают порог входа, интеграции, коллтрекинг, отчёты, цену владения и того, кто внедряет. Цена владения — лицензия плюс внедрение плюс сопровождение, не «тариф с сайта» в отрыве от труда людей. Актуальные тарифы смотрите на сайтах вендоров: цифры с лендинга устаревают быстрее статьи.

Для самого частого случая — сайт с формами, два-три канала в Директе, CRM уже стоит — начните с Метрики, UTM и таблицы. Roistat, Calltouch и Comagic не ваш случай, пока выгрузка занимает меньше вечера и звонков ещё можно склеить вручную.

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

Схемы под лидоген, магазин и B2B и чек-лист внедрения

Лидоген, магазин и B2B считают разные деньги. Один дашборд на троих врёт двоим.

Лидогенерация. Считают стоимость сделки, не заявки: CPL без квалификации бесполезен. Главный риск — отказы на этапе РОПа, которые маркетинг продолжает закупать. Отчёт: канал -> квалифицированная заявка -> сделка.

Интернет-магазин. Считают маржу, возвраты, средний чек и выгрузку из 1С. Выручка без себестоимости врёт. Главный риск — «успешный» канал с возвратами. Отчёт: канал -> заказ -> маржа после возврата. Рядом с CRM и 1С обычно стоит CRM и сайт на 1С-Битрикс.

B2B. Цикл длинный, касаний несколько, LTV важнее разового ROMI. Главный риск — last click на сделке, которая зрела месяцами. Отчёт: канал и стадия воронки, не только закрытие.

Срок внедрения зависит от числа каналов, наличия CRM и коллтрекинга. Ориентир берётся из опыта конкретного проекта, не из норматива.

Ошибки внедрения, 152-ФЗ и кто владеет контуром

Контур разваливается не от «сложной аналитики», а от отсутствия хозяина. Типовые ошибки одни и те же: разные UTM у подрядчиков, сделки без источника, last click на длинном B2B, отчёт по выручке вместо маржи. Без владельца метки, стадии и отчёты разъезжаются.

Номера телефонов и связка личности с визитом — персональные данные. Их обрабатывают по 152-ФЗ «О персональных данных». Сроки хранения и размеры ответственности в статье не пересказываю — смотрите актуальную редакцию закона. Для cookies счётчика нужна понятная политика, а не «молчаливая» склейка.

Агентство сдаёт клиенту не график кликов. Канал -> заявка -> сделка -> маржа, модель атрибуции указана явно. Иначе отчёт нельзя сравнить со следующим периодом.

Сквозным можно считать уже такой контур. Есть стандарт UTM и цели Метрики на заявку. В CRM стоят источник и стадия. Хотя бы одна оплата привязана к каналу. Коллтрекинг и офлайн-конверсии — следующий слой, не точка старта.

Если контур ещё не собран, начните с владельца, UTM и полей CRM. Когда цепочка дойдёт до маржи, будет что считать — и будет кому отвечать за цифру.

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

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

Источники

• Справка Яндекс Метрики — Яндекс
• Справка Яндекс Директа — Яндекс
• Федеральный закон «О персональных данных» № 152-ФЗ — Российская Федерация
• Сбор параметров кампании (UTM) — Google