Тригери Google Tag Manager: як налаштувати All Pages

Google Tag Manager допомагає керувати аналітичними тегами на сайті без постійної зміни вихідного коду. Через нього можна відстежувати перегляди сторінок, натискання кнопок, відправлення форм та інші дії відвідувачів. Але, щоб дані почали надходити в систему аналітики, необхідно визначити умови запуску кожного тега.

За ці умови відповідають тригери. Вони реагують на події сайту та перевіряють, чи потрібно запускати пов'язаний із ними тег. Наприклад, один тригер може працювати під час перегляду будь-якої сторінки, інший – тільки після натискання кнопки замовлення, а третій – після успішного надсилання заявки.

Розберемо основні типи тригерів Google Tag Manager, налаштування All Pages, роботу з кліками, формами та користувацькими подіями. Окремо розглянемо перевірку даних у GTM та Google Analytics 4, щоб аналітика фіксувала саме ті дії, які потрібні для оцінки роботи сайту.

Що таке тригер у Google Tag Manager?

Тригер Google Tag Manager – це правило, яке визначає, за яких умов повинен запускатися тег. Він відстежує події у браузері: завантаження сторінки, натискання посилання, взаємодію з формою, прокручування документа або поява елемента в області перегляду.

Коли відбувається відповідна подія, GTM перевіряє налаштування тригера. Якщо умови виконані, пов'язаний з ним тег отримує команду для запуску. Один тригер можна використовувати для кількох тегів, а до одного тегу можна підключати кілька тригерів.

Наприклад, інтернет-магазину потрібно дізнатися, скільки відвідувачів натиснули кнопку «Купити». Для цього створюють тригер кліка, вказують потрібний елемент і пов'язують правило з тегом події Google Analytics 4. Після налаштування кожен потрібний клік може передаватися в аналітику.

При цьому необхідно враховувати обмеження відстеження. Натискання кнопки ще не підтверджує покупку, а подія перегляду сторінки не означає, що відвідувач прочитав її вміст. Тому тип тригера вибирають з урахуванням дії, яку дійсно потрібно виміряти.

Як пов'язані тег, тригер, подія та змінна?

Для розуміння роботи GTM достатньо розібратися у чотирьох основних компонентах. Вони беруть участь в одній послідовності, але кожен виконує своє завдання.

Допустимо, відвідувач натискає кнопку зворотного дзвінка. Google Tag Manager отримує подію кліка, перевіряє ідентифікатор елемента та порівнює його з умовою тригера. При збігу запускається тег, який відправляє відповідну подію в GA4.

Змінні також допомагають надсилати додаткові відомості. Наприклад, разом із кліком можна записувати ідентифікатор кнопки, назву форми або адресу сторінки. Пізніше ці параметри використовують під час аналізу поведінки відвідувачів.

Приклад роботи тега та тригера при натисканні на кнопку

Уявімо сторінку послуги з кнопкою «Отримати консультацію». Потрібно враховувати натискання цієї кнопки, не включаючи кліки по меню, контактам та іншим елементам.

Послідовність обробки виглядає так:

1. Відвідувач відкриває сторінку послуги, де встановлено контейнер Google Tag Manager.
2. Користувач натискає кнопку консультації, після чого браузер створює подію кліка.
3. GTM отримує інформацію про елемент і перевіряє умови тригера, включаючи його ідентифікатор.
4. Якщо умови збігаються, запускається тег події Google Analytics 4, пов'язаний з тригером.
5. Тег надсилає дані, які потім можна перевірити в DebugView і використовувати у звітах GA4.

Схема роботи:

Дія користувача → Подія GTM → Перевірка умов тригера → Запуск тега → Відправлення даних до GA4

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

Чим тригер відрізняється від тега?

Тег містить налаштування дії, що має виконуватися. Наприклад, Google Tag може забезпечувати роботу Google Analytics, а тег події GA4 – надсилати відомості про взаємодію відвідувача з певним елементом сторінки.

Тригер визначає момент виконання цієї дії. Без відповідної умови запуску аналітичний тег не реагуватиме на події сайту. При цьому наявність тригера ще не гарантує успішної доставки інформації до системи аналітики.

Один і той самий тригер може запускати кілька тегів. Наприклад, підтверджена відправка форми може передаватися до GA4 та іншої системи вимірювання, якщо це передбачено налаштуваннями сайту та згодою користувача.

Для керування такими зв'язками бажано використовувати зрозумілі назви. За назвою GA4 – button_click – Consultation легше визначити призначення тега, ніж за назвою Tag 5. Аналогічний принцип підходить для тригерів, змінних та подій.

Як розуміти англійські терміни Trigger та Tag?

В англомовній документації Google використовуються назви Tag, Trigger, Event та Variable. В українськомовному інтерфейсі їм відповідають тег, тригер, подія та змінна, хоча частина технічних позначень залишається англійською мовою.

Запит tag manager trigger зазвичай стосується налаштування умов запуску тегів Google Tag Manager. Формулювання trigger tag зустрічається під час пошуку інформації про зв'язок тригера з тегом. Окремого типу тригера з такою назвою у стандартному інтерфейсі GTM немає.

Для налаштування корисно запам'ятати кілька виразів: Trigger Configuration означає конфігурацію тригера, Firing Triggers – тригери активації, а Trigger Exceptions – винятки, які забороняють запуск за певних умов.

Назви можуть відображатись по-різному залежно від мови інтерфейсу. Тому при роботі з іноземними інструкціями краще орієнтуватися на призначення налаштування та його розташування, а не лише на дослівний переклад.

Що таке All Pages trigger у Google Tag Manager?

