Разные сервисы фиксируют разные данные, а сквозная аналитика связывает эту информацию между собой. В местах стыковки сервисов иногда возникают расхождения. Например, рекламный кабинет передал клик, но сайт из‑за переадресации срезал UTM‑метки — и данные уже не сходятся.

На связи Андрей Луненко, руководитель продуктового маркетинга Яндекс Метрики. В этой статье рассказываю, как прийти к состоянию, в котором любое расхождение данных будет объяснимым, измеримым и контролируемым. 

Сначала разберёмся, как данные проходят путь от клика до сделки

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

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

1. Пользователь взаимодействует с рекламой. Предположим, человек кликает по объявлению в Директе и переходит на сайт. В зависимости от настроек рекламной кампании оплата может списываться за клики или за совершённые конверсии.

Главная задача этого этапа — определить источник перехода. Для этого Директ автоматически добавляет к ссылке идентификатор клика yclid, который помогает Метрике связать визит с конкретным рекламным переходом. Дополнительно можно использовать UTM‑метки. Если при переходе на сайт метки теряются, например из‑за некорректных редиректов, Метрика может не определить конкретную кампанию или объявление. Это снижает точность аналитики и затрудняет оценку эффективности рекламы.

2. Пользователь попадает на сайт. После загрузки страницы срабатывает счётчик Метрики. Он фиксирует визит и связывает его с переходом из рекламы. Для этого Яндекс Метрика присваивает посетителю ClientID — уникальный идентификатор, который сохраняется в cookie браузера. Так Метрика фиксирует, какие страницы смотрел пользователь, сколько времени провёл на сайте и какие действия совершил.

На этом этапе формируется связка: «Рекламная кампания → Сессия → Идентификатор ClientID».

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

1. Через форму на сайте. Пользователь вводит имя и телефон. Скрипты сайта подтягивают из куки присвоенный ClientID, а из адреса страницы — UTM‑метки и yclid. При нажатии на кнопку «Отправить» форма передаёт в базу весь этот пакет данных.

2. Через телефонный звонок. Визит на сайте связывается со звонком через коллтрекинг. Чтобы система поняла, кто именно звонит, используется динамический номер. Сервис выделяет под сайт определённый пул номеров и показывает каждому посетителю персональный. Пока человек смотрит сайт, этот номер закреплён за его ClientID. Когда происходит звонок, коллтрекинг понимает по привязанным данным, кто звонит по номеру.

Если цепочка рвётся, то мы уже не узнаем, с какого объявления пришёл этот человек.

4. Данные по обращениям попадают в CRM. СRM‑система создаёт карточку контакта и открывает сделку. Грамотная сквозная аналитика с CRM держится на том, что вместе с телефоном в сделку записывают рекламный источник и ClientID. Дальше с обращением работает отдел продаж.

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

5. Данные о совершённых сделках отправляют обратно в рекламные системы. Теоретически этот этап можно пропустить. Но в идеале данные по сделкам с прикреплёнными рекламными идентификаторами нужно возвращать назад — в Метрику и Директ. Это можно сделать через офлайн‑конверсии.

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

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

6. Формируется сводный отчёт. На финальном шаге массивы данных объединяются через специальные инструменты. На этом этапе сквозная аналитика в маркетинге и помогает разобраться в его эффективности: какие кампании дают прибыль, а какие сжигают бюджет; окупается ли стоимость лида; какой CAC у каналов; где выше LTV.

Найдём источники расхождения и зафиксируем допустимый порог 

Ситуация, при которой одна система фиксирует 1 000 кликов, а другая — 850 визитов, к сожалению, норма. Есть четыре объективные причины того, почему не получается свести данные со стопроцентной точностью

Системы измеряют разные сущности. Пользователь мог случайно кликнуть по объявлению и закрыть вкладку через секунду — рекламная система списала деньги за клик, но счётчик Метрики на сайте не прогрузился.

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

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

