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

Теги Google допомагають відстежувати дії відвідувачів сайту: перегляди сторінок, натискання кнопок, заповнення форм, покупки та інші події. Отримані дані використовуються в Google Analytics 4, Google Ads та інших сервісах для аналізу відвідуваності, оцінки реклами та вимірювання конверсій.

Для керування такими параметрами використовують Google Tag Manager (GTM). Через його інтерфейс можна додавати теги, вибирати умови запуску, передавати параметри подій та перевіряти роботу відстеження. Більшість змін виконується без редагування вихідного коду сайту, якщо необхідні дані доступні.

Розберемо, які бувають теги в Google Tag Manager, чим вони відрізняються від глобального тега Google, як налаштувати передачу подій у GA4 та Google Ads. Окремо розглянемо перевірку тегів через Tag Assistant та помилки, через які дані не потрапляють до аналітики.

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

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

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

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

Навіщо використовуються теги Google?

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

На практиці теги використовують для кількох завдань:

• Вимірювання відвідуваності. Google tag допомагає збирати дані про перегляд сторінок та інші взаємодії з сайтом для Google Analytics 4.
• Відстеження заявок. Окрема подія фіксує успішне відправлення форми зворотного зв'язку, запису або замовлення послуги.
• Облік продажів. Подія покупки передає ідентифікатор замовлення, вартість, валюту та інформацію про придбані товари.
• Оцінка реклами. Тег Google Реклами допомагає вимірювати дії користувачів після взаємодії з оголошеннями.
• Ремаркетинг. Рекламні теги передають передбачені налаштування та сигнали для роботи з аудиторіями відповідно до умов згоди.

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

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

Як працюють теги, тригери та змінні?

У Google Tag Manager роботу відстеження визначають три основні елементи: теги, тригери та змінні. Кожен відповідає за свою частину налаштування.

Уявімо форму запису на консультацію. Після успішного опрацювання заявки сайт передає подію lead_form_success. GTM виявляє її, перевіряє умови тригера та запускає відповідний тег GA4.

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

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

Дія користувача → подія сайту → тригер GTM → тег → Google Analytics 4

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

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

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

Розглянемо форму заявки. Тег GA4 – generate_lead налаштований на надсилання події в Google Analytics 4. Тригер lead_form_success запускає його після підтвердження, що сервер прийняв заявку.

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

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

Які види тегів є у Google Tag Manager?

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

Для більшості сайтів базовий набір включає Google tag, події Google Analytics 4 та відстеження конверсій Google Ads. Додаткові рекламні та маркетингові теги підключають за необхідності.

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

Тег Google для Google Analytics 4

Google tag використовується для налаштування збору даних у сервісах Google, включаючи Google Analytics 4. Через нього можна встановити базові параметри вимірювання і зв'язати сайт з потрібним ресурсом аналітики.

Для підключення GA4 через GTM створюють тег типу Google tag та вказують відповідний ідентифікатор. У налаштуваннях Google Analytics є ідентифікатор потоку даних формату G-XXXXXXXXXX, а в конфігурації Google tag може використовуватися ідентифікатор GT-XXXXXXXXXX.

Для окремих дій створюють теги Google Analytics: GA4 Event. Вони передають події з вибраними назвами та параметрами, наприклад generate_lead, add_to_cart або purchase.

У старих посібниках можна зустріти тип GA4 Configuration. В актуальному налаштуванні замість нього використовується Google tag. Також не слід застосовувати інструкції для Universal Analytics, оскільки ця система більше не використовується для стандартного збору даних.

Тег Google Реклами для відстеження конверсій

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

Для налаштування через GTM використовують тип Google Ads Conversion Tracking. У ньому вказують Conversion ID та Conversion Label, які беруть із параметрів конкретної дії-конверсії в рекламному кабінеті.

Conversion ID пов'язаний з рекламним обліковим записом, а Conversion Label визначає потрібну дію-конверсію. Додатково можна передавати вартість, валюту та ідентифікатор транзакції.

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

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

Теги ремаркетингу та сторонніх сервісів

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

У GTM доступні налаштування для Google Ads та можливість підключення сторонніх сервісів, включаючи Meta Pixel. Залежно від платформи використовуються готові шаблони з галереї спільноти або користувацькі скрипти.

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

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

Користувацькі HTML-теги та шаблони

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

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

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

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

Коли краще вибрати готовий шаблон тега?

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

Наприклад, для передачі подій Google Analytics 4 зазвичай використовують вбудований тип GA4 Event. Створювати аналогічну відправку через Custom HTML немає потреби, якщо стандартний шаблон покриває завдання.

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

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

Чим Google tag відрізняється від Global Site Tag та Google Tag Manager?

