Google Analytics 4 із коробки бачить лише перегляди сторінок — клік на кнопку «Замовити» чи відправку форми заявки він не фіксує без додаткового налаштування. Якщо ви проходите Google Tag Manager курс або розбираєтесь у темі самостійно, ця стаття покаже практично, як створити подію на клік, чому подія «клік по кнопці» обманює вас у випадку з формами і як натомість прив’язати конверсію до сторінки подяки. Матеріал розібраний на прикладі реального сайту, тож кожен крок можна одразу повторити у власному Google Tag Manager паралельно з читанням. Це базовий, але критичний навик для будь-якого практикуючого маркетолога — незалежно від того, який саме google tag manager курс чи формат навчання ви обрали.
Навіщо налаштовувати події в Google Tag Manager для GA4
Google Tag Manager потрібен для передачі кастомних подій у GA4, бо стандартна аналітика фіксує тільки перегляди сторінок і не бачить клік на кнопку, відправку форми чи прогрес воронки без окремо створеного тегу й тригера. Через GTM ви створюєте подію — наприклад, «замовити» — прив’язуєте її до конкретної дії відвідувача на сайті і передаєте у GA4 за ідентифікатором потоку даних із розділу «Адміністратор». Далі ці події можна перенести в рекламний кабінет Google Ads чи Meta Ads і оптимізувати кампанії саме на тих, хто клікнув кнопку замовлення чи дійшов до сторінки подяки, а не просто на весь трафік сайту. Без цього кроку рекламна система оптимізується на будь-який клік по оголошенню, включно з випадковими відвідувачами, які просто закрили сайт на першій секунді.
Практична цінність тут проста: без подій ви бачите загальну кількість відвідувачів, але не знаєте, скільки з них дійсно зробили цільову дію. Коли ж події налаштовані коректно, ви можете порівняти канали трафіку — скільки заявок прийшло з реклами в Facebook, скільки з Google, а скільки з органічного пошуку — і зрозуміти, який канал підсилювати бюджетом, а який вимикати. Саме тому це базовий скіл для будь-якого практикуючого маркетолога, незалежно від того, чи він таргетолог, чи PPC-спеціаліст, чи SMM-менеджер. Не дивно, що курси аналітика та роботи з подіями стабільно цікавлять і початківців, і фахівців, які вже запускають рекламу, але хочуть точніше розуміти, звідки насправді приходять заявки. Причому це стосується не лише PPC-напрямку: навіть таргетолог, який веде трафік із Meta Ads, без коректних подій в GTM бачить лише кількість кліків по оголошенню, а не реальні заявки, що прийшли з цього трафіку. Тому базові навички роботи з Google Tag Manager і GA4 сьогодні входять у мінімальний набір скілів практично для будь-якої ролі в перформанс-маркетингу — і саме тому курси аналітика останнім часом набирають популярність нарівні з курсами по запуску реклами.
Google Tag Manager курс на практиці: як створити подію на клік по кнопці
Якщо ви саме зараз проходите Google Tag Manager курс і хочете відпрацювати кожен крок на власному сайті — це найкращий формат навчання, бо помилки видно одразу в режимі Preview, а не через тиждень у звіті GA4. Будь-який Google Tag Manager курс, який вартий уваги, будує програму саме навколо такого практичного циклу: створили тег, перевірили в Preview, опублікували, порівняли з реальними заявками. Тому не варто обмежуватись переглядом одного відео — краще одразу відкрити свій контейнер GTM і повторювати кожен крок паралельно з поясненням. Навіть одна самостійно налаштована й перевірена подія дає більше практичного розуміння, ніж перегляд десяти чужих туторіалів без рук на клавіатурі.
Подію на клік створюють у розділі «Теги»: обираєте тип тегу «Google Аналітика: подія GA4», вставляєте ідентифікатор потоку з розділу «Адміністратор → Потоки даних» вашої аналітики і задаєте зрозумілу назву події, яка потім з’явиться у звітах GA4. Назва події — не формальність: якщо назвати подію абстрактно, у звіті буде незрозуміло, що саме вона означає, особливо коли зі статистикою працює не лише ви, а й підрядники чи клієнт. Тому краще одразу писати конкретно — «замовити_головна» замість просто «замовити», якщо на сайті є кілька схожих кнопок на різних сторінках. Така ж логіка іменування зберігається і в самому Google Ads, коли ви пізніше обираєте цю подію як ціль конверсії для кампанії — зрозуміла назва одразу підказує, з якої саме сторінки і кнопки прийшла заявка.
Ідентифікатор потоку даних копіюється один раз і використовується для всіх подій на цьому сайті — це той самий номер, який ви вставляли, коли підключали Google Analytics до Google Tag Manager на попередньому кроці налаштування. Помилка початківців — створювати новий тег без цього ідентифікатора або вставляти чужий ідентифікатор з іншого проєкту, через що подія технічно спрацьовує в GTM, але дані до вашої аналітики не доходять. Перевірити це можна одразу в режимі Preview, про який мова піде нижче. Взяти правильний ідентифікатор найпростіше прямо в GA4, у розділі «Адміністратор → Потоки даних», відкривши потрібний потік і скопіювавши значення без пробілів.
Тригер на клас кнопки: як точно відфільтрувати потрібний клік
Тригер «Клік — усі елементи» з умовою «Клік-Клас містить [назва класу кнопки]» дозволяє відфільтрувати саме потрібний клік із усіх кліків на сторінці: спочатку через інспектор браузера ви копіюєте технічний клас кнопки, а потім вставляєте його як умову в конфігурації тригера. Робити тригер на текст кнопки — погана ідея, бо текст легко змінюється: на сайті може бути кілька мовних версій («замовити», «buy», «заказать»), і тригер по тексту або пропустить клік, або спрацює там, де не треба. Клас кнопки, на відміну від тексту, зазвичай залишається однаковим у всіх мовних версіях сайту, бо він прописаний на рівні верстки, а не контенту. Саме тому досвідчені спеціалісти одразу закладають прив’язку до класу, а не до видимого напису на кнопці, навіть якщо на момент запуску сайт має лише одну мовну версію. Це невелика деталь, яка економить години переробки тригерів у майбутньому, коли на сайт додають англійську чи іншу локаль.
- Клікаєте правою кнопкою миші на потрібну кнопку і обираєте «Перевірити» — відкриється інспектор коду.
- Копіюєте значення класу кнопки без лапок — саме цей текст піде в умову тригера.
- У Google Tag Manager створюєте тригер «Клік — усі елементи», обираєте «Деякі кліки» і умову «Клік-Клас містить [ваш клас]».
- Прив’язуєте тригер до тегу події і зберігаєте — після цього подія спрацьовуватиме тільки на потрібному елементі.
Нюанс: клас кнопки іноді відрізняється від того, що ви бачите в редакторі сайту, бо конструктори сайтів додають технічні класи автоматично. Завжди перевіряйте реальний клас через інспектор браузера безпосередньо перед створенням тригера, а не орієнтуйтесь на назву з панелі редагування. Якщо конструктор сайту при кожному оновленні перегенеровує технічні класи, тригер краще прив’язувати до додаткового кастомного атрибута (наприклад, data-атрибута), який ви задаєте самостійно і який не зміниться після редизайну. Це рідкісна, але прикра причина, чому раніше робочий тег раптом перестає спрацьовувати без жодних змін у самому Google Tag Manager.
Чому подія «Клік по кнопці» не підходить для форм
Подія на клік по кнопці відправки форми фіксує сам клік, а не факт відправлення заявки, тож у звіті може з’явитися сто п’ятдесят «заявок» за день, хоча реально форму заповнили і надіслали лише десять. Це відбувається тому, що людина може натиснути кнопку «Відправити», але через незаповнене обов’язкове поле форма технічно не відправиться — а Google Tag Manager побачить лише клік і зафіксує подію як успішну. Для клієнта чи керівника такий звіт виглядає катастрофічно оптимістично: ви показуєте сто п’ятдесят заявок, а реальний відділ продажів отримав лише десять дзвінків, і довіра до аналітики падає одразу. Найпростіший спосіб перевірити, чи ваша поточна подія рахує саме кліки, а не реальні відправки — порівняти кількість подій за день із кількістю реальних дзвінків або листів у CRM.
Подія «Клік по кнопці форми» рахує кожен клік на кнопку «Відправити», незалежно від того, чи форма заповнена коректно і чи вона реально дійшла до сервера. Число подій у звіті буде значно вищим за фактичну кількість заявок, і різницю між ними ви побачите тільки тоді, коли порівняєте дані з CRM або відділом продажів. Найгірше, що ця розбіжність зазвичай виявляється не одразу, а через тиждень-два, коли на основі завищених цифр вже прийняті рішення про бюджет чи масштабування кампанії. У результаті доводиться відкочувати рішення назад і пояснювати клієнту, чому реальні цифри виявились суттєво нижчими за звітні.
Подія на перегляд сторінки подяки спрацьовує лише тоді, коли форма реально відправлена і відбулась переадресація на окрему URL-адресу. Це майже гарантує, що кожна зафіксована подія відповідає реальній заявці, бо потрапити на сторінку подяки без успішної відправки форми технічно неможливо. Різниця з CRM у такому випадку зазвичай мінімальна — максимум кілька заявок за рахунок технічних збоїв мережі, а не системної похибки трекінгу. Саме тому в звітах для клієнта варто орієнтуватись саме на цю подію, а не на клік по кнопці, навіть якщо цифра виглядає скромніше.
Подія на сторінку подяки: найточніший спосіб відстежити заявку
Подію на сторінку подяки налаштовують тригером «Перегляд сторінки» з умовою «Page URL містить [частина адреси сторінки подяки]» — такий тригер спрацьовує, тільки коли відвідувач реально потрапив на цю сторінку після успішної відправки форми. Для цього спочатку створюють окрему сторінку (наприклад, з текстом «Дякуємо за реєстрацію»), налаштовують на формі переадресацію саме на неї, а потім у Google Tag Manager додають новий тег події GA4 з тригером на перегляд цієї URL-адреси. Важливо, щоб ця сторінка не індексувалась у пошуку і не мала прямих переходів з меню сайту — інакше випадковий відвідувач, який просто зайшов на неї напряму, теж потрапить у статистику заявок. Найпростіший спосіб убезпечитись — додати на сторінку тег noindex і не додавати посилання на неї в жодне навігаційне меню чи сайтмап.
Умову краще ставити як «містить», а не «дорівнює всій адресі» — якщо на сайті є кілька мовних версій, кожна матиме свій варіант URL (наприклад, з префіксом /en/), і жорстка умова «дорівнює» просто не спрацює для інших мов. Умова «містить» із загальним фрагментом адреси працює однаково для всіх версій сторінки. Те саме стосується UTM-міток чи інших параметрів у кінці URL, які можуть додаватись автоматично рекламним кабінетом: якщо умова жорстко прописана «дорівнює», зайвий параметр у адресі теж зіб’є спрацювання тригера. Тому фрагмент для умови «містить» варто брати максимально коротким і унікальним — саме ту частину шляху, яка точно не зміниться незалежно від параметрів.
Той самий принцип працює і для лендінгів, зібраних через квіз: сторінка подяки після завершення квізу — така ж кінцева точка воронки, і подію на неї налаштовують у Google Tag Manager абсолютно тим самим тригером «Перегляд сторінки». Різниця лише в тому, що квіз перед фінальною сторінкою збирає ще й проміжні відповіді користувача, тому додатково варто розглянути окремі події на кожен крок проходження квізу, а не тільки на фінал. Це дає ширшу картину — де саме користувачі найчастіше зупиняються, не дійшовши до заявки, а не лише скільки з них дійшло до кінця. Такий поетапний трекінг особливо корисний, коли квіз довгий і потрібно зрозуміти, на якому саме питанні відвідувачі втрачають інтерес.
Як перевірити, що події працюють коректно (Preview-режим)
Перевірку роблять через кнопку «Попередній перегляд» у робочій області Google Tag Manager: ви вводите адресу сайту, підключаєтесь до нього і бачите панель з двома списками — теги, які спрацювали, і теги, які не спрацювали в кожному конкретному кліку чи переході. Якщо після кліку на кнопку потрібна подія з’явилась у списку «спрацювали», а її параметри (ідентифікатор потоку, назва) виглядають правильно — тег налаштований коректно і можна публікувати зміни на сайт. Якщо ж подія не з’явилась зовсім або з’явилась з порожніми параметрами — причина найчастіше в неправильному тригері (клас кнопки скопійовано з помилкою) або в переплутаному ідентифікаторі потоку даних. Preview-режим варто тримати відкритим протягом усього тестування, а не перевіряти постфактум уже після публікації змін на живому сайті.
- Внесені зміни опубліковано в Google Tag Manager (кнопка «Відправити»)
- Відкрито режим «Попередній перегляд» і підключено адресу сайту
- Клік на потрібну кнопку викликає подію у списку «теги, що спрацювали»
- Назва події та ідентифікатор потоку в тегу відповідають потрібним
- Подія на сторінку подяки перевірена окремою реальною відправкою форми
Скільки чекати дані в GA4 і як не обіцяти клієнту неможливе
Нові події з’являються в звітах GA4 у розділі «Конверсії» не одразу — потрібно від 24 до 48 годин після публікації змін у Google Tag Manager, тож обіцяти клієнту «повний звіт по заявках вже сьогодні» технічно некоректно. Це важливо проговорювати ще на етапі домовленостей: якщо клієнт чекає готову статистику наступного дня після старту робіт, а події ще навіть не встигли з’явитись в аналітиці, довіра до підрядника падає без жодної його провини — просто через нереалістичний дедлайн. Затримка стосується саме позначки події як «конверсія» у звітах — сама подія технічно фіксується одразу, просто вона ще не потрапила до потрібного розділу статистики. Це варто пояснити клієнту окремо, щоб він не думав, що аналітика взагалі не працює перші два дні.
Правило команди: на повне налаштування аналітики й тегменеджера варто закладати 3–4 дні — день-два на створення і тестування подій, плюс пів дня на очікування, коли дані стабільно з’являться в GA4. Заявляти клієнту готовність «сьогодні ж» — ризик пообіцяти те, що фізично неможливо перевірити раніше строку. Такий буфер також страхує від несподіванок, коли перше налаштування виявляється некоректним і доводиться перезапускати тестування з нуля. Краще закласти зайвий день у план, ніж потім терміново виправляти тег під тиском дедлайну, який ніколи не був реалістичним.
Прискорити появу даних трохи можна, якщо протягом дня періодично самостійно проходити тестовий шлях — клікати на кнопку, заповнювати форму, доходити до сторінки подяки. Це не скасовує технічну затримку в 24–48 годин, але дає більше тестових спрацювань події, за якими простіше переконатись, що налаштування стабільне, а не спрацювало один раз випадково. Кілька повторних тестових проходів також допомагають одразу побачити, чи не дублюється подія при повторному кліку чи оновленні сторінки — таку помилку складніше помітити з першого разу. Якщо подія спрацьовує двічі на один клік, статистика знову виявиться завищеною, хоч і не так драматично, як у випадку з подією на клік по кнопці форми.
Якщо ви хочете розібрати весь ланцюжок від першого тегу до передачі подій у рекламний кабінет на практиці з наставником — саме такий формат дає повноцінний Google Analytics курс, де кожен крок відпрацьовується на реальному сайті, а не лише переглядається у відео. Це особливо цінно на етапі, коли самостійні спроби налаштувати подію не спрацьовують і незрозуміло, в чому саме помилка — наставник підказує конкретний крок замість того, щоб гуглити відповідь годинами. Такий формат навчання скорочує шлях від «дивлюсь відео» до «мій GTM реально працює коректно» у кілька разів. Це те, чим повноцінний курс відрізняється від розрізнених статей і відео в інтернеті — послідовність і зворотний зв’язок на кожному кроці.
Що робити з подіями далі — передача в рекламний кабінет
Після того як події стабільно фіксуються в GA4, їх переносять у рекламний кабінет Google Ads для оптимізації кампаній саме на цільову дію — клік «Замовити» чи заявку, а не просто на трафік сайту; аналогічний принцип працює і в Meta Ads, де роль такого ж механізму виконує Facebook Pixel. Логіка однакова для обох платформ: рекламна система бачить, хто з відвідувачів дійшов до потрібної дії, і починає показувати оголошення схожій аудиторії частіше, ніж просто випадковим відвідувачам сайту. Чим точніше налаштована подія-конверсія, тим швидше алгоритм навчається і тим дешевше в підсумку обходиться кожна нова заявка. Це головна причина, чому досвідчені PPC-спеціалісти завжди перевіряють якість подій ще до запуску масштабної кампанії, а не покладаються на дефолтні налаштування рекламного кабінету.
Для тих, хто працює конкретно з контекстною рекламою, наступний логічний крок — курс Google Ads, де події з GTM використовують як цілі оптимізації кампаній Performance Max чи пошукових оголошень. Без коректно переданих подій із Google Tag Manager навіть найкраще написані оголошення оптимізуватимуться наосліп, орієнтуючись лише на кліки, а не на реальний результат. Такий перехід від «просто трафік» до «трафік, що конвертується» — це те, чим відрізняється практикуючий PPC-спеціаліст від людини, яка просто вміє натиснути кнопку «Запустити кампанію». Курси контекстної реклами зазвичай саме на цьому етапі і показують, як зв’язати події з GTM з цілями кампаній в Google Ads. Якщо ви шукаєте формат, де ці навички відпрацьовуються послідовно — від першого тегу до готової кампанії з оптимізацією на заявку — саме такий google ads курс дає повну картину, а не окремі розрізнені лайфхаки з різних джерел.
Сайт і GA4
Аналітика підключена до сайту, потік даних створено, ідентифікатор потоку скопійовано з розділу «Адміністратор».
↳ Виконується один раз на проєкт
Google Tag Manager підключено
Контейнер GTM встановлено на сайт, аналітика підключена як базовий тег на всіх сторінках.
↳ Базова активація перед подіями
Подія «Клік» на кнопку
Тригер по класу кнопки, тег GA4-події з ідентифікатором потоку і зрозумілою назвою події.
↳ Перевіряється через Preview
Подія на сторінку подяки
Окрема сторінка, переадресація з форми, тригер «Перегляд сторінки» з умовою «URL містить».
↳ Найточніший спосіб рахувати заявки
Передача в рекламний кабінет
Події з GA4 підключаються як цілі в Google Ads, аналогічно — конверсії через Facebook Pixel у Meta Ads.
↳ Через 24–48 годин після старту подій
Головне: точність вашої аналітики залежить не від кількості налаштованих подій, а від того, наскільки чітко кожна подія відповідає реальній дії відвідувача. Подія на сторінку подяки завжди точніша за подію на клік — тримайте це правило в голові, коли вирішуєте, який тригер обрати для конкретної форми на сайті.
Якщо ви ще не пробували повторити ці кроки на своєму сайті — саме зараз найкращий момент відкрити Google Tag Manager і створити першу подію на клік, поки деталі з відео ще свіжі в пам’яті. Розібратись у логіці на курсі Google Ads – Media Buyer буде значно швидше, ніж методом спроб і помилок. Кожна наступна подія даватиметься легше, бо принцип «тег + тригер + перевірка в Preview» повторюється однаково для будь-якої дії на сайті. Головне — почати з малого і не намагатись одразу охопити всі можливі кнопки й форми на сайті.
Часті запитання
Скільки чекати, поки нова подія з Google Tag Manager з’явиться в GA4?
Зазвичай від 24 до 48 годин після публікації змін у Google Tag Manager. Раніше цього терміну подія може не відображатись у звітах GA4, навіть якщо технічно вона спрацьовує коректно.
Чому подія «клік по кнопці» не годиться для трекінгу форм?
Бо вона фіксує сам клік на кнопку «Відправити», а не факт успішної відправки форми. Якщо обов’язкові поля не заповнені, форма технічно не відправляється, але подія все одно рахується як заявка.
Чому краще налаштовувати тригер по класу кнопки, а не по тексту?
Текст кнопки легко змінюється і відрізняється в мовних версіях сайту, тож тригер по тексту може пропустити клік. Клас кнопки — стабільніший технічний ідентифікатор, який не залежить від мови чи форматування напису.
Чи потрібна платна підписка сайт-конструктора для налаштування сторінки подяки?
Ні, створення окремої сторінки і налаштування переадресації з форми на неї доступне навіть у безкоштовній версії більшості конструкторів сайтів. Платна підписка потрібна лише для деяких додаткових функцій, як-от переадресація на зовнішній платіжний сервіс.
Отримати →