All Pages – стандартний тригер перегляду сторінок, який використовується для запуску тегів під час завантаження GTM. Він підходить для завдань, де тег повинен працювати на кожній сторінці із встановленим контейнером.

На запит google tag manager all pages trigger найчастіше шукають інструкцію з налаштування такого запуску та пояснення його відмінностей від інших подій завантаження сторінки.

Наприклад, All Pages можна використовувати для базового налаштування аналітики, яка має бути присутня на всьому сайті. Однак це правило не гарантує, що тег обов'язково виконається за будь-яких обставин: на його роботу можуть впливати налаштування згоди, виключення, помилки завантаження та інші обмеження.

Головна особливість All Pages полягає у часі спрацьовування. Звичайний тригер Page View реагує на подію GTM, яка з'являється під час обробки завантаженого контейнера. До цього моменту браузер може продовжувати формувати сторінку і завантажувати ресурси.

Як працює тригер All Pages?

При стандартному завантаженні вебконтейнера Google Tag Manager реєструє подію gtm.js. Вона відповідає звичайному етапу Page View і використовується стандартним тригером All Pages.

Коли така подія обробляється, GTM перевіряє пов'язані з нею теги. Якщо фільтрів немає, а інші налаштування не перешкоджають запуску, відповідні теги активуються.

All Pages не очікує повного завантаження зображень, шрифтів та інших ресурсів. Для завдань, які потребують готової HTML-структури або завершення завантаження сторінки, передбачені окремі типи тригерів.

Варто враховувати особливості сайтів із динамічною навігацією. Якщо відвідувач переходить між розділами без перезавантаження документа, подія gtm.js зазвичай не виникає повторно. Для таких переходів можуть знадобитися додаткові події та окреме налаштування переглядів сторінок.

Для яких тегів підходить All Pages?

All Pages підходить для тегів, яким необхідно оброблятись на всіх звичайних завантаженнях сторінок. Типовий приклад – базове налаштування Google Analytics через Google Tag, коли така схема передбачена конфігурацією аналітики.

Інший варіант – технічний тег, якому потрібно отримувати інформацію про кожне завантаження документа. При цьому не можна автоматично застосовувати All Pages до всіх скриптів: деякі з них вимагають готового DOM, згоди користувача чи конкретної дії на сайті.

При підключенні GA4 необхідно перевірити автоматичне надсилання page_view. Якщо перегляди вже передаються через Google Tag, додатковий тег із тією самою подією може створювати дублі. Особливо уважно слід перевіряти сайти, де одночасно використовуються GTM, пряме підключення Google Tag та плагіни аналітики.

Для користувацьких конверсій All Pages зазвичай не підходить. Якщо тег повинен враховувати оформлене замовлення, відправлену заявку або передплату, його слід запускати за подією підтвердженої дії, а не під час відкриття будь-якої сторінки.

Чим відрізняються All Pages, DOM Ready та Window Loaded?

Усі три типи стосуються завантаження сторінки, але реагують на різні етапи. Правильний вибір залежить від того, які дані або елементи потрібні тегу для роботи.

Послідовність для звичайного завантаження сторінки виглядає так:

Page View → DOM Ready → Window Loaded

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

Page View – подія gtm.js

Page View – рання подія стандартного життєвого циклу GTM. Вона з'являється при завантаженні контейнера і підходить для тегів, яким не потрібно звертатися до сформованих HTML-елементів.

Наприклад, базовий аналітичний тег може отримати адресу поточної сторінки та інші доступні параметри без очікування на завантаження зображень. Такий запуск допомагає не відкладати збір даних до завершення пізніших етапів.

Однак, gtm.js не слід плутати з подією page_view Google Analytics 4. Перша стосується внутрішньої обробки GTM, а друга є аналітичну подію, яку GA4 може отримувати при налаштованому вимірюванні переглядів.

DOM Ready – подія gtm.dom

DOM Ready настає після того, як браузер розібрав HTML-документ та сформував його об'єктну модель. Це слушний момент для скриптів, яким необхідно знайти існуючий елемент, прочитати його атрибути або перевірити структуру сторінки.

Наприклад, користувацький код може шукати певний блок за CSS-селектором. При надто ранньому запуску потрібний елемент іноді відсутній, оскільки браузер ще не завершив обробку відповідної частини документа.

DOM Ready не гарантує появи елементів, які застосунок додає пізніше через JavaScript. На динамічних сайтах іноді потрібна окрема подія застосунку або спостереження за зміною видимості елемента.

Window Loaded – подія gtm.load

Window Loaded відповідає події load, яку браузер створює після завершення початкового завантаження документа та залежних ресурсів, що враховуються цим механізмом. Зазвичай вона відбувається пізніше за DOM Ready.

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

Застосовувати Window Loaded до всієї аналітики не слід. Якщо сторінка довго завантажує ресурси, пізній запуск може призвести до втрати частини взаємодій, що відбулися раніше. Для більшості стандартних подій краще вибирати тригер за реальною технічною потребою.

Чим All Pages відрізняється від Initialization та Consent Initialization?

У Google Tag Manager передбачені події, які обробляються раніше звичайного Page View. Вони потрібні для завдань, чутливих до послідовності ініціалізації контейнера.

Consent Initialization застосовується для тегів керування згодою. Наприклад, інтеграція платформи CMP може встановити значення згоди до запуску аналітичних тегів.

Initialization використовують для інших сценаріїв раннього виконання. Він не повинен замінювати Consent Initialization у налаштуваннях, де потрібна коректна початкова обробка згод.

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

Коли All Pages не підходить?

