GTM: аудит коректності кастомних подій

Заявки у звітах виросли втричі, а реальних дзвінків від клієнтів немає? Чи, можливо, цільова подія purchase реєструє покупки, яких ніхто не робив? Коли ви зіткнулися з подібними розбіжностями у звітах під час під час перевірки відстеження рекламних конверсій через Google Tag Manager (GTM), вам потрібен аудит кастомних подій.

У цьому покроковому гайді розберу, як початківцям правильно перевірити налаштування GTM і навести лад у даних.

Що таке кастомна подія і навіщо вона потрібна

Подія (event) — це сигнал про дію користувача на сайті: клік на кнопку, відправку форми, додавання товару в кошик або оформлення замовлення. Подією може бути кожна дія, котру ви визначите як цільову і налаштуєте її. 

Кастомна подія — це спеціально налаштована подія через Google Tag Manager під конкретну дію користувача, важливу для бізнесу. Браузер чи сайт не відстежують такі дії за замовчуванням. 

Без подій GTM і GA4 бачать лише те, що відвідувач зайшов на сайт і переглянув сторінки. Але не бачать, чи зателефонував він, чи заповнив форму або купив товар. Саме кастомні події «перекладають» поведінку користувача на мову, зрозумілу аналітиці й рекламним системам.

Для PPC-фахівця події потрібні насамперед для трьох речей:

1. Фіксувати цільові дії як конверсії в Google Ads і Meta Ads.
2. Бачити в GA4 повну картину поведінки користувача — не тільки візити, а й реальні результати.
3. Давати рекламним алгоритмам якісні дані для навчання і оптимізації ставок.

Якщо подія спрацьовує некоректно, весь ланцюжок аналітики й реклами дає збій. Це означає злиті бюджети, хибні висновки й рекламу, яка оптимізується «в нікуди».

Коли потрібен аудит

Проводити аудит варто в таких ситуаціях: 

• перед запуском нової рекламної кампанії, що спирається на конверсії;
• після  змін на сайті (новий дизайн форми, редизайн кошика, зміна CMS);
• якщо цифри в GA4 і в CRM суттєво відрізняються;
• якщо показники різко просідають;
• регулярно раз на квартал — як планова задача для перевірки акаунта, навіть якщо все працює без видимих збоїв.

Підготовка до аудиту

Крок 0. Підготовка

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

1. Чіткий список подій. Перелік цільових дій зазвичай міститься в ТЗ або в списку конверсій GA4/Google Ads (наприклад: form_submit, add_to_cart, purchase, phone_click, generate_lead, order_created).
2. Необхідний рівень доступу до GTM. Для повноцінного тестування змін у режимі Preview (Tag Assistant) прав лише на перегляд (Read) буде недостатньо. Потрібен рівень Edit або Approve, щоб створювати робочі області й перевіряти їх до публікації. 
3. Доступ до GA4. Найбільше для цієї задачі знадобляться звіти Realtime та DebugView.
4. Розширення Google Tag Assistant. Офіційний інструмент Google для перевірки спрацьовування тегів у режимі реального часу.
   
   

Приклад списку подій:

Крок 1. Відкрийте GTM у режимі Preview (Debug mode)

Це головний інструмент для аудиту. Він дає змогу побачити всі події, відбулися на сторінці, зліва направо в хронологічному порядку: Container Loaded, DOM Ready, Window Loaded, а далі — ваші кастомні події типу form_submit.

Як запустити:

1. У правому верхньому куті робочої області GTM натисніть кнопку Preview (Попередній перегляд).

2. У вікні, що з’явиться, введіть URL сайту, який треба перевірити. Натисніть Connect (Підключитися).

3. Відкриється сайт у режимі тестування, а в новій вкладці або внизу з’явиться панель Tag Assistant з деталями всіх подій dataLayer.

Що перевіряти на цьому кроці:

1. Фактичне спрацьовування. Чи з’являється подія в списку, коли ви виконуєте дію (клік по кнопці, надсилання форми)? Відсутність події означає, що система не побачила вашу дію — через неналаштований тригер, dataLayer.push() у коді сайту або блокування скриптів розширеннями.
2. Відсутність дублювання. Чи фіксується подія один раз за одну дію? Повторне спрацьовування (коли за один клік вилітає 2–3 однакові події підряд) — одна з найпоширеніших помилок, яка штучно завищує конверсії в аналітиці. 

Крок 2. Перевірте тригер (Trigger)

Клікніть на подію в лівій панелі Tag Assistant. Вкладка Tags покаже, які теги спрацювали (Fired) або не спрацювали (Not Fired) на ній.

Типові помилки на цьому етапі:

1. Розбіжність у назві події. Тег очікує подію form_submit, а у dataLayer відправляється подія з іншою назвою. Пам’ятайте, що GTM чутливий до регістру й символів.
2. Невірно обраний тип тригера. Тригер налаштовано на клік по кнопці (Click Trigger), але фактично кнопка реалізована через <div> із JS-обробником, або ж ви вказали неточний ID/Class елемента. 
3. Занадто широке охоплення. Тригер спрацьовує на всіх сторінках замість конкретної (наприклад, забули умову «Page URL contains /thank-you»).

Крок 3. Перевірте змінні (Variables) і dataLayer

Недостатньо зафіксувати факт спрацьовування події, важливо перевірити, які саме дані вона передає. 

Як перевірити:

1. В інтерфейсі Tag Assistant потрібну подію у лівому меню і перейдіть на вкладку Data Layer.
2. Подивіться, які параметри прийшли: event, event_category, value, currency, transaction_id тощо.

