Встановлення Google Analytics 4 через Google Tag Manager

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

Зв'язка Google Analytics і GTM корисна і для простої статистики, і для повноцінної аналітики дій користувача. Після базової установки можна відстежувати відправлення форм, кліки по телефону, завантаження файлів, глибину прокручування, початок оформлення замовлення та купівлю. Перед публікацією кожне налаштування бажано перевірити через Preview Mode, Google Tag Assistant, Realtime та DebugView.

Що таке Google Analytics 4 та Google Tag Manager?

Google Analytics 4 збирає дані про відвідування, події та дії користувачів, після чого показує їх у звітах. У GA4 можна аналізувати джерела трафіку, сторінки входу, ключові події, послідовності дій, покупки та інші показники. Для сайту створюється окремий потік даних Web Data Stream, який отримує власний ідентифікатор вимірювання.

Google Tag Manager працює на іншому рівні. GTM зберігає теги, тригери та змінні, визначає момент їх запуску та передає дані підключеним системам. Менеджер тегів не замінює звіти Google Analytics і не використовується як окрема система вебаналітики. Тому запити google analytics tag manager або tag manager analytics зазвичай стосуються саме спільної роботи двох сервісів.

Чим Google Analytics відрізняється від Google Tag Manager?

Головна відмінність пов'язана з призначенням сервісів. Google Analytics приймає події, обробляє їх та будує звіти, а Google Tag Manager відповідає за технічний запуск тегів на сайті. Коли користувач натискає кнопку або відправляє форму, GTM може зафіксувати дію за заданим тригером і відправити подію в GA4.

При налаштуванні google tag manager with google analytics обидва інтерфейси використовуються послідовно. Спочатку спеціаліст створює ресурс та потік даних у GA4, потім встановлює або відкриває GTM, додає Google tag та після перевірки публікує контейнер. Фінальна перевірка знову проходить у Google Analytics, де мають з'явитись реальні тестові події.

Навіщо використовувати Google Tag Manager разом із Google Analytics?

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

Через один GTM container можна управляти GA4, Google Ads та іншими дозволеними рекламними тегами. Налаштування Google Analytics через GTM також спрощує роботу з dataLayer, користувацькими подіями та параметрами. Для розробника це означає менше розрізнених вставок у шаблонах, а для аналітика – зрозумілу схему відстеження та єдине місце для перевірки тригерів.

Google tag, gtag.js та Google Tag Manager – у чому різниця?

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

Google Tag Manager додає рівень керування між сайтом та системами аналітики. Через нього можна встановити Google tag, налаштувати GA4 Event, використовувати змінні, створювати тригери та перевіряти зміни до публікації. Запити google tag script, google tag html і google tag install часто стосуються прямого встановлення, тоді як google tag manager for google analytics передбачає керування аналітикою з контейнера GTM.

Що потрібно перед встановленням GA4 через GTM?

Перед тим, як виконувати install GA4 with Google Tag Manager, потрібно перевірити початкову конфігурацію проєкту. Користувач повинен мати доступ до ресурсу Google Analytics 4 і контейнера Google Tag Manager, а GTM-код повинен коректно завантажуватися на сторінках сайту. Якщо контейнер ще не створений, спочатку його реєструють і встановлюють у шаблон сайту.

Також знадобиться Web Data Stream для домену, який планується відстежувати. З його налаштувань беруть ідентифікатор, пов'язаний із потрібним ресурсом GA4. Якщо в обліковому записі кілька сайтів або потоків, особливо корисно заздалегідь перевірити домен та destination, щоб не відправити реальні дані в чужий чи тестовий ресурс.

Перед початком налаштування рекомендується перевірити чотири речі:

• ресурс Google Analytics 4 створений саме для потрібного проєкту та доступний фахівцю з необхідними правами;
• Web Data Stream пов'язаний з правильним доменом та містить актуальний Measurement ID;
• контейнер Google Tag Manager встановлений на всіх шаблонах, які мають брати участь в аналітиці;
• старі лічильники та тестові теги знайдені заздалегідь, щоб після запуску виключити подвійне надсилання подій.

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