All Pages не підходить для дій, які відбуваються після завантаження сторінки та потребують окремої реєстрації. Наприклад, купівля, надсилання форми, перегляд певного блоку або натискання кнопки не повинні автоматично враховуватися під час кожного відкриття документа.

Також він незручний, коли потрібний тег тільки в конкретному розділі сайту. У такому випадку можна створити Page View з фільтром по Page Path або вибрати іншу подію, що відповідає завданню.

Особливої уваги вимагають сайти на React, Vue та Next.js. При клієнтських переходах адреса може змінюватися без повного завантаження сторінки. Для коректного вимірювання таких переходів потрібно враховувати маршрутизацію застосунку та вже існуючі механізми GA4.

Які типи тригерів існують у GTM?

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

Перед налаштуванням корисно визначити, яку дію потрібно фіксувати та за якими ознаками GTM зможе її розпізнати.

Деякі типи потребують додаткової підготовки. Наприклад, для відстеження кліків необхідно включити вбудовані змінні, а для користувацьких подій – забезпечити передачу даних із застосунку.

Тригери перегляду сторінок

Тригери перегляду сторінок використовують для запуску тегів на певних етапах завантаження документа. Їх зручно застосовувати там, де подія не залежить від конкретної дії відвідувача.

Page View реагує на завантаження контейнера, DOM Ready – на готовність HTML-структури, а Window Loaded – на більш пізній етап. Initialization та Consent Initialization призначені для спеціальних завдань раннього запуску.

Якщо тег потрібен лише на сторінці послуги, можна використовувати Page View із фільтром за адресою. Наприклад, умова Page Path equals /services/seo/ обмежить його спрацьовування вказаним шляхом. За наявності мовних версій сайту умови знадобиться узгодити з їхніми URL.

Для кожного такого правила бажано заздалегідь визначити очікувану кількість запусків. Це особливо корисно під час перевірки аналітики після впровадження нових шаблонів сторінок.

Тригери кліків та взаємодій

Click-тригери відстежують взаємодію з елементами інтерфейсу. Їх застосовують для кнопок, посилань, пунктів меню та інших об'єктів, на які відвідувачі натискають мишею чи виконують відповідну дію.

У GTM доступні два основні варіанти: All Elements та Just Links. Перший працює з ширшим набором HTML-елементів, другий призначений для посилань <a>.

Для точного відстеження необхідно додати фільтр. Без нього тригер All Elements може реагувати на безліч кліків, які не належать до вибраної бізнес-дії.

Крім кліків можна використовувати користувацькі події. Наприклад, якщо сайт передає подію відкриття модального вікна, така дія часто зручніше вимірювати безпосередньо через dataLayer, особливо коли інтерфейс регулярно змінюється.

Тригери відправлення форм

Form Submission відстежує подію відправлення HTML-форми, доступну стандартному механізму GTM. Він може підійти для простих форм, що працюють через звичайне відправлення браузером.

Однак сучасні сайти часто використовують AJAX-запити та JavaScript-обробники. Такі форми можуть не створювати очікувану подію або генерувати її до отримання відповіді сервера.

Тому необхідно перевіряти не лише факт спрацьовування тригера, а й результат дії. Якщо заявка не збереглася через помилку, реєструвати успішну конверсію не можна.

Для надійного вимірювання зазвичай зручніше передавати подію form_submit_success після підтвердження надсилання застосунком. У цьому випадку аналітика отримує точніший сигнал про виконану дію.

Тригери прокручування та видимості елементів

Scroll Depth відстежує досягнення заданого рівня прокручування сторінки. Наприклад, можна фіксувати проходження 25%, 50%, 75% чи 90% її висоти.

Такі показники допомагають вивчати взаємодію відвідувачів із довгими статтями та посадковими сторінками. Але досягнута глибина прокручування не доводить, що людина прочитала відповідний обсяг тексту.

Element Visibility відстежує появу вибраного елемента в області перегляду. Для нього можна встановити мінімальну частку видимої площі та додаткові параметри спрацьовування.

Наприклад, такий тригер підходить для вивчення видимості блоку з тарифами чи форми консультації. Якщо елемент розташований у прихованій вкладці, його поява та фактична видимість залежать від реалізації інтерфейсу та вимагають тестування.

Додаткові типи тригерів

Custom Event використовується для подій, які сайт передає самостійно. Він підходить для складних форм, підтверджених замовлень, відкриття окремих компонентів та інших дій застосунку.

History Change допомагає відстежувати зміни адреси через History API, включаючи операції pushState і replaceState. Цей тип корисний для SPA, але необхідно перевірити, які переходи застосунок дійсно створює.

Timer реагує на заданий інтервал часу, а YouTube Video – на події вбудованого програвача YouTube, що підтримуються. JavaScript Error допомагає реєструвати деякі помилки JavaScript, які доступні механізму відстеження GTM.

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

Як створити тригер у Google Tag Manager?

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

Як приклад розглянемо тригер перегляду сторінок певного розділу. Такий сценарій зручний для знайомства з інтерфейсом, оскільки не потребує налаштування JavaScript або пошуку HTML-елементів.

Крок 1. Відкрити розділ Triggers

Перейдіть на tagmanager.google.com та виберіть обліковий запис із потрібним контейнером. Переконайтеся, що відкритий сайт, для якого будуть створюватися правила відстеження.

У меню робочої області відкрийте розділ «Тригери» (Triggers) та натисніть «Створити» (New). Після цього з'явиться вікно нового тригера із полями назви та конфігурації.

Назву краще ставити до збереження. Наприклад, PV – SEO Services – RU показує тип події та розділ сайту. Такий підхід є особливо корисним, коли в одному контейнері накопичилося багато схожих правил.

