Маркетолог, аналитик, ex-CMO — фокус на экосистеме Google (Ads, Merchant Center, GA4, GTM). Google Partner. 150+ проектов, 100+ положительных отзывов на Freelancehunt, 12+ стран.
- Работаю напрямую, без менеджеров и субподрядчиков
- Считаю результат в продажах, а не в конверсиях кабинета
- Максимальная экспертиза в экосистеме Google — вместо «и контекст, и таргет, и SEO»
Очень деликатный вопрос, с которым сталкивался каждый: почему продажи не совпадают с рекламным кабинетом, с аналитикой и с фактическими данными по CRM? Тут вопрос не только в событиях продаж — вопрос в трекинге событий в целом.
Содержание статьи
Сразу дисклеймер: в этой статье не рассматриваем историю с долгой загрузкой страницы — там причина понятна: страница грузится долго, скрипты не успевают сработать, события не трекаются. Это отдельная тема.
Разберём на реальном примере, в реальном времени, как блокировщики рекламы (на примере uBlock) и режим инкогнито в некоторых браузерах запрещают трекать те или иные события.
Предыстория
Создал определённый скрипт для собственных нужд. В процессе тестирования заметил: не со всех устройств информация, которая должна была передаваться этим скриптом, доходит до системы. Начал искать причину глубже — и сработал известный факт: блокировщики рекламы и некоторые браузеры в режиме инкогнито запрещают работу трекеров на сайте.
Инструменты для теста
- Тестовый сайт с установленным скриптом
- Консоль браузера
- Telegram-бот, который получает информацию от скрипта при срабатывании триггера на сайте
Два метода проверки: через бот в реальном времени и через консоль браузера напрямую.
Тест первый: браузер без блокировщиков
Обновляю страницу — триггер стоит на загрузку страницы. Переходим в бот — информация передалась: событие привязано к событию уровня dataLayer, и всё сработало.
Проверяем через консоль команду вызова dataLayer — видим, что данные там есть, всё нормально. Проверяем, видит ли система сам Google Tag Manager — да, видит, определённый объект GTM загрузился в этом браузере.
Ремарка: в этом браузере нет никаких блокировщиков — всё чисто. Для контроля отправляю ещё одно событие повторным обновлением страницы — триггер сработал, информация снова передалась в бот. Всё работает корректно.
Тест второй: браузер с блокировщиком рекламы uBlock
Обновляю страницу в браузере с uBlock. Ждём. Переходим в бот — и ничего нет. Событие не сработало и не передалось.
Вызываем dataLayer через консоль в этом браузере — а в нём ничего нет. Сравниваем код dataLayer в обоих браузерах — они существенно отличаются: в браузере без блокировщика событий заметно больше, в браузере с блокировщиком события попросту отсутствуют.
Ключевая мысль. Блокировщик рекламы заблокировал загрузку самого скрипта Google Tag Manager. Всё, что находится в GTM, просто не работает — все трекеры, все события, которые вы передаёте, технически срабатывают на сайте, но не передаются в систему аналитики, потому что заблокирован главный скрипт, отвечающий за загрузку GTM.
Второй метод проверки — функция, которая определяет наличие GTM в браузере. В браузере с блокировщиком она возвращает undefined — то есть GTM не видит. В браузере без блокировщика та же функция возвращает полноценный объект — GTM зафиксирован и работает.
Итог по этой причине: в браузере без блокировщика GTM есть, зафиксирован, работает. В браузере с блокировщиком — нет, не зафиксирован, не работает.
Вторая причина: режим инкогнито
Тот же тест, только в мобильном Safari в режиме инкогнито. Подгружаю сайт — ничего не происходит. Safari + режим инкогнито блокирует трекеры так же, как блокировщик рекламы.
Тестировал несколько комбинаций — Chrome, Chrome инкогнито, Firefox, Firefox инкогнито. В разных вариантах то срабатывало, то нет — стабильной закономерности нет.
Насколько это массовое влияние
Нет никакой корреляции между конкретным проектом и процентом потерянных данных. Где-то может не доходить 10% данных, где-то 20%. На небольших объёмах статистики бывают случаи, когда погрешность превышает даже 50%.
Всё зависит от конкретной аудитории проекта и того, какими средствами (антидетект-браузеры, блокировщики) она пользуется, чтобы избежать трекинга взаимодействия с сайтом.
Эта история довольно распространена — вы точно видели её на практике: когда пользуетесь блокировщиком рекламы, переходите на сайт, и сайт (особенно тот, что отдаёт бесплатный контент) просит отключить блокировщик. Во-первых, чтобы показать рекламные блоки, встроенные на сайте. Во-вторых, чтобы иметь возможность трекать взаимодействия и метрики пользователя.
Вывод
В следующий раз, когда клиент спросит, почему данные из аналитики или рекламного кабинета не совпадают с фактическими данными в CRM, — можно показать именно такой тест. При условии, что трекинг у вас настроен и протестирован корректно и вы в этом уверены на 100%. О том, как построить систему, показывающую реальную картину вместо цифр из кабинета, писал отдельно в статье про сквозную аналитику.
Потеря части данных из-за блокировщиков и режима инкогнито — не ошибка настройки, а объективное техническое ограничение, с которым сталкивается любой сайт независимо от качества трекинга. Похожее расхождение между кабинетом и реальностью разбирал и в кейсе про сеть металлобаз — только там причина была в неучтённых источниках конверсий, а не в блокировщиках.
Один из самых простых способов вернуть часть данных, которые режут блокировщики, — Google Tag Gateway. Пошаговая настройка через GTM и Cloudflare — в статье «Google Tag Gateway: +14% данных за 2 минуты».
Но даже полные данные ничего не дадут, если сами события настроены криво. Типичные ошибки в Google Tag Manager — в статье «Трекинг за $750 в месяц».
Как direct и потерянная атрибуция выглядят на реальных цифрах по каналам — в разборе 9 171 лида и 425 сделок из Google Ads, SEO, Meta и TikTok.
Ещё одна причина потери данных — отсутствующий или неправильно настроенный режим согласия для ЕЭЗ и Великобритании. Подробнее — настройка Consent Mode v2.
Чтобы источники трафика не терялись в аналитике, размечайте ссылки, например через бесплатный инструмент генератор UTM-меток.
Как увидеть в GA4, сколько транзакций теряется, — смотрите 11 отчётов в GA4, которые я использую в работе.
Где меня найти
Пишите в Telegram или на почту — отвечаю быстро. Telegram-канал и YouTube — для тех, кто хочет увидеть реальные кейсы перед обращением и понять мой подход к работе.