Що ми дізналися на вебінарі Stape про Google Tag Gateway та серверне відстеження
Для нас це був не просто «огляд нової функції», а дуже практичний аналіз того, як сьогодні змінюється first-party measurement.
Чому ця тема взагалі стала такою важливою
Одна з головних думок вебінару — прогалини у відстеженні вже стали нормою: обмеження браузерів, відмова від відстеження в iOS, блокувальники реклами та розриви між браузерним і серверним вимірюванням погіршують атрибуцію та заважають оптимізації. У самій презентації спікери прямо показують, що через це бізнес втрачає частину конверсійних сигналів, а server-side tracking розглядається як додатковий шар, який може очищати, доповнювати, анонімізувати та маршрутизувати дані перед відправкою в рекламні та аналітичні системи. Це збігається і з тим, як server-side tagging описує сама Google: поліпшення якості даних, більш детальний контроль приватності та окремий серверний шар для роботи з сигналами.
Для нас це особливо актуально, тому що сьогодні майже будь-який performance-проект спирається вже не стільки на налаштування «ще одного тегу», скільки на стійкість сигналу. Коли рекламні системи отримують неповні події, страждає не тільки звітність, але й smart bidding, аудиторії, value-based optimization та прийняття рішень загалом. Саме тому тема GTG та sGTM перестала бути вузькотехнічною — це вже питання ефективності маркетингу як такого.
Найкориснішим для нас є дуже чіткий розподіл ролей між Google Tag Gateway та серверною версією Google Tag Manager. Згідно з офіційною документацією, Google Tag Gateway for advertisers дозволяє передавати теги Google через власну інфраструктуру first-party на домені сайту — через CDN, load balancer або веб-сервер. Тобто, по суті, це first-party delivery для тегів Google. У презентації та ж думка сформульована ще жорсткіше: GTG — це serving and forwarding для Google-native measurement, тоді як server-side GTM — це повноцінний processing layer, де можна контролювати, збагачувати, редагувати, фільтрувати та маршрутизувати дані одразу в кілька рекламних та аналітичних платформ. Для нас саме це і стало головним «розвіюванням плутанини»: GTG не замінює sGTM за рівнем архітектури, а вирішує більш вузьке завдання.
Другий важливий момент: ці підходи не завжди потрібно протиставляти один одному. У документації Google прямо сказано, що якщо використовувати server-side tagging, то Google tag gateway можна підключати як частину «most durable tagging setup». Іншими словами, GTG цілком може бути першим кроком або додатковим first-party шаром поверх уже налаштованої server-side схеми, а не лише «альтернативою для ледачих». Для нас це важливий нюанс, тому що на практиці зрілі проєкти рідко живуть у логіці «або/або» — частіше йдеться про правильну комбінацію рівнів вимірювання.
Що виявилося найкориснішим у Q&A
Перший важливий висновок із Q&A — налаштування на основі шляху одного походження (same-origin path-based setup) є важливішим, ніж багато хто думає. В офіційній документації щодо налаштування власного домену Google називає це найкращою практикою (same-origin best practice) і окремо підкреслює, що саме такий варіант забезпечує переваги в плані безпеки та довговічності серверних файлів cookie. Якщо сервер тегування розміщений на стандартному хмарному кінцевому пункті, цих переваг немає. Для нас це означає просту річ: якщо проект реально стикається з проблемами Safari, ITP та довговічністю ідентифікаторів, то дивитися потрібно не тільки на те, «чи ввімкнули GTG», а на всю схему first-party serving цілком — із сервером, власним доменом та path-based routing на кшталт /metrics.
Другий висновок — GTG не варто сприймати як срібну кулю проти ad blockers і browser restrictions. У презентації GTG показано як рішення з обмеженим захистом від блокувальників і без повноцінного ITP bypass, а незалежні практики підтверджують, що частина запитів може, як і раніше, надходити на Google endpoints безпосередньо і що більш «розумні» блокувальники все ще розпізнають такий трафік. Якщо для проєкту критична максимальна стійкість трекінгу, міцнішою базою залишається повноцінний sGTM з first-party custom domain, а в інфраструктурах на кшталт Stape додатковий захист забезпечують custom loaders і power-ups, які спеціально спрямовані на зменшення втрат від ad blockers.
Третій висновок із Q&A нам особливо сподобався своєю практичністю: GTG — це історія про Google-стек, а не про весь martech stack відразу. Так, він охоплює Google tag, GTM, Google Ads, GA4, а через налаштування Google tag доступний і для Campaign Manager 360 / Floodlight. Але як тільки бізнесу потрібне multi-platform measurement — Meta, TikTok, CRM, call tracking, payment status, офлайн-конверсії або Pinterest CAPI — однієї логіки GTG вже недостатньо. У цьому сенсі дуже показовим є приклад з Pinterest: офіційна документація Pinterest рекомендує direct/server-to-server integration для більшого контролю і вимагає deduplication через event_id, якщо Tag і Conversions API використовуються разом. Така orchestration-логіка значно ближча до повноцінної server-side архітектури, ніж до GTG-only setup.
Як це впливає на нашу оцінку GTG та sGTM у клієнтах WAMP
Після цього вебінару ми в WAMP ще чіткіше розмежували, в яких проєктах GTG дійсно дає швидкий результат, а де відразу варто переходити на sGTM. Якщо у бізнесу порівняно простий стек, основна залежність — від продуктів Google, є доступ до CDN або іншої інфраструктури для маршрутизації, і завдання полягає в тому, щоб швидко посилити first-party measurement без повної перебудови трекінгу, GTG виглядає як чудовий quick win. Google спростив налаштування через інтерфейси Google Ads, GA4 і GTM, окремо підтримав інтеграцію з Cloudflare, а в травні 2025 року Google Ads Help посилався на середній uplift у 11% сигналів у тих рекламодавців, хто вже увімкнув Google tag gateway for advertisers.
Але якщо у проєкту складна атрибуція, кілька рекламних платформ, вимоги до анонімізації та управління даними, необхідність обмежувати, збагачувати або фільтрувати події, а також боротьба за стійкість у Safari та більш довговічні файли cookie, ми, як і раніше, вважаємо правильним звертати увагу на server-side GTM. Тут позиція Google теж досить однозначна: server-side tagging дає більш детальні налаштування конфіденційності та допомагає покращити якість даних, а same-origin custom domain — це найкраща практика саме завдяки перевагам server-set cookie та first-party context. Іншими словами, GTG — хороший рівень покращення сигналу, але sGTM — це вже рівень контролю над даними.
Окремо для нас цінним виявився інфраструктурний висновок із Q&A: GTG сильно залежить від того, чи контролює бізнес свій routing-шар. Офіційні матеріали Google прямо говорять про CDN, load balancer або web server як обов’язкову частину схеми. Отже, на платформах, де доступ до таких налаштувань обмежений або прихований усередині закритої інфраструктури, first-party path-based implementation може бути ускладненим. З практичної точки зору це означає, що на етапі пресейлу та аудиту потрібно оцінювати не тільки маркетингові завдання, а й технічну свободу проєкту.
Обмеження GTG
Втрата даних
Гнучкість
sGTM
Дедуплікація
Для нас головний практичний висновок вебінару такий: GTG — це не «новий sGTM», а зручний first-party gateway для Google measurement. Він особливо корисний там, де потрібне швидке й точне оновлення Google-стека без значної перебудови архітектури. Але якщо завдання ширше — мультиплатформове відстеження, стійкість до обмежень браузерів, суворий контроль над даними, дедуплікація між джерелами, офлайн- та CRM-сигнали, серверно керовані cookies і більш серйозна логіка конфіденційності — повноцінний sGTM, як і раніше, залишається більш потужною та гнучкою базою.
І ще один висновок, який ми точно беремо до уваги: будь-які міграції та апгрейди трекінгу не можна включати «наосліп». І Google, і Pinterest у своїх матеріалах окремо роблять акцент на валідації сетапу — через Tag Assistant, Test Events, перевірку event flow та дедуплікацію. Тому наш підхід після цього вебінару тільки зміцнився: спочатку архітектура, потім QA, потім перехід на production, а не навпаки. Саме така дисципліна зазвичай і визначає, чи поліпшить нова схема дані на практиці, чи просто додасть ще один рівень складності у звіти.
Висновок
Якщо підсумувати все в одній думці, то для нас цей вебінар виявився цінним не тому, що показав «ще одне налаштування в інтерфейсі Google», а тому, що дуже чітко продемонстрував зрілість підходів. Google Tag Gateway — це хороший інструмент для first-party доставки Google-тегів та зміцнення сигналу. Server-side GTM — це вже повноцінна архітектура data layer зі своїм рівнем контролю, гнучкості та стійкості. А отже, правильне питання для бізнесу звучить не «що модніше — GTG чи sGTM?», а «який рівень вимірювання потрібен саме нашому проєкту зараз».