Назви Google tag, Global Site Tag та Google Tag Manager часто зустрічаються в одних інструкціях. Через подібність термінів їх легко переплутати, особливо під час встановлення аналітики на новий сайт.

Google tag стосується налаштування вимірювання даних у сервісах Google, gtag.js використовується для безпосереднього підключення через код сторінки, а Google Tag Manager керує тегами та умовами їхнього запуску.

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

Що таке глобальний тег Google?

Global Site Tag – колишня назва технології підключення, яку зараз називають Google Tag. У старих інструкціях можна зустріти вирази «глобальний тег Google» та global tag google. Зазвичай вони стосуються встановлення коду gtag.js для Google Analytics або рекламних сервісів.

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

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

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

Що вибрати: gtag.js або Google Tag Manager?

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

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

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

Як створити та налаштувати тег у Google Tag Manager?

Розглянемо підключення Google Analytics 4 через Google Tag Manager та налаштування події успішної заявки. Для прикладу припускаємо, що ресурс GA4 створений, а контейнер GTM встановлений на всіх необхідних сторінках сайту.

Якщо контейнера ще немає, спочатку потрібно створити обліковий запис на tagmanager.google.com, додати вебконтейнер і встановити його код за інструкцією Google. Ідентифікатор контейнера має формат GTM-XXXXXXX.

Перед початком налаштування перевірте, чи є доступ до потрібного контейнера та ресурсу Google Analytics. Також варто переконатися, що аналітика не підключена повторно в інший спосіб.

Крок 1. Створення нового тега GTM

Відкрийте Google Tag Manager та оберіть контейнер потрібного сайту. У робочій області перейдіть до розділу Tags (Теги) і натисніть New (Створити).

У вікні, що відкриється, вкажіть назву тега і виберіть Tag Configuration (Конфігурація тега). Для базового підключення аналітики встановіть тип Google tag.

Використовуйте назву, за якою інші фахівці зможуть визначити призначення налаштування. Наприклад, GA4 – Google tag – Main.

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

Після вибору типу тега з'явиться поле для ідентифікатора Google. Його потрібно заповнити значенням із відповідного налаштування GA4 або Google tag.

Крок 2. Додавання ідентифікатора Google tag

Відкрийте Google Analytics 4 та перейдіть до розділу адміністратора. У налаштуваннях потрібного ресурсу знайдіть Потоки даних (Data streams) та виберіть вебпотік сайту.

У картці потоку доступний ідентифікатор вимірювання формату G-XXXXXXXXXX. У пов'язаних налаштуваннях Google tag можна знайти ідентифікатор самого тега та параметри його призначення.

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

Слід розрізняти основні формати ідентифікаторів:

• GTM-XXXXXXX – ідентифікатор контейнера Google Tag Manager, встановлений на сайті.
• G-XXXXXXXXXX – ідентифікатор вебпотоку даних Google Analytics 4.
• GT-XXXXXXXXXX – ідентифікатор Google tag у відповідній конфігурації.
• AW-XXXXXXXXX – ідентифікатор Google tag, пов'язаний із Google Ads.

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

Крок 3. Налаштування тригера запуску

Для базового Google tag зазвичай використовується вбудований тригер Initialization – All Pages. Він запускає тег на етапі ініціалізації контейнера до звичайних тригерів перегляду сторінки.

Відкрийте блок Triggering («Тригери»), виберіть відповідний варіант та збережіть налаштування. Після цього тег буде призначений для запуску під час завантаження сторінок, де встановлено контейнер.

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

Сам факт вибору Initialization – All Pages ще не гарантує отримання даних. Необхідно перевірити завантаження контейнера, правильність ідентифікатора та вплив налаштувань згоди.

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

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

Якщо сайт передає подію lead_form_success в dataLayer, у GTM можна створити тригер типу Custom Event і вказати цю назву в полі Event Name.

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

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

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

Крок 4. Створення тегу події GA4

Тепер налаштуємо передачу успішної заявки в Google Analytics 4. У GTM знову відкрийте Tags → New та виберіть тип Google Analytics: GA4 Event.

У полі Measurement ID вкажіть ідентифікатор потоку GA4. У Event Name задайте назву generate_lead – рекомендовану подію Google Analytics для реєстрації заявки.

Щоб розрізняти форми, додайте параметр form_type. Його значення можна отримувати зі змінної GTM, яка зчитує дані, передані сайтом через dataLayer.

Для прикладу використаємо таку конфігурацію:

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

Крок 5. Збереження, тестування та публікація

Збережений тег спочатку існує у робочій версії контейнера. Щоб перевірити його, натисніть Preview у верхній частині інтерфейсу GTM та підключіть адресу сайту через Tag Assistant.

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