Як створити ресурс GA4 та потік даних?

Якщо ресурсу GA4 немає, його створюють в адміністративному розділі Google Analytics. Після цього для сайту додають потік типу Web, вказують домен та отримують налаштування збору даних. Один ресурс може містити кілька потоків, тому при роботі з кількома доменами не можна копіювати ідентифікатор з першого Web Data Stream, що трапився.

Для базового налаштування достатньо переконатися, що потік створений для потрібного сайту і доступний його Measurement ID. Додаткові параметри Enhanced Measurement можна перевірити у тому самому розділі. Вони впливають на автоматичний збір деяких дій, тому перед ручним налаштуванням scroll, outbound click або file download варто подивитися, які події вже включені.

Де знайти Measurement ID та Tag ID?

Measurement ID знаходиться в налаштуваннях потоку даних сайту і зазвичай виглядає як G-XXXXXXXXXX. Цей ідентифікатор пов'язує події із конкретним Web Data Stream. Його часто шукають за запитами «ідентифікатор відстеження облікового запису Google Analytics», хоча в GA4 коректніше говорити про ідентифікатор вимірювання конкретного потоку.

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

Чим Tag ID відрізняється від Measurement ID?

Плутанина між Tag ID та Measurement ID часто з'являється під час читання старих та нових інструкцій одночасно. В актуальній конфігурації базовий тег Google створюється з ідентифікатором тега, а окремий Google Analytics: GA4 Event відправляє подію в потрібне призначення GA4. В інтерфейсі конкретні поля можуть залежати від типу тега, що створюється, і поточної версії GTM.

Якщо після налаштування GA4 GTM показує спрацювання тега, а в Analytics даних немає, насамперед варто перевірити вибраний ідентифікатор та destination. Декілька схожих Tag ID в одному обліковому записі не означають, що будь-який з них приведе до потрібного ресурсу. Надійна перевірка включає Preview, Tag Assistant та перегляд події в DebugView.

Що таке Tracking ID та чому старі інструкції відрізняються?

У старих матеріалах часто зустрічається Tracking ID формату UA-XXXXXXXX-X. Такий ідентифікатор використовувався в Universal Analytics, тому інструкції з UA Tracking ID не можна переносити без перевірки на новий проєкт GA4. Запити universal analytics tag manager та google tag manager universal analytics досі трапляються, хоча вони описують попередню версію Analytics.

Для нової установки використовується Google Analytics 4. Якщо на сайті зберігся старий UA-код, його потрібно враховувати під час аудиту, але переносити цю схему в нове налаштування не потрібно. Особливо уважно варто ставитись до інструкцій, де основним тегом вказано старий GA4 Configuration tag без згадки про актуальний Google tag.

Як встановити Google Analytics 4 через Google Tag Manager?

Установка починається з перевірки контейнера GTM, потім у ньому створюється базовий Google tag і задається умова запуску. Після збереження змін потрібно відкрити Preview Mode, переконатися у правильній роботі тега і лише потім публікувати нову версію контейнера. Простого натискання Save недостатньо, тому що збережена робоча область ще не працює для звичайних відвідувачів сайту.

Логіка передачі виглядає так:

Сайт → контейнер GTM → Google tag → Google Analytics 4

Для окремих дій додається ще один рівень:

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

Таку схему зручно використовувати як основу налаштування google analytics and gtm. Вона показує, де шукати помилку: на стороні дії користувача, умови спрацьовування, тега або отримання події в GA4.

Крок 1. Перевірте встановлення контейнера Google Tag Manager на сайті

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

Найзручніше відкрити сайт через Preview Mode або перевірити контейнер за допомогою Tag Assistant. Якщо GTM не визначається, переходити до налаштування Google Analytics безглуздо. Спочатку потрібно виправити установку самого контейнера, очистити кеш за необхідності та перевірити, що production-сторінки отримують актуальну версію шаблону.