Крок 2. Вибрати тип тригера

Натисніть на блок конфігурації тригера та виберіть потрібний тип зі списку. Для прикладу з відкриттям сторінки послуги підійде Page View.

Якщо потрібно реагувати на кнопку, виберіть Click. Для підтвердженої дії, яку застосунок передає самостійно, знадобиться Custom Event.

Тип має відповідати джерелу події. Налаштування Page View не зможе визначити успішне надсилання заявки, а Click не гарантує, що дія після натискання виконалася.

При сумнівах відкрийте Preview та перевірте, які події з'являються при потрібній дії. Ця перевірка часто допомагає вибрати тригер до створення додаткових правил.

Крок 3. Встановити умови спрацьовування

Для Page View можна вибрати All Page Views або Some Page Views. Перший варіант реагує на відповідні перегляди сторінок, другий дозволяє обмежити запуск додатковими фільтрами.

Наприклад, для розділу послуг можна задати умову:

Page Path contains /services/seo/

Такий фільтр підходить, якщо обрана частина шляху дійсно є тільки в потрібному розділі. При перетині адрес краще використовувати точний збіг або регулярний вираз.

Після налаштування перевірте кілька відповідних та невідповідних URL-адрес. Особливо уважно тестуйте сайти з різними мовними версіями, параметрами в адресах та нестандартними правилами формування URL.

Крок 4. Зберегти тригер і прив'язати його до тега

Натисніть «Зберегти», а потім відкрийте потрібний тег у розділі Tags. В області Triggering виберіть створений тригер як умову активації.

При необхідності один тригер можна підключити до кількох тегів. Наприклад, якщо два незалежні вимірювання повинні реагувати на одну підтверджену дію, для них допустимо використовувати загальне правило.

При цьому слід враховувати налаштування самого тега. Деякі теги мають додаткові обмеження, пов'язані зі згодою користувача, частотою запуску або послідовністю виконання.

Збереження конфігурації у робочій області ще не означає публікацію змін на сайті. Для початку необхідно перевірити їх у режимі попереднього перегляду.

Крок 5. Перевірити налаштування перед публікацією

Відкрийте Preview, підключіть сторінку сайту та виконайте дію, яку повинен відстежувати тригер. Потім перевірте, чи з'явився очікуваний event і чи запустився тег, пов'язаний з ним.

Для нашого прикладу відкрийте URL із вибраного розділу та переконайтеся, що правило спрацьовує. Після цього перейдіть на сторінку іншого розділу та перевірте відсутність зайвого запуску.

Якщо тести пройшли успішно, можна надіслати зміни до публікації через Submit. При створенні версії контейнера бажано зазначити, які тригери додані чи змінені.

Така історія змін допомагає знаходити причину помилок, що виникли після подальших оновлень аналітики.

Як налаштувати умови та фільтри тригерів?

За замовчуванням багато типів тригерів можуть реагувати на всі події обраної категорії. Наприклад, All Elements може враховувати різні кліки на сторінці, тому для відстеження однієї кнопки необхідно додати конкретну умову.

Фільтри дозволяють порівнювати значення змінних із заданими правилами. Завдяки цьому можна запускати тег на певному URL, для конкретного елемента або під час виконання кількох вимог одночасно.

Які оператори доступні у фільтрах?

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

У прикладі регулярного виразу символ | позначає альтернативу. Такий шаблон можна застосовувати до двох мовних шляхів, якщо структура адрес повністю відповідає зазначеній умові.

Регулярні вирази корисні для груп сторінок, але помилки в шаблоні здатні істотно розширити охоплення тригера. Тому складні умови спочатку перевіряють на реальних URL у Preview.

Як використовувати вбудовані змінні GTM?

Вбудовані змінні надають значення, які GTM вміє одержувати без написання окремого коду. Серед них є Page URL, Page Path, Click Element, Click ID, Click Classes, Click URL та Click Text.

Щоб увімкнути змінні, відкрийте розділ Variables і перейдіть до налаштування Built-In Variables. Виберіть показники, необхідні для певного сценарію відстеження.

Після цього в режимі Preview можна побачити значення відповідних змінних під час зареєстрованих подій. Наприклад, при натисканні на посилання Click URL покаже адресу переходу, якщо GTM зміг визначити її для вибраного елемента.

Click Text слід використовувати обережно. Текст кнопки може відрізнятися в російській, українській та англійській версіях, а також змінюватись в результаті редагування контенту. Для постійного відстеження краще підходять стабільні технічні ознаки.

З чого складається умова спрацьовування?

Кожна стандартна умова фільтра включає змінну, оператор та значення. Змінна надає дані, оператор визначає спосіб порівняння, а значення задає потрібний результат.

Наприклад, правило Page Path contains /services/ перевіряє, чи шлях поточної сторінки містить зазначену послідовність символів.

Для кількох умов GTM перевіряє їхнє спільне виконання в рамках обраної події. Тому додаткові фільтри звужують набір ситуацій, де тег буде запущений.

Умова по Page URL або Page Path

Page URL містить повну адресу сторінки, включаючи протокол, домен та інші компоненти URL. Page Path повертає шлях, за яким браузер відкрив документ.

Для відстеження розділу всередині одного сайту зазвичай зручно використовувати Page Path. Наприклад, умова Page Path equals /ua/services/seo/ дозволяє вибрати конкретну мовну сторінку.

Якщо правило має працювати на кількох доменах, потрібно окремо перевірити, чи підходить порівняння лише за шляхом. На різних сайтах можуть зустрічатися однакові URL-шляхи, тому іноді додатково перевіряють hostname.