На що звертати увагу:

• чи не пусті значення (value: undefined або "") там, де мають бути реальні дані;
• чи правильний формат (наприклад, value має бути числом, а не рядком із валютою);
• для eCommerce-подій — чи є масив items з товарами та чи не порожній він.

Якщо ви бачите змінну GTM зі значенням undefined, це майже завжди означає, що:

• або змінна дивиться не на той рівень dataLayer (наприклад, Data Layer Variable Name написаний із помилкою);
• або подія відправляється в dataLayer до того, як GTM встиг завантажити змінну.

Крок 4. Перевірте в GA4 DebugView

Успішне спрацьовування тегу в GTM Preview свідчить лише про те, що контейнер відправив сигнал. Але це не гарантує, що дані безперешкодно потрапили до Google Analytics 4 чи Google Ads.

Для перевірки доставки використовуйте інструмент DebugView у GA4.

Як перевірити:

1. Перейдіть у кабінет GA4: Адміністратор (Admin) → DebugView (у блоці Відображення даних / Data display). 
2. Активний режим Preview у GTM автоматично активує debug-режим і в GA4.
3. Виконайте цільову дію на сайті.
4. У DebugView з’явиться подія в режимі реального часу.

На що звернути увагу:

• чи з’явилася подія в стрічці;
• чи всі параметри передалися коректно;
• чи не дублюється подія (одна дія користувача = одна подія, а не дві–три).

Крок 5. Перевірте дублікати й «хибні спрацьовування»

Дублі найбільше псують статистику конверсій і бюджети в рекламі.

Як перевірити:

1. Виконайте цільову дію один раз і порахуйте кількість зафіксованих подій у Tag Assistant і GA4 DebugView. Співвідношення має бути 1:1.
2. Перезавантажте сторінку подяки (thank-you page) вручну через адресний рядок браузера. Подія purchase не має спрацьовувати повторно.
3. Поверніться на сторінку подяки за допомогою кнопки «Назад» у браузері. Подія теж не має дублюватись.

Найпоширеніші причини виникнення дублів:

• тег прив’язаний одночасно до двох тригерів;
• на сторінці подяки немає перевірки, чи це нове завантаження, а не оновлення сторінки;
• одна й та сама подія налаштована одразу у двох різних тегах (наприклад, і в GA4-тегу, і окремо в тегу для Google Ads Conversion).

Крок 6. Звірте з реальними даними бізнесу

Останній крок — зіставити цифри з вебаналітики з реальністю.

Що потрібно зіставити за останній тиждень/місяць: 

1. Ліди й заявки. Чи відповідає кількість подій generate_lead у GA4 кількості нових лідів, які фактично зафіксовані в CRM-системі? 
2. Трансакції. Чи збігається кількість подій purchase із кількістю виконаних замовлень в адмін-панелі вашого інтернет-магазину? 
3. Чи відповідає значення value в подіях purchase реальній сумі замовлень (без збою валют, без нулів)?

Особливості подій для різних ніш

Базові кроки аудиту універсальні для різних проєктів. Але важливі події і «типові пастки» в кожній ніші свої. Розгляну два ключові напрями. 

Ecommerce (інтернет-магазини)

На що звернути особливу увагу при аудиті: 

1. Перевіряйте, чи унікальні item_id / item_name для кожного товару — дублікати ID ламають звіти по товарах.
2. Значення value має передаватися числом з правильним роздільником (крапка, а не кома) і відповідати сумі замовлення з ПДВ / без ПДВ відповідно до ваших правил.
3. Масив items не повинен бути порожнім і має містити параметри quantity та price для кожного товару.
4. Перевірте, чи параметри coupon і discount не спотворюють підсумкове значення value (наприклад, чи не віднімається знижка двічі). 
5. Оновлення сторінки «Дякуємо за замовлення» не повинно генерувати повторну транзакцію. 

Які події та параметри критично важливі для eCommerce у GA4 

Лідогенерація / послуги (B2B, юридичні, ремонт, консалтинг)

На що звернути особливу увагу при аудиті: 

1. Якщо на сайті кілька форм, перевірте, що параметр form_id або form_name показує саме ту форму, яку заповнили, а не завжди одну й ту саму.
2. Переконайтесь, що подія фіксує тільки успішну відправку, а не кожен клік по кнопці «Надіслати», коли користувач припустився помилки.
3. При кліку на номер телефону (phone_click) перевіряйте формат переданих даних. Нормалізований вигляд (наприклад, +380…) необхідний для подальшої звірки з CRM і колтрекінгом. 
4. Якщо використовується завантаження олайн-конверсій offline або Enhanced Conversions, перевірте, що email / телефон передаються (в хешованому вигляді) і збігаються з тим, що потім вантажиться назад із CRM.

Швидкий чек-лист для аудиту

Висновки

1. Ніколи не вірте на слово, що подія налаштована. Перевіряйте все особисто через GTM Preview і GA4 DebugView. 
2. Дублікати подій — найчастіша і найдорожча помилка в PPC.
3. Порожні значення або undefined-параметри — сигнал про розсинхронізацію таймінгів або синтаксичну помилку.
4. Завжди звіряйте фінальні цифри із даними в CRM і продажами, а не тільки з GA4.
5. Робіть аудит регулярно, а не тільки при запуску.
   Витративши 30–40 хвилин на детальну перевірку зараз, ви заощадите клієнтський бюджет, вбережете власні нерви і забезпечите алгоритмам чисті дані для навчання кампаній.