Якщо результат коректний, натисніть Submit («Надіслати») у GTM. Вкажіть зрозумілу назву версії, наприклад GA4 – lead form tracking, додайте опис зміни та виконайте публікацію.

Історія версій дозволяє відновити попередню конфігурацію під час виявлення помилки. Тому бажано публікувати перевірені зміни окремими логічними наборами.

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

Приклади тегів GTM для відстеження подій

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

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

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

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

У GTM можна використовувати вбудований тригер Click – All Elements. В умовах запуску вказують відповідну ознаку елемента, наприклад, стійкий CSS ID або значення атрибута, доступне через змінну.

Якщо кнопка має ідентифікатор appointment-button, тригер можна обмежити умовою Click ID equals appointment-button. Для надсилання даних створюють тег GA4 Event з назвою appointment_click.

Назва події та її параметри повинні відповідати прийнятій схемі аналітики. За наявності рекомендованої події Google для конкретної дії бажано використовувати саме її.

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

Приклад тега для успішного надсилання форми

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

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

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

window.dataLayer.push({
  event: 'lead_form_success',
  form_type: 'consultation'
});

У GTM створюють тригер Custom Event із значенням lead_form_success. Окрема змінна Data Layer зчитує form_type, після чого тег GA4 відправляє generate_lead з відповідним параметром.

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

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

Приклад тега для покупки в інтернет-магазині

Для інтернет-магазину ключовою подією зазвичай стає purchase. Вона передає інформацію про завершену покупку та використовується у звітах електронної торгівлі Google Analytics 4.

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

Приклад структури даних покупки:

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

window.dataLayer.push({ ecommerce: null });

window.dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'ORDER-1058',
    value: 2500,
    currency: 'UAH',
    items: [
      {
        item_id: 'SKU-101',
        item_name: 'Товар',
        price: 2500,
        quantity: 1
      }
    ]
  }
});

Це приклад даних, які сайт передає до GTM після підтвердження замовлення. Для надсилання в GA4 потрібно додатково створити тег GA4 Event і налаштувати передачу параметрів з об'єкта ecommerce.

Значення value має відповідати правилам розрахунку виручки GA4, а валюта передається окремим параметром у форматі ISO 4217. Ідентифікатор транзакції має бути унікальним для замовлення.

Особливу увагу приділяють повторним відкриттям сторінки підтвердження. Якщо подія purchase повторно надсилається при кожному відвідуванні сторінки, дані про продажі можуть спотворюватися.

Як передавати дані події через dataLayer?

dataLayer – це шар даних, через який сайт передає інформацію до Google Tag Manager. Для додавання подій та параметрів використовується метод dataLayer.push().

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

Щоб GTM обробив подію, в об'єкті вказують поле event. Його значення має збігатися з назвою тригера Custom Event.

Для зчитування додаткових параметрів створюють змінні типу Data Layer Variable. Якщо дані вкладені в об'єкт ecommerce, змінна може використовувати шлях ecommerce.transaction_id або ecommerce.value.

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

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

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

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

Для діагностики використовують Google Tag Assistant, інструменти розробника Chrome та DebugView у Google Analytics 4. Кожен показує окрему частину процесу вимірювання.

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

Перевірка тегів через Google Tag Assistant

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

Щоб розпочати перевірку, відкрийте контейнер GTM, натисніть Preview та введіть URL-адресу сторінки. Після підключення виконайте потрібну дію на сайті.

У вікні Tag Assistant оберіть відповідну подію в лівій частині інтерфейсу. Далі перевірте інформацію на вкладках Tags, Variables та Data Layer.

В інтерфейсі доступні два важливі статуси:

• Tags Fired – теги, запущені для вибраної події або в межах сеансу, залежно від представлення.
• Tags Not Fired – теги, які не запустилися в контексті, що розглядається.

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

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

Перевірка тегів у Google Chrome

У браузері Google Chrome можна використовувати Tag Assistant та вбудовані інструменти DevTools. Вони допомагають перевірити завантаження контейнера та мережеві запити, які надсилає сайт.

Щоб перевірити запити, відкрийте DevTools за допомогою F12, перейдіть на вкладку Network і виконайте потрібну дію. Якщо потрібно, увімкніть збереження журналу, щоб запити не зникали після переходу на іншу сторінку.

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

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

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

Як виконати Google tag test та перевірити дані у GA4?

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

Для перевірки в Google Analytics 4 відкрийте Admin → DebugView і запустіть сесію налагодження через GTM Preview. Після цього виконайте на сайті дії, які мають надсилати події.

У DebugView перевірте назву події, час її появи та параметри. Наприклад, для generate_lead можна переконатися, що аналітика отримала потрібне значення form_type.