Для точного збігу використовуйте equals, а для розділу з кількома вкладеними сторінками – відповідний contains або регулярний вираз. Не забувайте про кінцевий сліш та особливості маршрутизації сайту.

Умови Click ID та Click Classes

Click ID отримує значення атрибута id елемента, по якому зареєстровано клік. Якщо кнопка має стабільний унікальний ідентифікатор, по ньому зручно створювати точну умову.

Click Classes містить CSS-класи вибраного елемента. Цей варіант підходить, коли стабільного ID немає, але розробник передбачив окремий клас для аналітики.

Слід враховувати, що класи часто використовуються для оформлення інтерфейсу та можуть змінюватись після оновлення дизайну. Особливо ненадійні автоматично згенеровані імена, які залежать від збирання застосунку.

Якщо відстеження є критичним для бізнесу, бажано погодити з розробником постійний ідентифікатор або data-атрибут. Це знижує ризик втрати подій після оновлення шаблонів.

Як налаштувати тригер кліка на кнопку?

Відстеження кнопок допомагає аналізувати дії, які відвідувачі виконують на сайті. Наприклад, можна дізнатися, як часто користувачі відкривають форму консультації, переходять до оформлення замовлення або натискають контактну кнопку.

Для налаштування необхідно визначити HTML-елемент, створити відповідний Click-тригер та підключити його до тегу події. Головна умова – відокремити необхідний клік від інших взаємодій на сторінці.

Як вибрати між All Elements та Just Links?

All Elements відстежує кліки по різних HTML-елементах, включаючи кнопки, зображення та вкладені компоненти інтерфейсу. Just Links призначений для кліків по HTML-посиланнях <a>.

Якщо елемент реалізований як <button>, зазвичай вибирають All Elements. Для переходу за звичайним посиланням частіше підходить Just Links.

Відмінність особливо помітна на сайтах із нестандартним інтерфейсом. Візуально кнопка може бути посиланням, а іноді клікабельний елемент реалізований через контейнер із JavaScript-обробником.

Тому перед створенням правила бажано перевірити HTML-розмітку. Зовнішній вигляд елемента не завжди показує, який тип тригера зможе правильно визначити взаємодію.

Для Just Links доступні додаткові параметри, пов'язані з очікуванням тегів та перевіркою коректності кліка. Їх потрібно тестувати окремо, оскільки поведінка посилань залежить від скриптів сайту.

Як визначити необхідний елемент?

Відкрийте сторінку в браузері, натисніть правою кнопкою миші на потрібний елемент та виберіть команду перегляду коду. В інструментах розробника знайдіть атрибути id, class та інші ознаки.

Якщо кнопка містить id="consultation-button", для тригера можна задати умову:

Click ID equals consultation-button

Після цього запустіть Preview та перевірте значення Click ID при натисканні. Якщо клік потрапляє по вкладеному елементу, GTM може отримати відомості саме про нього, тому просте порівняння ID іноді не спрацьовує.

У таких ситуаціях можна використовувати Click Element з відповідним CSS-селектором або домовитися з розробником про стабільну подію.

CSS-селектор дозволяє визначити елемент за його положенням та атрибутами. Однак надмірна залежність від вкладеності HTML робить відстеження вразливим до змін верстки.

Як передати подію кліку в GA4?

Після створення тригера потрібно налаштувати передачу даних. Для цього в Google Tag Manager створюють тег Google Analytics: GA4 Event, пов'язаний з потрібним ідентифікатором потоку даних.

Як ім'я події можна використовувати button_click. Для додаткової інформації підходять параметри button_id та button_name.

Приклад налаштування:

Ім'я події має відповідати прийнятій схемі аналітики проєкту. Перед створенням користувацької події бажано перевірити, чи немає відповідної рекомендованої події GA4 і чи не передаються аналогічні відомості автоматично.

Після збереження запустіть Preview, натисніть кнопку та відкрийте відповідну подію. Потім перевірте її надходження до GA4 DebugView, включаючи передані параметри.

Для використання деяких користувацьких параметрів у звичайних звітах GA4 може знадобитися створення спеціальних визначень у налаштуваннях ресурсу.

Чому клік на кнопку не завжди є конверсією?

Клік фіксує взаємодію відвідувача з інтерфейсом. Після натискання може відкритися форма, розпочатись перевірка введених даних або виконатися запит до сервера.

Якщо відвідувач натиснув «Надіслати заявку», але припустився помилки в номері телефону, успішної відправки не сталося. Аналогічна ситуація виникає при помилці сервера або втраті з'єднання.

У таких випадках подія кліка є корисною для аналізу поведінки, але вона не повинна автоматично враховуватися як підтверджена заявка.

Провідний SEO-спеціаліст — Геннадій

У роботі з SEO-проєктами я використовую Google Tag Manager для відстеження дій, які допомагають оцінювати якість пошукового трафіку. Перегляд сторінки показує відвідування, а кліки по контактах та надсилання форм дають додаткові відомості про зацікавленість користувачів.

Особливу увагу приділяю тому, що фіксує тригер. Натискання кнопки надсилання ще не означає, що заявка успішно створена. Якщо рахувати такі кліки конверсіями, дані GA4 можуть спотворювати реальну ефективність органічного пошуку. Для важливих бізнес-дій я віддаю перевагу подіям, які сайт передає після підтвердженого результату.

Такий підхід допомагає розділяти проміжні взаємодії та підсумкові дії. В аналітиці можна окремо аналізувати інтерес до форми та кількість фактично отриманих заявок.

Як відстежувати надсилання форми через GTM?

Форми використовуються для заявок, реєстрації, підписки та зворотного зв'язку. Для оцінки їхньої роботи необхідно розуміти, на якому етапі має виникати аналітична подія.

