Реклама привела посетителя, форма отправилась, менеджер создал сделку. Но какой источник принёс оплату, а какой только обращения? Сквозная аналитика помогает соединить эти события. Команда Гуси-Лебеди объясняет, как собрать систему, в которой можно проверить происхождение каждого показателя, найти потерянную заявку и отличить выручку от прибыли.
Ниже разбираем устройство аналитики на учебном примере сайта услуг. Все идентификаторы и суммы в примерах условные. Они показывают способ расчёта, а не результаты клиентов.
Что такое сквозная аналитика и какие данные она связывает
Сквозная аналитика связывает расходы на привлечение с обращениями, работой отдела продаж и финансовым результатом. Веб-аналитика показывает наблюдаемые действия на сайте. CRM хранит обращения и сделки. Учёт оплат подтверждает поступление денег и возвраты. Чтобы получить общую картину, эти записи нужно соединить по понятным правилам.
Начните с конкретного вопроса. Какие кампании приводят подходящие заявки? Где обращения теряются после передачи менеджеру? Какие источники связаны с оплаченными заказами? Для каждого решения нужен свой набор данных. Универсальный график «эффективность рекламы» без определения результата мало помогает.
| Источник | Что берём | Что проверяем |
|---|---|---|
| Рекламный кабинет | Расходы, кампании и объявления | Период, валюту, состав затрат и корректировки |
| Сайт и счётчик | Визит, источник и события | Работу счётчика, метки и дубли событий |
| Форма или коллтрекинг | Обращение и связь с визитом | Получение заявки и её уникальный ID |
| CRM | Лид, квалификацию, сделку и этапы | Историю изменений и объединение дублей |
| Учёт оплат | Платежи, возвраты и отмены | Уникальность операций и контрольные суммы |
Согласуйте, что называется лидом, подходящим обращением, продажей и оплатой. Событие отправки формы, созданная сделка и поступившие деньги отвечают на разные вопросы. Если продажи занимают несколько месяцев, вчерашние заявки ещё не имеют окончательного результата. Показывайте их как незавершённые, а не автоматически как неудачные.
В проектирование системы веб-аналитики стоит включать карту источников до разработки отчётов. Сначала определите, какая запись подтверждает результат, затем выбирайте удобный способ его показать.
Как связать визит, заявку, сделку и оплату
У каждой сущности должен быть собственный идентификатор и явная связь с соседними записями. Учебная цепочка выглядит так: визит V-12, обращение L-104, сделка D-52, платежи P-81 и P-97. Две оплаты относятся к одной сделке. Два обращения одного человека при этом не обязательно являются дублем.
Связывать записи только по названию кампании, имени клиента или телефону ненадёжно: значения повторяются и меняются. Храните исходные идентификаторы систем и таблицу соответствий. Отдельно зафиксируйте правило объединения повторных обращений, иначе отчёт будет менять смысл при каждой очистке CRM.
Первый источник и последующие контакты сохраняйте раздельно. Если перезаписывать единственное поле source при каждом визите, история первого обращения исчезнет. Если хранить только первый источник, потеряются повторные касания. Нужна история, из которой можно собрать отчёт по выбранному правилу.
Для передачи офлайн-конверсий в Яндекс Метрику используются предусмотренные форматом идентификаторы, цель и время события. В документации по офлайн-данным описаны ClientID, UserID, yclid и PurchaseId, а также различия между форматами передачи. Выбор зависит от события и доступных данных.
ClientID нельзя считать универсальным паспортом человека на всех устройствах. Собственный UserID тоже требует настройки связи. Проверяйте, где идентификатор получен, как он попадает в заявку и сохраняется ли после внешней формы или перехода между доменами. Для меток договоритесь об общем формате, как в нашем разборе UTM-разметки. Не помещайте в UTM телефон, почту или другие лишние персональные данные.
Почему объединение таблиц может умножить расходы
Перед объединением определите, что означает одна строка каждой таблицы. В расходах это может быть кампания за день, в CRM одно обращение, в оплатах отдельная операция. Эти уровни детализации нельзя механически смешивать и затем суммировать все колонки.
Учебный пример: кампания потратила 10 000 рублей за день и получила десять обращений. Если присоединить дневной расход к каждой заявке, в десяти строках появится по 10 000 рублей. Сумма такой колонки станет 100 000 рублей. Расход не вырос: его размножило соединение данных.
| Таблица | Одна строка | Правильный контроль |
|---|---|---|
| Расходы | Кампания за день | Сумма совпадает с выгрузкой кабинета |
| Обращения | Уникальный LeadID | Повторная загрузка не увеличивает число лидов |
| Сделки | Уникальный DealID | История этапов не считается новыми сделками |
| Оплаты | Уникальная платёжная операция | Частичные платежи суммируются без дублирования |
Для отчёта по кампаниям сначала соберите обращения и оплаты до нужного уровня, затем соедините агрегаты с расходами. Если расход распределяется между заявками, покажите правило распределения. Не выдавайте распределённую сумму за точный расход, непосредственно измеренный для одного человека.
После каждого преобразования сверяйте число уникальных записей и контрольные суммы. Отдельно проверяйте пустые ключи, несколько соответствий одному ID и исчезнувшие строки. Эта проверка часто полезнее ещё одного красивого графика.
Как учитывать частичные оплаты, возвраты и прибыль
Сумма сделки в CRM, поступление денег и выручка по правилам учёта могут различаться. Выберите показатель и назовите его точно. Для отчёта по поступлениям берите подтверждённые платежи. Для выручки используйте согласованный источник финансового учёта. Статус «успешно» в CRM сам по себе не заменяет ни одно из этих подтверждений.
В учебной сделке клиент заплатил 40 000 и 60 000 рублей, затем получил возврат 20 000. Поступления составили 100 000, а поступления за вычетом возврата 80 000 рублей. Сделка остаётся одной. Возврат должен сохраняться отдельной связанной операцией, чтобы можно было восстановить историю.
Для повторной загрузки предусмотрите обновление существующей записи по устойчивому ID. Повтор того же платежа не должен создавать ещё одну оплату. Если источник исправил сумму, отчёт должен учесть исправление и сохранить возможность объяснить изменение.
Другой учебный расчёт: рекламный расход 20 000 рублей, учтённая выручка 100 000. ROAS равен 5, или 500% при процентном выражении; ДРР составляет 20%. Если переменные затраты равны 70 000, после них и рекламы остаётся 10 000 рублей. Это ещё не чистая прибыль компании: прочие расходы здесь не учтены.
Пишите формулу и состав затрат рядом с показателем. Когда себестоимость неизвестна, нельзя делать вывод об общей прибыльности на основании выручки. На уровне обращений отдельно оценивайте стоимость лида и качество заявок, не подменяя ими финансовый результат.
Как выбирать атрибуцию и разбирать расхождения
Посетитель мог сначала увидеть рекламу, потом вернуться из поиска и только позже оставить заявку. Атрибуция определяет, какому наблюдаемому контакту отчёт присваивает результат. Правило первого касания и правило последнего касания отвечают на разные вопросы. Сравнивайте источники при одной модели и явно показывайте её название.
Приписанная продажа не доказывает, что без рекламы её бы не было. Сквозная аналитика связывает записи и описывает наблюдаемый путь. Для причинного вывода нужны отдельные подходы к проверке гипотез. Не складывайте продажи из разных рекламных кабинетов: одна сделка может попасть в несколько отчётов.
Неизвестный источник оставляйте видимым. Подстановка последней активной кампании создаёт удобную, но выдуманную историю. Лучше показать долю несвязанных обращений и выяснить, на каком шаге теряются метки или идентификаторы.
Если числа расходятся, начните с определений и периода. Сверьте события с уникальными обращениями, часовой пояс, валюту, состав расходов и задержку выгрузки. Затем найдите конкретную заявку или оплату и проследите её путь. Общая разница в процентах не объясняет место потери.
Успешная загрузка офлайн-конверсий ещё не означает, что они связались с визитами. Проверяйте результат сопоставления. Отчёт Метрики «Офлайн-конверсии» помогает проверять привязку и разбирать её отсутствие. Условия и ограничения выбранного формата сверяйте с документацией при настройке.
Как внедрить сквозную аналитику и принять результат
Начните с ограниченного пилота: один канал, одна форма, одна CRM и понятный источник оплат. Составьте карту полей, правила объединения, определения показателей и список ответственных. Затем проведите контрольные истории от исходного события до строки отчёта.
- Новая заявка из размеченного перехода связалась с нужным источником.
- Повторное обращение обработано по согласованному правилу.
- Две частичные оплаты не удвоили число сделок.
- Возврат изменил нужный показатель и сохранил историю.
- Повторная загрузка не создала дубли.
- Остановка одного источника видна как задержка данных, а не как нулевые продажи.
Сверьте суммы по завершённому периоду с исходными системами. Проверьте долю обращений без источника, связанных оплат и дублей. На отчёте показывайте время последней успешной загрузки. Если выгрузка остановилась, руководитель должен видеть ограничение данных до принятия решения.
Выбирая сервис, проверяйте свои сценарии: частичные оплаты, возвраты, длинный цикл сделки, несколько CRM. Логотип системы в списке интеграций не подтверждает поддержку всех этих случаев. Оцените доступ к исходным данным, прозрачность формул, обработку ошибок и стоимость сопровождения.
В настройке обмена между сайтом и бизнес-системами нужны журнал ошибок, безопасная повторная обработка и сверка. Договоритесь об объёме доступа и сроках хранения данных. Готовый результат можно принять, когда команда объясняет число в отчёте через исходные записи, а исправление сбоя не требует вручную подгонять итоговую ячейку.