Крок 2. Створіть Google tag у GTM

У робочій області GTM відкрийте розділ Tags, створіть новий тег та виберіть Google Tag. Назву краще робити зрозумілою всій команді, наприклад GA4 – Google Tag – All Pages. У назві корисно вказати систему, призначення та область запуску, тому що згодом контейнер може містити десятки тегів зі схожими функціями.

Після вибору типу тега потрібно вказати ідентифікатор, пов'язаний із потрібним Google Analytics 4. Старі інструкції можуть пропонувати GA4 Configuration tag, але в актуальній структурі Google tag виконує базову функцію конфігурації. Такий підхід краще відповідає нинішній логіці Google Tag Manager and GA4.

Крок 3. Додайте ідентифікатор Google Analytics

Скопіюйте Tag ID або інший ідентифікатор, який пропонує актуальне налаштування Google tag для вибраного ресурсу. Не вводьте випадковий код із іншого потоку, тестового ресурсу або старого Universal Analytics. Помилка на цьому етапі часто непомітна в GTM, тому що сам тег може запускатися технічно без явного повідомлення про неправильний destination.

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

Крок 4. Налаштуйте тригер

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

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

Крок 5. Збережіть та протестуйте тег

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

Успішний статус Fired показує, що GTM виконав умову запуску, але фінальну перевірку на цьому закінчувати зарано. Дані мають дійти до Google Analytics. Тому після Preview потрібно відкрити Realtime або DebugView і переконатися, що тестовий користувач та події дійсно відображаються у потрібному ресурсі.

Крок 6. Опублікуйте контейнер

Після успішного тестування натисніть Submit та створіть нову версію контейнера. Для назви версії краще коротко описати зміну, наприклад, GA4 base tag або GA4 events for forms. Така історія допомагає швидко зрозуміти, що саме потрапило у production, особливо якщо з GTM працюють кілька фахівців.

Після публікації повторіть перевірку вже без Preview Mode. Відкрийте звичайну сторінку сайту, виконайте тестову дію та перегляньте Realtime. Збережене налаштування та опубліковане налаштування – різні стани GTM, тому забутий Publish залишається однією з простих причин, з яких google analytics gtm code не дає очікуваних даних.

Як перевірити, що Google Analytics працює через GTM?

Перевірка повинна охоплювати і GTM, і Google Analytics 4. У контейнері потрібно переконатися, що тег запускається при потрібній події, а в GA4 – що ця подія прийнята з правильними параметрами. Один інструмент не показує весь ланцюжок, тому діагностика тільки через статус Fired часто пропускає помилки.

Для базової установки зручно пройти три рівні: Tag Assistant показує роботу тегів, Realtime підтверджує надходження живих даних, DebugView допомагає детально перевірити події та їх параметри. Якщо використовуються форми, e-commerce або dataLayer, тест потрібно проводити на реальному сценарії користувача від початку дії до отримання події в GA4.

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

Preview Mode підключає браузер до вибраної робочої області GTM та показує послідовність подій на сторінці. У Tag Assistant можна побачити, які теги спрацювали, які залишилися в стані Not Fired і яка умова завадила запуску. Це особливо корисно для кліків, форм і користувацьких подій dataLayer.

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

Перевірка даних у Realtime

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

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

Перевірка подій через DebugView

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

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

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

Я вважаю налаштування GA4 завершеним після перевірки всього ланцюжка, а не після появи статусу Fired у Google Tag Manager. Я додатково дивлюся подію у Tag Assistant, Realtime та DebugView. Такий порядок допомагає помітити неправильний Measurement ID, подвійне надсилання page_view або збережену, але не опубліковану версію контейнера.

Чому Google Analytics не отримує даних із Google Tag Manager?

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

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

Використано неправильний Tag ID або Measurement ID

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

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

Контейнер GTM не опубліковано

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

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