На простих сайтах достатньо стандартного Form Submission, але складні форми потребують додаткових перевірок. Головне завдання – переконатися, що аналітика фіксує успішний результат, коли саме він вважається цільовою дією.

Коли використовувати Form Submission?

Тригер Form Submission підходить для HTML-форм, які створюють подію відправки, доступну стандартному обробнику GTM. Для налаштування вибирають відповідний тип і вказують умови, що обмежують потрібні форми.

При необхідності можна використовувати вбудовані змінні, пов'язані з формою, або фільтр по сторінці розміщення. Після налаштування необхідно перевірити поведінку під час коректного та некоректного заповнення.

Слід враховувати, що стандартна подія надсилання не завжди підтверджує збереження даних на сервері. Наприклад, браузер може розпочати відправлення, після якого виникне технічна помилка.

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

Як відстежувати успішне надсилання AJAX-форми?

AJAX-форми надсилають дані без повного перезавантаження сторінки. Їхня логіка зазвичай обробляється JavaScript-кодом, який відправляє запит і отримує відповідь сервера.

Для таких форм зручно передбачити окрему користувацьку подію. Після успішного підтвердження операції застосунок передає інформацію в dataLayer, а GTM реагує через Custom Event.

Наприклад, можна використовувати form_submit_success з ідентифікатором форми. Це допомагає розрізняти заявки, надіслані із шапки сайту, картки послуги або окремої сторінки контактів.

Подія повинна з'являтись лише після перевірки результату. Якщо сервер повернув помилку, користувач побачив повідомлення про збій або заявку було відхилено, успішну конверсію передавати не слід.

Як уникнути помилкових конверсій?

Найпоширеніша помилка – вважати конверсією будь-яке натискання кнопки відправки. Такий підхід завищує результати, якщо відвідувачі часто стикаються із помилками заповнення.

Інше джерело проблем – повторне надсилання однієї події. Вона може виникати, коли кілька обробників реагують на один результат або користувач повторно натискає кнопку.

Для перевірки слід протестувати успішне відправлення, помилки обов'язкових полів, збій сервера та повторне виконання дії. У кожному сценарії потрібно порівняти очікувані події із фактично відправленими.

Якщо у GA4 відзначається важлива для бізнесу дія, її необхідно коректно налаштувати як key event. Попередньо слід переконатися, що подія справді відображає завершену операцію.

Як працюють Custom Event та dataLayer?

Вбудовані тригери зручні для стандартних взаємодій, що відбуваються у браузері. Але складні сайти виконують безліч дій, результат яких не можна надійно визначити лише за HTML-елементами.

Для передачі таких відомостей використовують користувацькі події і dataLayer. Це особливо корисно для форм, кошиків, особистих кабінетів та застосунків з динамічними компонентами.

Що таке користувацька подія?

Custom Event – тип тригера, який реагує на подію з певним ім'ям у dataLayer. Його назву узгоджують із розробником і використовують у налаштуваннях GTM.

Наприклад, після успішного надсилання заявки застосунок може передати подію form_submit_success. Google Tag Manager виявить її та перевірить пов'язані умови.

Користувацькі події зручні тим, що можуть описувати дії на рівні бізнес-логіки сайту. При оновленні оформлення кнопок або форми узгоджена подія продовжуватиме працювати, якщо розробник зберігає її передачу.

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

Як передати подію через dataLayer?

Data Layer – рівень даних, через який сайт передає інформацію до Google Tag Manager. Зазвичай він представлений масивом window.dataLayer, що містить об'єкти з параметрами та назвами подій.

Для передачі події використовують dataLayer.push(). Нижче наведено приклад, який може викликати розробник після успішного підтвердження заявки сервером.

window.dataLayer = window.dataLayer || [];

window.dataLayer.push({
  event: 'form_submit_success',
  form_id: 'consultation'
});

Тут event містить назву події, а form_id вказує ідентифікатор форми. Значення наведені для прикладу та мають відповідати реальним ідентифікаторам сайту.

Після впровадження коду створіть тригер Custom Event з ім'ям form_submit_success. Щоб надіслати ідентифікатор форми, налаштуйте змінну рівня даних з ключем form_id.

Потім підключіть тригер до тега GA4 Event та вкажіть необхідні параметри. При успішному надсиланні форми GTM зможе отримати подію та відправити передбачені дані в аналітику.

Не передавайте в GA4 імена клієнтів, адреси електронної пошти, телефонні номери та інші персональні дані. Для форми достатньо технічних параметрів, які необхідні для аналітики.

Як використовувати тригери на SPA-сайтах?

SPA-застосунки можуть змінювати вміст сторінки без перезавантаження документа. Такий підхід зустрічається у проєктах на React, Vue та Next.js, хоча конкретна поведінка залежить від архітектури застосунку.

Наприклад, користувач переходить із каталогу до картки товару. Адреса сторінки змінюється, інтерфейс оновлюється, але стандартна подія завантаження GTM може не з'явитися повторно.

Для вимірювання таких переходів використовують History Change, події маршрутизації застосунку або вже налаштовані механізми Google Analytics 4.

Під час роботи з History Change важливо перевірити, які зміни історії дійсно фіксує сайт. Не кожен перехід автоматично відповідає новому перегляду сторінки, особливо при складній клієнтській навігації.

Окремо необхідно перевірити автоматичний вимір переглядів у GA4. Якщо він вже реагує на зміни історії, додаткове ручне надсилання page_view може створювати дублі.

На багатомовних сайтах також слід контролювати параметри мови, адресу сторінки та заголовок документа. При клієнтському переході ці значення повинні відповідати вже відкритій сторінці.

