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

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

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

Сквозной отчёт начинается не с ROI, а с вопроса: по какому ключу одна заявка узнаёт себя в рекламе, на сайте и в CRM.

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

Не все шаги имеют один и тот же идентификатор. У визита может быть ID браузера, у формы — ID отправки, у звонка — номер и время соединения, у сделки — номер CRM. Поэтому заранее описывают, что связывает этапы: параметры ссылки, идентификатор визита, телефон, адрес почты, идентификатор обращения или явная передача поля в CRM. Телефон и email помогают дедупликации, но не всегда уникальны: бывают общие номера, опечатки и повторные заявки.

Если связи нет, таблица всё ещё может стоять на одном экране, но это не сквозная аналитика. Это рядом поставленные отчёты.

Одна сущность должна иметь владельца. CRM обычно отвечает за текущий статус и сумму сделки, рекламный кабинет — за собственный расход, платёжная система или учёт — за подтверждённую оплату и возврат. Аналитическая витрина собирает эти данные, но не должна молча переписывать первичную систему.

Например, маркетолог помечает лид «целевым» по своей логике, а отдел продаж закрывает сделку как нецелевую. Если отчёт складывает оба статуса без правила, конверсия будет зависеть от того, чей файл обновился последним. Нужно договориться о словаре: что такое обращение, квалифицированный лид, сделка, выручка, оплаченный заказ и возврат. У каждого определения есть дата, система-источник и ответственный.

Это особенно заметно в B2B. Заявка на сайте может превратиться в коммерческое предложение через неделю и в оплату через три месяца. Нельзя записать выручку в день клика только потому, что в отчёте хочется видеть быстрый результат.

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

Возврат, скидка, комиссия, НДС, прочие налоги и себестоимость влияют на разные строки и не складываются в одну универсальную формулу. Скидка меняет цену сделки; возврат требует связать обратную операцию с исходной; комиссия эквайера или площадки может быть отдельным расходом либо учитываться иначе по принятой модели; включение НДС и других налогов зависит от назначения отчёта и учётных правил. Прибылью нельзя называть разницу между оплатой и рекламным расходом, пока не определён полный периметр относимых расходов. Рядом с числом подписывают формулу, момент фиксации, состав сумм, валюту и систему-источник. Этот текст не заменяет бухгалтерскую, налоговую или юридическую оценку.

После того как цепочка собрана, возникает вопрос: как распределить ценность сделки между рекламными касаниями. Модель последнего клика отдаст весь результат последнему известному источнику. Другая модель может распределить ценность между первым, последним и промежуточными касаниями. GA4 и Яндекс Метрика применяют собственные настройки, окна и области действия моделей атрибуции; одинаковое название модели не гарантирует одинаковый результат между платформами.

Это не ошибка, а свойство модели. Атрибуция отвечает на вопрос «как мы договорились учитывать наблюдаемую сделку». Она не доказывает, что именно этот канал вызвал покупку. У клиента мог быть офлайн-контакт, рекомендация, повторный визит без меток или несколько параллельных кампаний.

Смена модели атрибуции меняет распределение ценности, но не переписывает историю решения покупателя.

Поэтому рядом с числом нужны период, модель, окно и состав данных. Если коммерческий директор сравнивает две недели, а в середине изменились правила UTM или статус сделки, вывод о канале будет ложным ещё до начала оптимизации.

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

Проверяют цепочку не общим итогом, а контрольными примерами. Берут одну размеченную кампанию, один визит, одно обращение, одну сделку и один платёж. На каждом шаге фиксируют ID, время, сумму и статус. Затем повторяют сценарий для звонка, письма, повторного клиента и отмены. Для телефонного канала отдельную механику раскрывает коллтрекинг, для писем — email-трекинг.

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

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

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

Импорт платформы тоже имеет узкую семантику. GA4 Campaign Data Import загружает агрегированные по дням расходы, клики и показы и соединяет их с уже измеряемыми кампаниями; это не импорт банковской оплаты или бухгалтерской прибыли. В Метрике расходы можно загрузить через интеграции, CSV или API, причём поле Expenses документировано без НДС, а повторная ручная загрузка расходов Директа создаёт дубли. Суммы сравнивают только после выравнивания валюты, НДС, периода и уровня кампании.

Задержка передачи результата ограничена правилами продукта. На дату проверки GA4 Measurement Protocol допускает обратную дату события в пределах 72 часов и рекомендует передавать события для совместной обработки с браузерными данными в течение 48 часов. В Метрике срок передачи результата и срок привязки к визиту — разные условия: для такой привязки 21-дневный период считается от последнего визита до обработки данных. Поэтому трёхмесячную B2B-оплату можно быстро загрузить после её поступления, но Метрика не свяжет её с мартовским визитом одним идентификатором. Для длинного цикла CRM и учёт остаются источниками оплаты; в Метрике это будет непристыкованная запись либо понадобится другое предусмотренное продуктом решение, которое проверяют отдельно.

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

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

До выбора сервиса достаточно составить карту полей и один контрольный поток. В ней нужны название источника, ID, система-владелец, момент создания, правило обновления и ответственный за ошибку. Затем выбирают один приоритетный канал и проверяют его до оплаты. Если полей и статусов нет, сложный дашборд только быстрее покажет старый хаос.

Особое внимание — персональным данным и доступам. Интеграция может передавать телефоны, почты, псевдонимные идентификаторы, записи коммуникаций и детали сделок; хеширование или замена значения внутренним ID не всегда превращает данные в обезличенные. Такие сведения не помещают в UTM-метки и открытые URL. Компания отдельно определяет цель и правовое основание, минимальный состав, роли доступа, сроки удаления, меры защиты и условия поручения обработки поставщику.

Использование иностранной платформы само по себе не позволяет по названию сервиса установить маршрут каждого набора данных. Проверяют фактических получателей, серверы и субподрядчиков: если возникает трансграничная передача, отдельно применяют требования статьи 12 № 152-ФЗ. Требование локализации при сборе персональных данных граждан России и правила трансграничной передачи — разные проверки; их нельзя заменить одной отметкой в договоре или баннере.

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

После этого добавляют следующий источник: звонок, письмо, мессенджер или повторную покупку. Каждый новый канал приносит особую проблему. Звонок может состояться без сайта; письмо — прийти с переадресации; постоянный клиент — вернуться без рекламной метки. Их нельзя притворно склеить с первым визитом только ради стопроцентного отчёта. Лучше сохранить признак «источник неизвестен» и сформулировать, какого сигнала не хватает.

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

Такая последовательность менее эффектна, чем запуск большого дашборда, но быстрее показывает владельца ошибки. Если в тестовой цепочке пропадает идентификатор, это задача интеграции. Если сделка не получает обязательный статус, это задача процесса в CRM. Если оплату нельзя отличить от счёта, вопрос уходит к учёту. Сквозная аналитика ценна именно тем, что не прячет эти границы.

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

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

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

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

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