Как понять, что реклама корректно отслеживается аналитикой?

Понять, что реклама корректно отслеживается, можно только через сверку «по цепочке»: клик → сессия → лид (форма/звонок/чат) → запись в CRM → попадание в отчёт. Если на любом этапе есть разрыв (редиректы, неверные UTM, потеря client_id, не настроены события, дубликаты/фильтры), часть заявок неизбежно «выпадает» из аналитики.

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

Как устроена логика и где чаще всего ломается

• Клик из рекламы должен принести параметры (UTM и/или авторазметку gclid/yclid) до конечной посадочной страницы.
• Сессия в аналитике фиксируется только если счётчик реально грузится (нет блокировщиков/ошибок, не мешает баннер согласия, страница не редиректит до загрузки).
• Конверсия должна быть отправлена корректно: событие/цель на «спасибо», на submit формы, на успешный ответ API, на клик по телефону и т.д. Ключевое — конверсия должна срабатывать после фактического успеха, а не просто на нажатие кнопки.
• Связка с CRM требует передачи идентификаторов (Client ID / User ID / click id) и нормализации источника. Иначе лид в CRM есть, но «источник» в отчёте будет Direct/None или «не определено».
• Сквозная аналитика ломается на дедупликации (заявка пришла и с формы, и из коллтрекинга), на неправильных правилах атрибуции и на фильтрах (боты, внутренний трафик, платёжные/переходы между доменами).

Проверка корректности: пошаговый чек-лист

1) Проверка клика и сохранности разметки

• Сделайте тестовый клик по каждому ключевому каналу (поиск/РСЯ/соцсети/партнёрки) и проверьте, что на конечной странице в URL присутствуют UTM и/или авторазметка (gclid/yclid) и они не пропадают после редиректов.
• Если есть промежуточные редиректы, трекеры, сокращатели, переходы http→https, www→без www — убедитесь, что параметры не «съедаются».
• Проверьте, что каноникал/серверные редиректы не ведут на URL без параметров.

2) Проверка загрузки счётчика и отсутствия блокировок

• Откройте посадочную с тестовой меткой и убедитесь, что счётчик аналитики реально отправляет хит (в режиме отладки/реального времени и в сетевых запросах браузера).
• Проверьте влияние баннера согласия: частая проблема — до согласия счётчик не грузится, а пользователь успевает оставить заявку.
• Сравните долю браузеров/устройств: если «потери» непропорционально высоки на iOS/Safari — вероятны ограничения по cookies/ITP и нужна корректная настройка first-party/серверной части.

3) Проверка конверсий (целей/событий) на фактический успех

• Для форм: конверсия должна срабатывать на успешный ответ сервера (200/успешный статус), а не на клик «Отправить». Иначе будут ложные конверсии и одновременно пропуски при ошибках.
• Если используется страница «Спасибо» — проверьте, что она открывается всегда и только после успешной отправки (без кэша/без повторного открытия).
• Для звонков/мессенджеров/чатов: убедитесь, что настроены корректные события (клик по телефону ≠ состоявшийся звонок). Для звонков нужен коллтрекинг с передачей факта звонка и, желательно, статуса/длительности.

4) Проверка связки «аналитика → CRM» и идентификаторов

• Проверьте, что в CRM у лида сохраняются UTM-поля и/или click id (gclid/yclid) и/или client_id/user_id. Без этого нормальная атрибуция продаж и заявок невозможна.
• Сопоставьте 20–30 реальных лидов из CRM с данными аналитики: у каждого должен быть вменяемый источник/кампания. Если много Direct/None — почти всегда теряется разметка или не прокидываются идентификаторы.
• Проверьте дедупликацию: один лид может приходить несколькими путями (форма + коллтрекинг + чат). Если правила объединения неверные, в отчётах будет либо недосчёт, либо раздутие.

5) Сверка цифр «сверху вниз»

• Сравните: клики в рекламных кабинетах → сессии/пользователи в аналитике → конверсии → лиды в CRM. Расхождения допустимы, но если лидов в CRM стабильно заметно больше, чем конверсий, — проблема в трекинге конверсий или загрузке счётчика.
• Разложите расхождение по каналам и по устройствам — это быстро покажет, где «дыра» (например, только мобильный трафик из соцсетей).

Что я рекомендую сделать команде прямо сейчас

1. Составить карту воронки трекинга: какие конверсии считаем, где они возникают, чем подтверждаются (страница/событие/серверный ответ/статус звонка), куда пишем (аналитика/CRM/BI).
2. Провести 10–15 тестовых лидов по основным каналам (с разными устройствами) и для каждого зафиксировать: URL входа, источник в аналитике, факт срабатывания цели, запись в CRM и заполненность UTM/click id.
3. Проверить редиректы и сохранность параметров на всех посадочных и промежуточных страницах, включая домены виджетов/форм, если они выносятся отдельно.
4. Довести цели до «успешного результата»: формы — от события успешной отправки, звонки — от факта звонка из коллтрекинга, заявки из чатов — от webhook/интеграции.
5. Если значимая доля трафика теряется из‑за ограничений браузеров/согласий — рассмотреть серверную отправку ключевых событий (server-side) и более устойчивую работу с first-party идентификаторами.

Типичные ошибки, из-за которых «пропадают» заявки

• UTM/авторазметка теряются на редиректе, в промежуточном трекере, при переходе между доменами.
• Цель висит на клике по кнопке, а не на успешной отправке (часть заявок не проходит, а часть считается ошибочно).
• Форма/виджет грузится с другого домена без корректного кросс-домена и прокидывания идентификаторов.
• Коллтрекинг есть, но не передаёт конверсии/источник в аналитику и/или лиды не матчатся с сессиями.
• Баннер согласия блокирует загрузку аналитики до согласия, а заявки уходят раньше.
• Нет единого ID пользователя/устройства, поэтому повторные визиты и многоканальные цепочки «рассыпаются».

Если напишете, какая у вас связка (GA4 или Метрика, есть ли GTM, какая CRM, есть ли коллтрекинг и чат), я подскажу, какие 3–5 проверок дадут максимум эффекта именно в вашей схеме.