Що таке групи тригерів та винятки?

Іноді однієї умови недостатньо для запуску тега. Наприклад, потрібно враховувати користувачів, які прокрутили статтю до певної глибини та провели на сторінці встановлений час.

У таких випадках застосовують Trigger Group. Для ситуацій, де запуск потрібно заборонити, передбачено Trigger Exceptions. Ці функції вирішують різні завдання та можуть використовуватися в одній конфігурації.

Як працює Trigger Group?

Trigger Group об'єднує кілька тригерів у загальну умову. Група спрацьовує після того, як усі включені до неї тригери активувалися необхідну кількість разів.

Припустимо, потрібно зафіксувати взаємодію зі статтею за двох умов: відвідувач досяг глибини прокручування 50% і провів на сторінці 60 секунд.

Для налаштування спочатку створюють Scroll Depth з порогом 50%, потім Timer з відповідним інтервалом і обмеженнями. Після цього обидва правила додають до Trigger Group.

Порядок виконання умов не має значення. Користувач може спочатку знаходитись на сторінці заданий час, а потім прокрутити її до потрібної глибини.

Якщо один і той же тригер додати до групи кілька разів, GTM вимагатиме відповідну кількість його спрацьовувань. Це підходить для сценаріїв, де необхідно зафіксувати повторну дію.

При звичайному завантаженні сторінки стан групи починається заново. Стандартна Trigger Group не призначена для накопичення умов між незалежними завантаженнями різних сторінок.

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

Як налаштувати Trigger Exceptions?

Trigger Exceptions дозволяють заблокувати запуск тега за певних умов. Наприклад, можна виключити внутрішню тестову сторінку з окремого аналітичного виміру.

Для цього відкрийте налаштування тега та додайте правило до області Exceptions. Як виняток можна вибрати Page View з фільтром по URL тестового розділу.

Якщо умова виключення виконується, вона запобігає запуску відповідного тега по основному тригеру. Результат необхідно перевірити в Preview, оскільки взаємодія умов залежить від події, що обробляється.

Винятки також можуть використовуватись для запобігання окремим небажаним запускам. Але вони не замінюють коректну схему роботи Consent Mode і не повинні застосовуватись для обходу вибору користувача.

Перед додаванням кількох винятків бажано перевірити, чи не простіше уточнити умови основного тригера. Складна система взаємних блокувань ускладнює подальшу підтримку аналітики.

Як перевірити роботу тригерів у GTM?

Після створення тригера необхідно переконатися, що він реагує на правильну подію та запускає потрібний тег. Однією перевірки налаштувань в інтерфейсі недостатньо: важливо подивитися фактичну поведінку сайту.

Google Tag Manager надає режим попереднього перегляду. Додатково результати передачі подій можна перевіряти у Google Analytics 4.

Як використовувати Preview Mode та Tag Assistant?

У робочій області GTM натисніть Preview. Відкриється Google Tag Assistant, де необхідно вказати адресу сторінки та підключитись до сайту.

Після підключення виконайте дію, яку слід відстежувати. Наприклад, відкрийте сторінку послуги, натисніть кнопку консультації або надішліть тестову форму.

Tag Assistant покаже послідовність зареєстрованих подій та відомості про пов'язані з ними теги. Тут можна побачити, які значення містили змінні та які правила перевірялися.

Для налаштування кліка виберіть відповідну подію та перегляньте її параметри. Якщо ідентифікатор кнопки відрізняється від значення у фільтрі, тригер не виконає очікуваної умови.

Режим Preview працює із поточними змінами контейнера до публікації. Тому його слід використовувати щоразу, коли додаються нові теги, тригери чи змінні.

Як визначити причину, через яку тег не спрацював?

Якщо тег не активувався, перевірте наявність очікуваної події. Без слушної події GTM не зможе виконати пов'язаний з ним тригер.

Потім відкрийте інформацію про тег. У Tag Assistant доступні розділи Tags Fired та Tags Not Fired, які допомагають визначити теги, які запускалися при вибраній події.

Особливу увагу приділіть умовам фільтрації. Наприклад, якщо Click ID повертає порожнє значення, перевірка за конкретним ідентифікатором не дасть позитивного результату.

Перевірте також налаштування виключень та згоди користувача. Вони можуть впливати на запуск навіть при коректному основному тригері.

Якщо тег активувався, але дані не з'явилися в GA4, необхідно перевірити його тип, ідентифікатор потоку, назву події, параметри та можливі помилки надсилання. Запуск тега у GTM ще не підтверджує успішну обробку події аналітичною системою.

Як перевірити події в GA4 DebugView?

DebugView дозволяє спостерігати події, що надходять до Google Analytics 4 у режимі налагодження. Він корисний для перевірки користувацьких подій і параметрів, що передаються.

Відкрийте відповідний ресурс GA4 та перейдіть до DebugView. Переконайтеся, що тестовий пристрій передає події з увімкненим режимом налагодження, наприклад, через підключений Tag Assistant.

Виконайте потрібну дію на сайті та знайдіть її назву у послідовності подій. Після вибору можна переглянути доступні параметри, включаючи ідентифікатор кнопки або форми.

Окремо перевірте кількість подій. Одна підтверджена дія не повинна створювати кілька однакових аналітичних записів, якщо повторне відправлення не передбачене логікою виміру.

Для бізнес-значущих подій перевірте налаштування key events. У GA4 саме так позначають події, що становлять особливу цінність для організації.

Відсутність події в DebugView не завжди означає помилку тригера. Причина може полягати в блокуванні передачі, налаштуваннях згоди, режиму налагодження або самого ресурсу аналітики.

