Блог

← Усі статті

Серверний GTM проти клієнтського — коли переходити

1 квітня 2026

TL;DR: Серверний GTM переносить виконання тегів із браузера на хмарний сервер, яким ви керуєте. Це покращує точність даних завдяки обходу блокувальників реклами, подовжує час життя cookies через first-party домен, зменшує вплив на швидкість завантаження та забезпечує краще дотримання згоди користувачів. Компроміс: ви платите за хостинг ($50–$500+/місяць залежно від трафіку), а налаштування складніше. Почніть із переведення GA4 та Facebook CAPI на серверну сторону, залиште прості тригери кліків та прокрутки на клієнтській стороні, і запускайте обидва контейнери паралельно.

Google Tag Manager за замовчуванням працює в браузері. Кожен тег, тригер та змінна виконуються у браузері відвідувача як JavaScript. Це добре працювало понад десять років, але ландшафт змінився. Блокувальники реклами тепер впливають на 30–40% веб-трафіку. Intelligent Tracking Prevention в Safari обмежує час життя cookies до 7 днів. Регуляції конфіденційності вимагають жорсткішого контролю над тим, куди йдуть дані. Серверний GTM вирішує всі три проблеми, переносячи виконання тегів на інфраструктуру, якою ви володієте.

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

Що таке серверний Google Tag Manager?

Серверний GTM — це окремий тип контейнера в Google Tag Manager, який працює на хмарному сервері замість браузера відвідувача. Коли користувач взаємодіє з вашим сайтом, браузер надсилає один запит на ваш серверний ендпоінт. Серверний контейнер обробляє цей запит, створює об'єкт даних події та пересилає дані до кількох платформ — Google Analytics, Google Ads, Meta, TikTok — із серверної сторони.

Серверний контейнер працює на Google Cloud (App Engine або Cloud Run) або будь-якому середовищі, що підтримує Docker-контейнери. Ви налаштовуєте first-party субдомен, наприклад sgtm.yourdomain.com, який вказує на цей сервер. Це означає, що запити виглядають як first-party трафік і для браузера, і для систем захисту від трекінгу.

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

Чим серверний GTM відрізняється від клієнтського?

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

АспектКлієнтський GTMСерверний GTM
Середовище виконанняБраузер відвідувачаВаш хмарний сервер
Завантаження скриптів третіх сторінТак — кожен тег завантажує свій JSНі — сервер пересилає дані через API
Вплив на швидкість сторінкиВищий — більше JS = повільніші сторінкиНижчий — один запит із браузера
Вразливість до блокувальниківВисока — запити до відомих доменів блокуютьсяНизька — first-party домен не блокується
Контроль cookiesОбмежений браузером (ITP, ETP)Повний контроль — сервер встановлює first-party cookies
Видимість данихКористувач може переглядати всі вихідні даніСервер контролює, що пересилається
Складність налаштуванняНизька — вставте сніпет, готовоСередня-Висока — хмарна інфра, DNS, моніторинг
ВартістьБезкоштовно (GTM безкоштовний)Хмарний хостинг: $50–$500+/місяць

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

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

Серверний GTM вирішує п'ять конкретних проблем, які клієнтський трекінг не може подолати:

Які недоліки та вартість серверного GTM?

Серверний GTM не безкоштовний і не простий. Розуміння витрат заздалегідь запобігає сюрпризам:

Як серверний GTM покращує точність даних?

Покращення точності даних забезпечується трьома механізмами:

1. Обхід блокувальників реклами. Дослідження постійно показують, що 15–40% веб-користувачів використовують блокувальники, залежно від аудиторії. Технічна аудиторія може досягати 50%+. Коли ваш аналітичний запит йде на sgtm.yourdomain.com замість www.google-analytics.com, переважна більшість блокувальників пропускає його. Сайти, що переходять на серверне тегування, зазвичай бачать збільшення відстежених сесій на 10–25%.

2. Збереження first-party cookies. Safari ITP скорочує час життя клієнтських cookies до 7 днів. На сайті, де середній інтервал повторного відвідування становить 14 днів, ITP призводить до того, що користувачі Safari виглядають як нові відвідувачі через кожне друге відвідування. Серверні first-party cookies зберігають вказаний вами термін дії (зазвичай 90–400 днів), що коректно з'єднує шляхи користувачів між візитами.

3. Надійна доставка подій. Beacon API та navigator.sendBeacon() допомагають із клієнтською надійністю, але вони не бездоганні. Серверна обробка подій із логікою повторних спроб гарантує, що події конверсій (покупки, реєстрації) доставляються навіть коли браузер закривається до завершення запиту.

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

Як налаштувати серверний контейнер GTM?