Разрыв цепочки между устройствами (кросс‑девайс). Клиент может посетить сайт днём с рабочего компьютера через поиск Яндекса, а вечером продолжить со смартфона из закладок и оформить заказ. Для рекламы клик с компьютера покажется пустым, а в CRM заказ запишется как бесплатный прямой заход.

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

Поймём, почему могут теряться данные

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

Чтобы Метрика могла связать офлайн‑конверсию с исходным визитом пользователя, файл загрузки должен содержать идентификатор, по которому можно сопоставить конверсию с предыдущими действиями пользователя. Для этого используют несколько типов идентификаторов:

• ClientID — один из основных идентификаторов для связи офлайн‑конверсии с визитом пользователя

• yclid — идентификатор клика по объявлению

• хешированный номер телефона или email клиента

Как правило, цепочка передачи данных рвётся в четырёх типовых узлах.

1. Реклама ➔ Сайт

2. Сайт ➔ Обращение 

3. Звонки и офлайн‑коммуникации

4. CRM ➔ Отчёт 

Реклама → Сайт

На этом отрезке нужно довести метку рекламного клика до страницы сайта в неизменном виде. Разбираемся, что может сломаться.

Технические редиректы срезают параметры. Объявление настроили на адрес site.ru/catalog, а сервер сайта принудительно перенаправил пользователя на https://www.site.ru/catalog/. Если при этом параметры запроса не переносят, то UTM‑метки и динамический параметр yclid моментально исчезают.

Конфликт автоматической и ручной разметки. В кампаниях могут одновременно использоваться автометки Яндекса и вручную собранные UTM‑метки. Если синтаксис составлен с ошибкой, системы аналитики не смогут корректно распарсить URL.

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

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

Сайт → Обращение

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

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

Форма не собирает скрытые поля. Чтобы связать обращения из CRM с визитами пользователей в Метрике, необходимо настроить передачу идентификатора ClientID. Для этого его можно автоматически записывать в скрытое поле формы и передавать в CRM вместе с заявкой. Если ClientID не передаётся, системе будет сложнее сопоставить обращение с визитом и определить, какой источник трафика привёл клиента.

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

Звонки и другие офлайн‑конверсии

Если бизнес принимает звонки или уводит людей в мессенджеры, риск потери данных возрастает в разы. Рассказываем, почему такое случается.

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

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

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

CRM → Отчёт

Даже если техническая связка от рекламы до CRM отработала идеально, данные могут сломаться на этапе работы с продажами, и вот почему.

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

Несопоставленные статусы сделок. Аналитический сервис ожидает стандартную воронку статусов: «Новый лид» → «В работе» → «Оплачено» или «Отказ». Если в CRM заводят кастомные статусы (например, «Ждём согласования договора» или «Перенос на следующий квартал») и не связывают их с аналитикой, сделки на этих этапах выпадают из отчёта. Зависшие на этих этапах деньги просто не попадают в расчёт окупаемости.

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

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

Учтём разные модели атрибуции 

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

Всего таких моделей в Директе и Метрике четыре:

• Последний переход

• Последний значимый кросс‑девайс

• Первый кросс‑девайс переход

• Автоматическая атрибуция

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

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

Как атрибуция в Директе влияет на бюджет и автостратегии

В Яндекс Директе от выбора модели напрямую зависит расход денег.

Кампании с оплатой за конверсии. Если кампания настроена на оплату за результат, модель атрибуции определяет, за какие конверсии спишутся деньги. При «Последнем переходе» вы платите, только если последним визитом перед конверсией был переход из Директа. При «Последнем значимом кросс‑девайс» вы платите за визиты, в которых конверсия совершена после перехода по объявлению из Директа и до следующего значимого события (например, перехода из соцсети или почтовой рассылки).

Обучение алгоритмов в ЕПК. В Единой перфоманс‑кампании, где текстово‑графические объявления заменяются комбинаторными, нейросеть обучается предсказывать вероятность конверсии на основе статистики выбранной модели.

