Реклама приводит посетителей, но аналитика считает не всех: как проверить данные

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

Сравнивайте события одного уровня

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

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

Атрибуция тоже различается: отчёт может отнести заказ к последнему платному переходу, первоначальному источнику или взаимодействию в пределах окна. Уточните модель и окно каждого отчёта. Google перечисляет причины расхождения кликов и сеансов: задержка загрузки тега, фильтрация кликов, повторные визиты (разбор расхождений Google Analytics). Сверяйте один и тот же период после того, как данные успели обработаться; оперативные отчёты и рекламные кабинеты могут обновляться с задержкой.

Клик, визит, заявка и оплата относятся к разным системам и определениям — сравнивайте соседние этапы.

Проверьте путь рекламной метки до страницы

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

Если оформление или корзина находятся на другом домене, проверьте настройку измерения между доменами и сам переход. Сохранение UTM само по себе не объединяет пользователя между доменами: это отдельная настройка связки измерения. В Google Analytics она передаёт специальный параметр между доменами; конкретные настройки зависят от платформы (справка Google о междоменном отслеживании). Наличие двух разных счётчиков на посадочной и форме, фильтр внутреннего трафика, исключённый реферер или разные настройки согласия тоже могут объяснить, почему этапы не сходятся. Проверьте ресурс, поток или счётчик, период, сегмент и фильтры отчёта.

Убедитесь, что тег действительно сработал

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

Для контрольной проверки используйте обычное окно браузера, разрешите аналитику через штатный интерфейс согласия и откройте DevTools. В панели Network проверьте, загружается ли файл тега и уходит ли запрос события при просмотре страницы или нажатии кнопки. В консоли обратите внимание на ошибки. В Google Analytics используйте DebugView, Tag Assistant и инструменты разработчика для тестового события; в Яндекс Метрике — отладку целей и проверку счётчика. Названия и доступность режимов зависят от конфигурации. Не публикуйте в скриншотах и URL тестовые контактные данные.

Если тег срабатывает в отладке, но данных нет в нужном отчёте, проверьте идентификатор счётчика и фильтры, а затем повторите тест после обработки данных. Для отдельных посетителей данные могут отсутствовать из-за блокировок, отключённого JavaScript или непринятого согласия. Клиентская аналитика по своей природе не обязана учитывать каждого посетителя.

Идите от конечной страницы по цепочке: метка, загрузка тега, сохранённая заявка, событие успеха и запись в CRM.

Считайте успешную заявку, а не нажатие кнопки

Клик по кнопке «Отправить» ещё не означает, что форма прошла проверку и сервер создал обращение. Свяжите событие с подтверждённым результатом: сервер принял форму и создал запись с внутренним ID. Если событие отправляется при нажатии, пользователь может ошибиться в поле, не пройти проверку, потерять соединение или получить серверную ошибку — аналитика засчитает конверсию, а заявки в системе не будет.

И обратная ситуация: заявка сохранена, но тег не выполнился из-за ошибки на странице подтверждения или пользователь закрыл вкладку слишком быстро. Страница «Спасибо» сама по себе не доказывает ни сохранение обращения, ни тем более оплату. Проверьте в системе обработки заявок, что тестовая запись создана и доставлена ответственному.

Дубли возникают при обновлении страницы подтверждения, повторном срабатывании обработчика в SPA, нескольких установленных тегах или одновременной автоматической и ручной отправке события. Используйте устойчивый уникальный ID заявки или заказа и предусмотрите идемпотентность на стороне системы обработки: повторная отправка не должна создавать новый заказ. Правила обработки повторов различаются: наличие параметра с ID не означает одинакового поведения во всех счётчиках. В GA4 для веб-потоков документирована дедупликация событий покупки одного пользователя с одним уникальным transaction_id; пустой ID недопустим; это правило нельзя автоматически переносить на Метрику или иную платформу (справка GA4 об ID транзакции).

Не помещайте email и телефоны в URL, параметры события или передаваемые данные аналитики. Проверьте также параметры строки запроса: посетители иногда сами вводят контакт в поиске или поле формы, а затем адрес с параметрами попадает в аналитику. Не передавайте туда содержимое полей; исключайте такие значения до отправки и не сохраняйте их в журнале тестов.

Сверьте аналитику с заказами по правилам бизнеса

Для продаж отправная точка — система заказов или CRM, где видны ID, даты создания и оплаты, статусы, отмены и возвраты. Сопоставляйте не только итоги, но и период, валюту, часовой пояс, тип заказа и определение «оплачено». Отдельно посмотрите заказы, созданные в периоде, но оплаченные или отменённые позже. Покупка и возврат могут отражаться отдельными событиями; не исходите из того, что отмена автоматически удалит событие покупки из аналитики. Для дедупликации используйте ID заказа; не складывайте в одну конверсию тестовые, отменённые и возвращённые заказы, если отчёт должен показывать оплаченные продажи.

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

В отчёте фиксируйте этап, источник данных и правило статуса, а не только итоговую цифру.

Короткий контрольный список

1. Запишите, что сравниваете: клики, визиты, успешные формы или оплаченные заказы.
2. Сведите часовые пояса, даты, окна атрибуции и выбранные счётчики; проверьте фильтры.
3. Пройдите тестовый рекламный маршрут с согласием и проверьте сохранность метки после редиректа и смены домена.
4. Убедитесь через DevTools и отладчик системы, что тег загрузился и отправил нужное событие.
5. Проверьте серверный ответ формы и запись в CRM; отделите успешную отправку от нажатия и страницы подтверждения.
6. Найдите дубли и сверяйте покупки по уникальному ID с учётом статусов, отмен и возвратов.
7. Повторите проверку после обновления данных и задокументируйте ожидаемые различия между системами.

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

Расходы на рекламу растут, а источник разницы неясен? SolverWeb может проверить путь от рекламной ссылки до события, формы и записи заказа, а также помочь настроить проверяемую сверку показателей. Связаться с SolverWeb.