Налаштування складається з шести кроків. Заплануйте 2–4 години для першого впровадження:

  1. Створіть серверний контейнер у GTM. Перейдіть на tagmanager.google.com, натисніть Create Container, назвіть його (наприклад, "My Site - Server") та виберіть Server як цільову платформу. GTM пропонує два варіанти розгортання: автоматичний (App Engine від Google) або ручний (власна інфраструктура).
  2. Розгорніть на Google Cloud Run. Для економії використовуйте Cloud Run замість App Engine. Завантажте офіційний образ tagging server (gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable), встановіть змінну середовища CONTAINER_CONFIG із налаштувань серверного контейнера GTM і розгорніть із мінімум 2 інстансами для надійності в продакшені.
  3. Налаштуйте first-party субдомен. Створіть DNS CNAME запис, що направляє sgtm.yourdomain.com на URL вашого Cloud Run сервісу. Потім налаштуйте кастомний домен у Cloud Run із SSL-сертифікатом. Цей крок критичний — без нього ви втрачаєте переваги first-party cookies.
  4. Додайте GA4 клієнт у серверний контейнер. GA4 клієнт приймає вхідні запити measurement protocol від браузера та перетворює їх у уніфікований об'єкт даних події. Додайте його в серверному контейнері в розділі Clients.
  5. Оновіть веб-контейнер. У клієнтському GTM-контейнері змініть transport URL тега GA4 Configuration на https://sgtm.yourdomain.com. Тепер браузер надсилає хіти GA4 на ваш сервер замість прямого відправлення в Google.
  6. Додайте серверні теги. Створіть тег GA4 у серверному контейнері для пересилання подій до Google Analytics. Додайте будь-які додаткові теги (Google Ads Conversion Tracking, Meta Conversions API) за потребою. Використовуйте режим Preview серверного контейнера для перевірки потоку даних від початку до кінця.

GTM Event Helper створює тригери та теги у вашому клієнтському контейнері через GTM API. Незалежно від того, маршрутизуєте ви ці події клієнтською стороною чи через серверний контейнер, конфігурація тригерів і тегів залишається тією ж — змінюється лише transport URL.

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

Не кожен тег однаково виграє від серверного виконання. Пріоритезуйте за впливом:

ПріоритетТип тегаЧому серверний
1 (найвищий)GA4Найбільший приріст точності даних; first-party cookies виправляють ITP; обхід блокувальників повертає 10–25% сесій
2Meta Conversions API (CAPI)Meta вимагає CAPI для оптимальної доставки реклами; серверна дедуплікація з браузерним пікселем; краща якість зіставлення
3Google Ads Conversion TrackingEnhanced conversions із first-party даними; покращена атрибуція для Smart Bidding
4TikTok Events APIТа сама логіка, що й Meta CAPI — платформа все більше покладається на серверні події для оптимізації
5 (нижчий)Теплокарти, A/B тестуванняВони потребують взаємодії з браузером у реальному часі; залишайте клієнтськими

Правило: переносьте теги аналітики та конверсій на серверну сторону. Залишайте теги, що залежать від взаємодії (теплокарти, запис сесій, A/B тестування, чат), клієнтськими, бо вони потребують прямого доступу до DOM.

Як серверний GTM працює з управлінням згодою?

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

Клієнтський збір згоди. Ваша платформа управління згодою (CMP) працює в браузері та збирає вибір згоди користувача. Consent Mode GTM зчитує ці сигнали та коригує поведінку тегів — блокує теги, надсилає безкукові пінги або запускає нормально залежно від стану згоди.

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

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

Google Consent Mode v2 нативно працює з серверним GTM. Серверний контейнер зчитує сигнали згоди analytics_storage, ad_storage, ad_user_data та ad_personalization і застосовує їх до кожного вихідного запиту. Платформи, що вимагають сигналів згоди (Google Ads в EEA, Meta в ЄС), отримують коректний стан згоди автоматично.

Коли варто переходити з клієнтського на серверний GTM?

Серверний GTM потрібен не кожному сайту. Оцініть за такими критеріями:

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

Чи можна використовувати клієнтський і серверний GTM разом?

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

Типова гібридна архітектура:

  1. Клієнтський контейнер обробляє тригери (кліки, прокрутки, відправки форм, видимість елементів) і надсилає події до серверного контейнера через transport URL GA4.
  2. Серверний контейнер приймає події, збагачує їх за потребою (наприклад, додає серверні дані користувача для enhanced conversions) і пересилає до GA4, Google Ads, Meta CAPI та інших платформ.
  3. Деякі теги залишаються клієнтськими. Інструменти теплокарт (Hotjar, Microsoft Clarity), платформи A/B тестування (Optimizely, VWO) та віджети чату потребують доступу до браузера і залишаються в клієнтському контейнері.

Ця гібридна модель дає вам найкраще з обох світів: трекінг взаємодій на рівні браузера з контролем та надійністю даних на рівні сервера. Клієнтський контейнер залишається легким, бо надсилає дані лише на один ендпоінт (ваш сервер), а серверний контейнер займається розподілом до кількох платформ.

Які типові помилки серверного GTM?

Ці помилки найбільше марнують час та спричиняють неточності в даних:

Клієнтський чи серверний — налаштовуйте GTM-події швидше.

Встановити GTM Event Helper

Зовнішні ресурси

Пов'язані статті

← Усі статті · Головна · Політика конфіденційності · Контакти