Для покупки необхідно додатково перевірити transaction_id, value, currency та масив items. Відсутність одного з необхідних параметрів може зробити звіти електронної торгівлі неповними.

Якщо подію видно в Tag Assistant, але вона не з'являється в DebugView, перевірте ідентифікатор потоку, режим налагодження, згоду користувача та мережну передачу даних.

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

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

Тому під час перевірки я дивлюся не лише на статус Tags Fired. Мені важливо переконатися, що подія відбулася саме після потрібної дії користувача, надіслалася один раз, містить правильні параметри і з'явилася в GA4. Тільки після такої перевірки дані можна використовувати для оцінки ефективності SEO та реклами.

Чому теги GTM не спрацьовують та як виправити помилки?

Одна з найпоширеніших проблем при налаштуванні Google Tag Manager – відсутність очікуваної події в аналітиці. Причина може бути в тригері, змінних, контейнері, налаштуваннях згоди або самому коді сайту.

За запитом gtm tags not fired користувачі часто шукають пояснення однойменного статусу в Tag Assistant. Однак спочатку необхідно визначити, чи дійсно тег повинен був запуститися під час обраної події.

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

Що означає статус Tags Not Fired?

Статус Tags Not Fired означає, що тег не був запущений для вибраної події або набору подій, що розглядається. Сам по собі такий статус не вказує на помилку конфігурації.

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

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

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

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

Неправильні тригери та змінні

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

Аналогічна ситуація виникає зі змінними. Якщо тригер очікує form_type = consultation, а сайт передає form_type = appointment, потрібна умова не виконується.

Для діагностики відкрийте подію в Tag Assistant та перевірте значення на вкладці Variables. Потім порівняйте їх із умовами запуску тега.

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

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

Помилки контейнера, публікації та згоди користувача

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

Ще одна причина – зміни збережені у робочій області, але не опубліковані. У Preview нова конфігурація може працювати, тоді як звичайні відвідувачі продовжують використовувати попередню версію контейнера.

На передачу даних також впливають блокувальники реклами, обмеження браузера та політика Content Security Policy. Окремо перевіряють роботу Consent Mode та підключеної системи керування згодою.

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

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

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

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

Далі перевірте конфігурацію послідовно:

1. Знайдіть відповідний тег. Відкрийте Tags Not Fired і переконайтеся, що ви перевіряєте подію, для якої тег повинен запускатися.
2. Вивчіть тригери. Перевірте всі умови запуску, включаючи фільтри URL, кліків та користувацьких подій.
3. Подивіться значення змінних. Порівняйте фактичні дані з тими, які очікує тригер або конфігурація тега.
4. Перевірте згоду. Вивчіть Consent Settings та можливі обмеження з боку CMP.
5. Перевірте публікацію. Переконайтеся, що потрібна версія контейнера опублікована та завантажується на сторінці.
6. Перевірте передачу даних. Перегляньте Network і DebugView, якщо тег запускається, але аналітика не показує подію.

Часті причини помилок можна звести в таблицю:

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

Як безпечно керувати тегами Google Tag Manager?

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

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

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

Керування версіями та доступами

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

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

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

Також варто використовувати єдині правила іменування. Назви GA4 – purchase, Ads – Lead Conversion та Meta – PageView значно зрозуміліші за випадкові позначення на зразок Tag 14 або New Tag.

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

Consent Mode та захист даних користувачів

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

У Google Consent Mode передбачені параметри:

• analytics_storage – управління згодою на зберігання даних, пов'язаних з аналітикою.
• ad_storage – згода на зберігання даних, використовуваних для рекламних цілей.
• ad_user_data – згода на використання користувацьких даних для рекламних цілей Google.
• ad_personalization – згода на застосування даних для персоналізації реклами.

Для збору та передачі вибору користувача зазвичай використовують банер згоди або платформу Consent Management Platform (CMP). Налаштування повинні відповідати чинним вимогам та фактичним процесам обробки даних.

Consent Mode не замінює політику конфіденційності або механізм отримання згоди. Також не можна передавати в Google Analytics особисті дані, заборонені правилами сервісу.

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

Як теги впливають на швидкість та SEO сайту?

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

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

Для перевірки використовують Chrome DevTools та PageSpeed Insights. Особливу увагу приділяють часу виконання JavaScript, завантаженню сторонніх ресурсів та метрикам Core Web Vitals, включаючи INP.

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

З точки зору SEO коректне налаштування GTM корисне насамперед для вимірювання результатів. Воно допомагає аналізувати звернення, покупки та поведінку відвідувачів, але прямого підвищення позицій у пошуку від встановлення тегів не слід очікувати.

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

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

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