Google tag не спрацьовує на всіх сторінках

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

Перевіряйте кілька типів сторінок, а не лише головну. У Tag Assistant порівняйте запуск Google tag на категорії, картці, формі та сторінці підтвердження. Якщо ви використовуєте винятки за Page URL або hostname, переконайтеся, що вони дійсно відповідають поточній структурі проєкту.

На сайті встановлено кілька однакових тегів

Дублі з'являються після паралельного встановлення Google Analytics через код сайту, CMS-плагін та GTM. У такому випадку один page_view може відправлятися двічі, а ключові події отримують завищені значення. Проблема особливо помітна після редизайну чи міграції, коли стару інтеграцію забувають видалити.

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

Події блокуються Consent Mode або налаштуваннями cookies

Якщо на сайті використовуються CMP та Consent Mode, поведінка тега залежить від вибору користувача та поточного режиму згоди. Тому тестування в браузері з уже збереженими cookies може давати інший результат, ніж перевірка в чистому профілі. Умови consent потрібно враховувати під час аналізу тегів, які не запускаються.

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

Браузер чи розширення блокує аналітику

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

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

Як налаштувати події Google Analytics 4 через Google Tag Manager?

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

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

Які події GA4 збирає автоматично?

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

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

Що таке Enhanced Measurement?

Enhanced Measurement розширює автоматичний збір дій для вебпотоку. У налаштуваннях можна зустріти прокручування сторінки, зовнішні переходи, внутрішній пошук, завантаження файлів та взаємодії із вбудованим відео. Конкретний набір необхідно перевіряти в інтерфейсі поточного Web Data Stream.

Якщо Enhanced Measurement вже надсилає scroll або outbound click, другий схожий тег через GTM створюється лише за окремої аналітичної задачі. Наприклад, стандартного прокручування може бути недостатньо, якщо проєкту потрібні рівні 25%, 50%, 75% і 90%. У такому випадку користувацька подія повинна мати інше зрозуміле призначення.

Як створити користувацьку подію через GTM?

Спочатку визначають дію, яку можна надійно зафіксувати. Потім створюють trigger, додають тег Google Analytics: GA4 Event, задають Event Name та потрібні event parameters. Після налаштування виконують дію в Preview Mode і перевіряють, що подія дійшла до DebugView з очікуваними значеннями.

Робоча послідовність виглядає так:

1. Визначити користувацьку дію та її аналітичну цінність.
2. Вибрати надійний сигнал для trigger у Google Tag Manager.
3. Створити GA4 Event зі зрозумілим та стабільним Event Name.
4. Додати параметри через змінні GTM або dataLayer.
5. Перевірити подію через Preview Mode та Google Tag Assistant.
6. Переконатися, що дані з'явилися в DebugView потрібного ресурсу.
7. Опублікувати контейнер та повторити тест у production.

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

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

Для кліку на кнопку можна використовувати вбудовані click variables, якщо елемент стабільно визначається за ID, класом, текстом або URL. Trigger має відрізняти потрібну кнопку від інших елементів сторінки. Якщо один текст використовується в кількох місцях, краще додати розробнику окремий технічний атрибут для аналітики.

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

Приклад: відправлення форми

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

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

Приклад: глибина прокручування

Стандартний Enhanced Measurement фіксує прокручування за власною логікою, але для контентних проєктів іноді потрібні додаткові рівні. У GTM можна налаштувати Scroll Depth Trigger та передавати значення 25%, 50%, 75% та 90%. Ці дані допомагають зрозуміти, наскільки глибоко користувачі переглядають довгу сторінку.

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

Як передавати параметри подій

Параметри додають контекст до події. Для кліка це може бути link_url, для форми – form_name, для покупки – transaction_id, value та currency. Значення можна отримувати із вбудованих змінних GTM, DOM, URL або dataLayer залежно від технічної реалізації сайту.