Определим, с какими проблемами придётся смириться

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

• Использование блокировщиков рекламы, запрет на использование cookie и визиты через режим инкогнито

• Перерывы между визитами свыше того количества дней, которое поддерживает ваша модель атрибуции

• Офлайн‑обращения клиентов с номеров телефонов, не связанных с исходным визитом

• Необходимость ждать созревания сделок в нишах с длинным циклом продаж

Всё прочее исправляется либо настройкой системы, либо введением грамотных регламентов.

Что делать

Возьмите работу под системный контроль. Рассказываем, как сделать это без микроменеджмента.

1. Закрепите одного ответственного за целостность данных. За рекламу отвечает маркетолог, за сайт — разработчик, за воронку — РОП, а за сквозную аналитику — никто. У всех всё работает штатно, а кто должен отвечать в случае проблем, неясно.

В компании должен быть один владелец сквозной цепочки. Оптимально сделать им штатного аналитика или ведущего маркетолога. Его задача — контролировать прохождение данных через стыки всех систем и валидировать любые технические изменения.

2. Зафиксируйте словарь бизнес‑метрик. До того как формировать отчёты, отдел маркетинга, отдел продаж и финотдел должны зафиксировать терминологию на бумаге:

• Что признаётся обращением, что — лидом, а что — квалифицированным лидом

• Какая дата считается точкой отсчёта: дата клика по рекламе, дата создания лида или дата фактического поступления денег на расчётный счёт

• Какая выручка идёт в сквозной расчёт: валовая (по чеку) или чистая маржа за вычетом себестоимости, возвратов и логистики

• Какая модель атрибуции используется как базовая для подведения финансовых итогов

3. Введите регламент обязательных тестов. Любое изменение на сайте (смена вёрстки, добавление нового квиза, переезд на новый хостинг) или обновление полей в CRM должно сопровождаться обязательным контрольным прогоном:

1. Тестовый переход по ссылке с UTM‑метками.

2. Заполнение формы или звонок на динамический номер.

3. Проверка — создалась ли сделка в CRM, прикрепился ли к ней ClientID и правильный источник.

4. Проверка — появилось ли событие в отчёте веб‑аналитики.

4. Назначьте разным проверкам разную периодичность. Еженедельно стоит мониторить долю неопределённого трафика («Прямые заходы», «Не определено») и резкие отклонения в конверсиях посадочных страниц. Ежемесячно стоит проводить детальную сверку данных между рекламными расходами, отчётами Метрики и фактической выручкой по банковской выписке по созревшим когортам.

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

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

Чек‑лист: 6 вопросов, с которыми стоит прийти к команде

1. «Каков средний цикл закрытия сделки в нашем бизнесе?» Достаточно ли созрели данные за прошлый месяц, чтобы делать выводы о реальном ROMI и принимать решения об оптимизации кампаний?

2. «По какой модели атрибуции оцениваем окупаемость каналов?» Как учитывается влияние переходов между девайсами? В каких сценариях наша модель может привести к тому, что мы не учтём прибыль от каких‑то сделок?

3. «Покажите путь одной тестовой заявки прямо сейчас» — от клика по ссылке с метками до сделки в CRM. Все ли поля (ClientID, yclid, UTM‑метки) заполняются корректно?

4. «Какова текущая доля обращений с неопределённым источником и как она менялась?» Если она резко выросла, то где именно рвётся цепочка?

5. «Как технически учитываются возвраты, отмены и дубликаты?» Очищается ли финальный отчёт от фиктивной выручки и не задваиваются ли сделки при повторных звонках клиентов?

6. «Как мы проверяем разметку после обновлений сайта?» Кто проводит тесты после обновлений и кто отвечает за то, чтобы формы не потеряли скрытые поля?

Больше о диджитал‑маркетинге, рекламных инструментах и работе с аудиторией — в наших каналах в Telegram, во ВКонтакте и в MAX.