Що перевірити перед публікацією контейнера?

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

Використовуйте наступний список:

• Перевірте роботу тригера на десктопі та мобільній версії, оскільки елементи інтерфейсу можуть відрізнятися.
• Відкрийте різні мовні версії сторінки і переконайтеся, що умови не залежать від тексту кнопок, що змінюється.
• Перевірте успішне надсилання форми, помилки заповнення та повторне натискання, щоб унеможливити помилкові конверсії.
• Протестуйте згоду та відмову від відповідних категорій обробки даних, перевіряючи коректність Consent Mode.
• Виконайте кілька SPA-переходів та порівняйте кількість подій з очікуваною кількістю переглядів.
• Перевірте, чи теги не запускаються на сторінках та елементах, які мають бути виключені з вимірювання.

Після успішного тестування створіть версію контейнера зі зрозумілою назвою змін. Для великих оновлень аналітики корисно зберігати короткий опис нових подій та правил їхнього запуску.

Типові помилки при налаштуванні тригерів Google Tag Manager

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

Щоб виявити проблему, необхідно порівнювати очікувану поведінку сайту з фактичними подіями в Preview та GA4.

Проблеми часто виникають після оновлення сайту, зміни форми або підключення нового аналітичного інструменту. Тому контроль вимірювань необхідний не тільки при початковому налаштуванні.

Тригер спрацьовує на всі кліки

Якщо для All Elements вибрати всі кліки без обмежень, GTM реагуватиме на безліч взаємодій з інтерфейсом. В аналітиці можуть з'являтися події від натискання меню, випадкових кліків та інших дій, які не належать до цільової кнопки.

Для виправлення додайте фільтр за стійким ідентифікатором або відповідним CSS-селектором. За необхідності обмежте область дії тригера певними сторінками.

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

Якщо на сайті використовуються однакові кнопки у різних блоках, заздалегідь визначте, чи потрібно поєднувати їх в одну категорію подій або передавати окремі параметри розташування.

Один і той же тег запускається двічі

Дублі з'являються, коли одна дія викликає кілька однакових відправлень. Наприклад, подія може передаватися безпосередньо кодом сайту та одночасно через Google Tag Manager.

Інша ситуація - до одного тегу підключені тригери, що перетинаються. Також слід враховувати повторні обробники JavaScript та автоматичний вимір подій Google Analytics.

Для діагностики знайдіть події, що дублюються в Tag Assistant і визначте, який саме тег виконує відправку. Потім перевірте підключення Google Tag, GA4 Event та додаткових інтеграцій.

Після виправлення повторіть тест. Для підтвердженої дії кількість подій має відповідати прийнятій логіці виміру, включаючи випадки повторних дій користувача.

Зміна дизайну порушує відстеження

Тригери, які залежать від оформлення елементів, часто перестають працювати після оновлення шаблону. Наприклад, CSS-клас кнопки може змінитися, хоча її призначення для користувача залишилося незмінним.

Аналогічна проблема виникає під час використання Click Text. Після зміни тексту або перекладу сторінки фільтр перестає збігатися з новим значенням.

Для важливих подій краще використовувати стабільні атрибути або передачу подій через dataLayer. Такі параметри менше залежать від зовнішнього вигляду інтерфейсу.

Перед редизайном бажано скласти список аналітичних ідентифікаторів, що використовуються. Розробник повинен знати, які зміни розмітки можуть вплинути на наявні виміри.

Тригер не працює на мобільній версії або SPA

На мобільній версії сайту елементи інколи мають іншу HTML-структуру. Наприклад, кнопка в десктопній шапці і аналогічна кнопка мобільного меню можуть мати різні ідентифікатори.

Тому тригер, налаштований лише за десктопним елементом, не обов'язково працюватиме на смартфоні. Для перевірки потрібно використовувати фактичну мобільну версію та її події.

У SPA проблема може бути пов'язана з відсутністю повного перезавантаження документа. Стандартний Page View не повинен спрацьовувати при кожному клієнтському переході між розділами.

Для вирішення перевірте маршрутизацію застосунку, History Change та наявне налаштування GA4. Потім переконайтеся, що сторінки враховуються без пропусків і дублювання.

Налаштування згоди блокують тег

Consent Mode впливає на роботу підтримуваних тегів залежно від стану згоди користувача. Додаткові перевірки згоди в GTM також можуть забороняти запуск за певних умов.

Якщо тег не спрацьовує, відкрийте його параметри Consent Settings і перевірте стан згоди в Tag Assistant. Необхідно розрізняти вбудовану поведінку Google Tag та додаткові обмеження, встановлені у контейнері.

Consent Initialization повинен використовуватися для початкового налаштування згод. Звичайні аналітичні теги не слід без необхідності переводити на цей ранній тип тригера.

Виправлення має відповідати вибраній моделі Consent Mode та вимогам до обробки даних. Не можна усувати помилку аналітики через ігнорування відмови користувача від відповідної обробки.

Тригери Google Tag Manager визначають, коли запускати теги та які дії відвідувачів враховувати в аналітиці. All Pages підходить для базових сценаріїв завантаження сторінки, Click допомагає відстежувати взаємодії, а Custom Event дозволяє отримувати дані про підтверджені дії застосунку.

Після налаштування обов'язково перевіряйте події у Tag Assistant та GA4 DebugView. Це допомагає знаходити пропущені дії, дублі та помилки фільтрації до того, як вони вплинуть на звіти.

Потрібне коректне налаштування Google Tag Manager та GA4? Зверніться до Seo-Gen за аудитом вебаналітики, перевіркою тригерів та налаштуванням відстеження цільових дій на сайті.