Передавати персональні дані користувачів у GA4 через event parameters не слід. Email, номер телефону, ім'я та інші ідентифікаційні відомості, потрібно виключати з аналітичної схеми. Якщо dataLayer містить такі дані для внутрішніх завдань сайту, змінні GA4 повинні вибирати тільки безпечні параметри.

Custom Definitions у GA4

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

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

Що таке dataLayer і навіщо він потрібний для GA4?

dataLayer є структурованим шаром даних, через який сайт може передавати в GTM події та значення. Замість спроби зчитувати ціну, ID товару або статус замовлення з візуальної розмітки, розробник відправляє готові дані в зрозумілій структурі. GTM отримує їх через Data Layer Variable та передає далі в GA4.

Для базового кліка dataLayer може не знадобитися. Для e-commerce, авторизації, складних форм та внутрішніх станів застосунку такий спосіб набагато надійніший роботи з DOM. Запит gtm ga4 datalayer зазвичай стосується саме цієї зв'язки: сайт формує дані, GTM обробляє подію, а GA4 отримує готові параметри.

Як GTM отримує дані з dataLayer?

Розробник відправляє об'єкт із подією та потрібними значеннями через dataLayer.push. GTM бачить ім'я події, запускає Custom Event Trigger та зчитує параметри через змінні. Після цього GA4 Event отримує готові значення та надсилає їх до Google Analytics 4.

Умовна структура може мати такий вигляд:

event: purchase
transaction_id: 12345
value: 2500
currency: UAH

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

Коли без dataLayer можна обійтися?

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

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

Коли dataLayer необхідний?

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

Особливо корисний цей підхід для SPA та складних форм. Користувач може залишитися на тому ж URL, хоча всередині застосунку вже відбулася значуща подія. Custom Event у dataLayer повідомляє GTM про таку зміну незалежно від перезавантаження сторінки та зовнішнього вигляду елемента.

GA4 e-commerce через GTM та dataLayer

Для електронної торгівлі GA4 використовує набір рекомендованих подій. Серед них view_item, add_to_cart, view_cart, begin_checkout, add_payment_info, purchase та refund. Разом з ними передаються параметри замовлення та масив товарів, якщо вони потрібні для конкретної події.

Особливу увагу слід приділити purchase. Подія повинна відправлятися після підтвердженої покупки та містити стабільний transaction_id, щоб знизити ризик повторного обліку однієї транзакції. Значення value передається числом, а currency – окремим кодом валюти.

Consent Mode та конфіденційність при установці GA4

Якщо сайт використовує механізм згоди на cookies, роботу GA4 та рекламних тегів потрібно перевіряти разом із ним. CMP зберігає вибір користувача, а Consent Mode передає стан згоди тегам Google. Поведінка аналітики при згоді та відмові може відрізнятися, тому тестування слід проводити в обох сценаріях.

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

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

Server-side Google Tag Manager та GA4

Server-side GTM додає серверний контейнер між браузером користувача та системами, що отримують події. Браузер відправляє запит на server container, після чого той обробляє дані та передає їх далі. Така архітектура вимагає окремої інфраструктури, домену або піддомена, налаштування клієнтів, тегів та контролю запитів.

Для звичайного невеликого сайту починати аналітику з server-side GTM необов'язково. Спочатку корисніше впорядкувати web container, події, dataLayer, consent і перевірку даних. Якщо проєкт зріс, працює з більшим обсягом e-commerce даних або потребує більш керованої серверної схеми, тоді server-side розглядається як окремий етап.

Чим server-side GTM відрізняється від звичайного GTM?

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

Схема виглядає так:

Браузер → Web GTM → Server GTM → GA4

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

Коли server-side GTM має сенс?

Server-side tagging частіше розглядають для e-commerce, SaaS та великих сайтів із розвиненою аналітикою. Причинами можуть бути контроль маршруту даних, робота з first-party інфраструктурою, необхідність централізованої обробки запитів і велика кількість маркетингових інтеграцій.

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

Параметр server_container_url

