Сквозная аналитика связывает расходы на рекламу с обращениями и оплатами, сохраняя источник на пути от визита до сделки в CRM.
Как связать рекламный визит с оплаченной сделкой
Для связи рекламы с продажами нужны переходы между записями разных систем. От обращения должна находиться карточка CRM, от карточки — сделка, от сделки — подтверждённые платежи. Данные веб-аналитики помогают связать обращение с рекламным источником. В Справке Яндекс Метрики описана основа такой связки: UTM-метки, загрузка рекламных расходов, сохранение ClientID в CRM и передача данных о клиентах и заказах.
ClientID обозначает посетителя сайта, а для поиска отдельного визита дополнительно нужны сведения о его времени и источнике.
Сквозной отчёт объединяет записи веб-аналитики, рекламы и продаж. Такое назначение метода описано и в материале Яндекс Рекламы. Однако наличие интеграции ещё не доказывает, что конкретный платёж связан с нужным обращением.
Заявка подтверждает обращение человека, а статус сделки отражает этап работы отдела продаж. Если клиент внёс аванс, полная стоимость договора в карточке не равна уже полученной сумме.
В разборе сквозной аналитики для руководителя описано, какие решения помогает принимать отчёт. Проверку связки удобнее начинать с одной заявки: для неё должны находиться исходное обращение, сделка и запись об оплате.
Какие данные сохранить в карточке заявки
Сохраняйте данные, по которым можно найти исходное обращение и проверить его связь с посетителем сайта. Для каждого поля определите источник данных, место их хранения и способ проверки. Предложенная ниже карта — основа для обсуждения интеграции, которую нужно адаптировать к вашей CRM.
| Поле | Где возникает | Где сохранить | Как проверить |
|---|---|---|---|
| Идентификатор посетителя, например ClientID Метрики | В системе веб-аналитики | В записи обращения или связанном поле CRM | Сравнить значение на сайте и в тестовой карточке |
| UTM-метки | В адресе рекламного перехода | В записи обращения или истории касаний | Открыть размеченную ссылку и проверить сохранённые значения |
| Время и канал обращения | При отправке формы, звонке или сообщении | В записи обращения | Сверить исходное обращение с записью в CRM |
| Идентификаторы заявки и сделки | При создании записей в CRM | В связанных записях и выгрузке | Найти сделку по заявке и проверить обратную связь |
| Сумма, дата и идентификатор платежа | В системе учёта оплат | В связанной записи или выгрузке для отчёта | Сверить платёж с исходным учётом и сделкой |
UTM-метки описывают источник и кампанию перехода, но одинаковая метка может встречаться у многих посетителей, поэтому её недостаточно для связи отдельной заявки с визитом.
ClientID тоже нельзя считать номером заявки или отдельного посещения. При проектировании связки проверьте, как система различает повторные визиты и обращения одного посетителя. Для повторных обращений предусмотрите историю касаний: если новое обращение затирает первоначальный источник, проверить распределение продаж между каналами будет сложнее.
Как сохранить источник формы, звонка и сообщения
Проверяйте каждый канал обращения отдельно: работающая форма ничего не говорит о связи звонков и сообщений с CRM. Для формы можно предусмотреть передачу данных посетителя вместе с заявкой. Для звонков и мессенджеров сначала выясните, какие связи поддерживает выбранная интеграция при передаче обращений.
| Канал обращения | Что нужно проверить | Признак потери связи | Тест |
|---|---|---|---|
| Форма | Передачу данных посетителя и обращения | Заявка создана, ожидаемые поля пустые | Отправить форму после размеченного перехода и открыть карточку |
| Звонок | Связь записи коллтрекинга с посетителем и CRM | Звонок записан, соответствующая заявка не находится | Найти тестовый звонок в телефонии и CRM |
| Мессенджер | Связь перехода с диалогом, если интеграция её поддерживает | Диалог есть, исходный переход определить нельзя | Начать диалог с сайта и проверить доступные данные в CRM |
| Ручное обращение | Основание для указанного источника | Источник выбран без подтверждения | Проверить происхождение записи и способ определения источника |
Если интеграция не передаёт источник, сохраняйте обращение с отметкой «неизвестен». Ответ клиента «нашёл в интернете» можно хранить отдельно как сведения с его слов. Этого недостаточно для привязки продажи к конкретной кампании.
Повторный контакт добавляет ещё одно касание: например, человек мог сначала написать после рекламы, затем позвонить напрямую и позже купить. Заранее определите, по какому правилу отчёт распределяет результат между касаниями. Если история потеряна, отразите ограничение рядом с выводами по каналам.
Восстановление источника по догадке создаст видимость точности.
Какие этапы сделки передавать в аналитику
Разделите события по этапам: обращение получено, клиент прошёл квалификацию, договор заключён, оплата поступила. Для передачи статусов заказа в Метрику согласуйте, какой статус соответствует каждому этапу и связанной с ним цели. Если менеджеры по-разному понимают статус «успех», отчёт смешает, например, подписанные договоры и полученные оплаты.
Следующая карта служит примером, её названия не обозначают готовый набор статусов конкретного сервиса.
| Событие | Основание для записи | Что учитывать в отчёте |
|---|---|---|
| Квалифицированная заявка | Выполнены согласованные критерии квалификации | Число подходящих обращений |
| Сделка на согласовании | Менеджер подтвердил стадию | Продвижение по воронке |
| Частичная оплата | В учёте есть подтверждённый платёж | Фактически полученную сумму |
| Полная оплата | Получены все платежи по согласованной сумме сделки | Общую оплаченную сумму без повторного учёта аванса |
| Отмена или возврат | Есть соответствующая запись в учёте | Изменение результата по согласованному правилу |
Представьте договор с авансом и доплатой. Если отчёт прибавит полную стоимость договора к уже учтённому авансу, поступления окажутся завышены. Для проверки нужны отдельные платежи и их связь со сделкой.
Заранее определите дату учёта платежей и порядок отражения возвратов. Если выбранная интеграция не поддерживает нужную детализацию, её придётся учитывать в отдельном отчёте.
Нельзя заменять отсутствующие данные статусом «сделка выиграна».
В каком порядке собрать данные в один отчёт
Начните с карты данных и проверки тестовой цепочки. Для первой проверки выбирайте самый понятный путь, по которому поступает обращение, а затем подключайте остальные каналы. Такой порядок поможет проще найти участок, на котором при передаче данных теряется связь между записями разных систем.
- Опишите обращения. Перечислите формы, звонки, мессенджеры и ручные заявки.
- Согласуйте поля и связи. Определите, как обращение связывается с посетителем, заявкой и сделкой.
- Проверьте передачу обращений. Найдите ожидаемые поля в каждой тестовой карточке.
- Свяжите сделки с оплатами. Установите правила для авансов, доплат, отмен и возвратов.
- Добавьте расходы. Зафиксируйте состав затрат и период, к которому они относятся.
- Сверьте исходные записи. Проследите тестовые обращения через системы.
- Соберите отчёт. Показывайте заявки, стадии сделок и подтверждённые оплаты отдельно.
Готовую интеграцию и собственную сборку сравнивайте по одинаковым критериям: поддержка нужных каналов, сохранность полей, разбор ошибок на уровне записи и обслуживание после запуска. Начните с проверки готового решения, если оно покрывает вашу карту данных. Собственную сборку стоит рассматривать, когда проверка выявила существенные ограничения.
Удобная диаграмма не поможет найти источник звонка, если связь потеряна при передаче данных, поэтому внешний вид отчёта оценивайте после проверки записей.
Для B2B с долгим согласованием пригодится разбор учёта рекламы при длинном цикле сделки. В такой ситуации особенно важно различать дату обращения и дату оплаты.
Как проверить путь заявки до принятия решений
Проведите тестовое обращение через каждый действующий канал. Найдите запись обращения, карточку CRM, связанную сделку и отражение платежа в отчёте. Для проверки оплаты используйте тестовую среду или согласованную контрольную запись, которую после проверки исключат из рабочих показателей, чтобы она не учитывалась в них.
Для одной цепочки проверьте:
- Посетителя и визит: доступны ожидаемые идентификаторы, источник и время перехода.
- Обращение: форма, звонок или сообщение появились в исходной системе.
- Заявку: в CRM создана карточка с ожидаемыми данными.
- Сделку: она связана с нужной заявкой, дубля нет.
- Оплату: сумма, дата и связь со сделкой совпадают с учётом.
- Отчёт: показаны ожидаемые канал, стадия и сумма.
После проверки отдельных цепочек сравните число записей и суммы в исходных системах и отчёте. Используйте одинаковые периоды, часовые пояса, фильтры и правила отбора.
Совпадение итогов полезно для сверки, но само по себе не подтверждает правильность каждой связи.
Пустой источник проверяйте по пути от исходного обращения до CRM, пропавший идентификатор — по пути от его получения на сайте до поля заявки. При дублях выясните, сколько раз отправилось событие и сколько карточек создала интеграция.
Разделите работу по месту сбоя. Маркетолог проверяет разметку и расходы, специалист по CRM — поля и связи, отдел продаж — стадии и оплаты. После исправления повторите соответствующее тестовое обращение.
Точная атрибуция недоступна, если история касаний потеряна и исходных записей нет. Такие заявки и оплаты показывайте отдельно: назначать им рекламный источник без основания нельзя.
Как оценить канал по продажам и выбрать следующее действие
Сравнивайте каналы по одной стадии воронки и одинаковым правилам учёта. Для оценки поступлений нужны подтверждённые платежи, а для оценки окупаемости дополнительно определите, какие затраты и финансовый результат входят в расчёт. Ниже условный учебный пример: все суммы придуманы для объяснения, к результатам Adget они не относятся.
Предположим, расходы и поступления относятся к сопоставимым группам заявок, а оплаты проверены.
| Канал | Рекламные расходы | Заявки | Оплаченные сделки | Подтверждённые поступления | Поступления минус рекламные расходы |
|---|---|---|---|---|---|
| А | 100 000 ₽ | 20 | 2 | 150 000 ₽ | 50 000 ₽ |
| Б | 100 000 ₽ | 10 | 3 | 240 000 ₽ | 140 000 ₽ |
Стоимость заявки равна рекламным расходам, делённым на число заявок: в примере это 5 000 ₽ для канала А и 10 000 ₽ для канала Б. При равных расходах Б принёс больше оплаченных сделок и поступлений. Последняя колонка показывает только разность поступлений и рекламных расходов.
По ней нельзя определить прибыль бизнеса: в расчёте отсутствуют себестоимость и другие затраты.
Если маржинальность, возвраты и возраст заявок сопоставимы, канал Б стоит первым проверить на возможность увеличения бюджета. Данные таблицы дают основание для гипотезы, но не доказывают, что дополнительный бюджет принесёт продажи в прежней пропорции.
При длинном цикле сделки такое сравнение неприменимо без учёта возраста заявок. Нынешние обращения ещё могут проходить согласование, а сегодняшние оплаты — относиться к старым кампаниям. Сравнивайте группы заявок за одинаковые периоды привлечения и показывайте незакрытые сделки отдельно.
Практический вывод: сначала проверьте связь записей и сопоставимость данных.
После этого выбирайте канал для контролируемого изменения бюджета и оценивайте последующие оплаты. Если нужна помощь со связью рекламы, CRM и отчёта, обсудите комплексный интернет-маркетинг с аналитикой продаж.
Частые вопросы
Как понять, что данные рекламы и CRM относятся к одной заявке?
Проверьте идентификатор посетителя, время и данные исходного обращения в карточке CRM. Затем найдите связанную сделку. Одного совпадения ClientID недостаточно для различения повторных обращений, а название кампании может совпадать у разных клиентов.
Что делать, если клиент сначала написал, а потом позвонил?
Сохраните оба обращения в истории клиента и проверьте их связь со сделкой. Источник продажи определяйте по согласованному правилу распределения результата между касаниями. Если первое касание потеряно, отметьте это ограничение в отчёте.
Когда можно перераспределять рекламный бюджет по отчёту?
Когда проверены связи записей, полнота данных и одинаковый способ расчёта для сравниваемых каналов. Учитывайте возраст заявок, незакрытые сделки, маржинальность и возвраты. Первое изменение бюджета рассматривайте как гипотезу, которую нужно проверить по последующим результатам.
Источники
Документы проверены 21 октября 2026 года. Они подтверждают назначение сквозной аналитики и описанную основу передачи данных в Метрику. Карта полей, порядок проверки и расчёт в статье — практические рекомендации и учебный пример.
- Сквозная аналитика — Справка Яндекс Метрики. Раздел «Чтобы собирать сквозную аналитику» описывает UTM-метки, загрузку расходов, сохранение ClientID в CRM и передачу данных о клиентах и заказах. Раздел об отчётах указывает возможность анализа этапов воронки через цели, использованные при передаче статусов заказа.
- Что такое сквозная аналитика: как её настроить в Яндекс Метрике и использовать для маркетинга и продаж — Яндекс Реклама. Материал обновлён 17 марта 2026 года. Раздел «Что такое сквозная аналитика» описывает объединение данных веб-аналитики, рекламных платформ, CRM и электронной коммерции для оценки пути клиента и результатов каналов.
