Маркетолог, аналітик, 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 — для тих, хто хоче побачити реальні кейси перед зверненням та зрозуміти мій підхід в роботі.