Під час зв'язування web GTM і server-side контейнера використовується адреса серверного endpoint. У налаштуваннях Google tag для цього може використовуватися параметр server_container_url. Він вказує, куди браузерна частина повинна надсилати відповідні запити перед подальшою обробкою.

Перед зміною маршруту спочатку перевіряють роботу самого server container, DNS, SSL і прийом запитів. Після перемикання знову тестують події в Preview та GA4. Для production-проєкту таку міграцію краще виконувати поетапно, щоби можна було порівняти результати до і після зміни маршруту.

Google Tag Manager та Universal Analytics

Universal Analytics часто зустрічається в старих інструкціях зі встановлення Google Analytics через GTM. У таких матеріалах використовуються UA Tracking ID, Universal Analytics tags та колишня модель цілей. Для нового проєкту ця схема не підходить, тому що основною актуальною платформою Google Analytics є GA4.

Старі запити google tag manager and universal analytics, gtm universal analytics або tag manager universal analytics корисні лише для розуміння попередньої реалізації та аудиту legacy-коду. Якщо такий тег знайдено на діючому сайті, його потрібно враховувати під час очищення контейнера та перевірки дублів.

Чи можна зараз встановити Universal Analytics через GTM?

Для нової аналітичної системи використовувати Universal Analytics не слід. Standard Universal Analytics припинив обробку нових даних 1 липня 2023 року, а основна міграція проєктів давно завершена. Нове налаштування має будуватися навколо Google Analytics 4 та актуальних типів тегів.

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

Google Tag Manager vs Universal Analytics – що неправильно порівнюють?

Google Tag Manager та Universal Analytics належать до різних категорій продуктів. GTM управляє кодами та умовами запуску, а Universal Analytics була системою вебаналітики. Тому запит google tag manager vs universal analytics містить порівняння сервісів із різним призначенням.

Коректна сучасна зв'язка виглядає як Google Tag Manager + Google Analytics 4. GTM відповідає за технічну реалізацію тегів та подій, а GA4 приймає дані та використовується для аналізу. Такий самий принцип допомагає розібратися в запитах google tag manager in google analytics або analytics tag manager.

Чек-лист налаштування Google Analytics 4 через GTM

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

Перевірте такі пункти:

• ресурс GA4 і необхідний Web Data Stream призначені для правильного домену;
• контейнер Google Tag Manager встановлений на всіх потрібних шаблонах сайту;
• Google tag використовує ідентифікатор потрібного ресурсу та destination;
• базовий trigger запускає тег у передбачених сценаріях;
• Preview Mode та Tag Assistant не показують несподіваних дублів;
• тестові події з'являються в Realtime та DebugView;
• custom events передають необхідні параметри без персональних даних;
• Enhanced Measurement не дублюється користувацькими тегами без причини;
• e-commerce події отримують коректні value, currency та transaction_id;
• consent перевірено до та після вибору користувача;
• стара аналітика та зайві плагіни не відправляють другий набір подій;
• робоча область збережена, протестована та опублікована новою версією.

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

Google Analytics 4 через Google Tag Manager зручніше налаштовувати як послідовну систему: спочатку коректний контейнер, потім Google Tag, після нього події та параметри. Кожен новий елемент потрібно перевіряти до публікації та повторно тестувати вже на production-сайті. Такий підхід знижує ризик дублів, неправильних ідентифікаторів та втрати важливих дій користувачів.

Якщо на сайті вже встановлено кілька лічильників, старі UA-теги, рекламні пікселі та власний dataLayer, починати краще з аудиту поточної конфігурації. Після перевірки можна зібрати чисту структуру GTM, налаштувати GA4, події, e-commerce та перевірити дані через Tag Assistant, Realtime та DebugView.

Потрібне коректне налаштування Google Analytics 4 через Google Tag Manager – передайте спеціалісту доступ до GA4, GTM та тестового сайту. Після аудиту можна визначити, які теги залишити, які події додати та де потрібно доопрацювання dataLayer.