Что мы узнали на вебинаре Stape о Google Tag Gateway и server-side tracking
Для нас это был не просто “апдейт по новой функции”, а очень прикладной разбор того, как сегодня меняется first-party measurement.
Почему эта тема вообще стала настолько важной
Одна из главных мыслей вебинара — tracking gaps уже стали нормой: ограничения браузеров, iOS opt-outs, блокировщики рекламы и разрывы между браузерным и серверным измерением ухудшают атрибуцию и ломают оптимизацию. В самой презентации спикеры прямо показывают, что из-за этого бизнес теряет часть конверсионных сигналов, а server-side tracking рассматривается как дополнительный слой, который может очищать, дополнять, анонимизировать и маршрутизировать данные перед отправкой в рекламные и аналитические системы. Это совпадает и с тем, как server-side tagging описывает сама Google: улучшение качества данных, более детальный контроль приватности и отдельный серверный слой для работы с сигналами.
Для нас это особенно актуально, потому что сегодня почти любой performance-проект упирается уже не столько в настройку “ещё одного тега”, сколько в устойчивость сигнала. Когда рекламные системы получают неполные события, страдает не только отчётность, но и smart bidding, аудитории, value-based optimization и принятие решений в целом. Именно поэтому тема GTG и sGTM перестала быть узкотехнической — это уже вопрос эффективности маркетинга как такового.
Самое полезное для нас — очень чёткое разделение ролей между Google Tag Gateway и server-side Google Tag Manager. По официальной документации, Google Tag Gateway for advertisers позволяет отдавать Google tag через собственную first-party infrastructure на домене сайта — через CDN, load balancer или web server. То есть по сути это first-party delivery для Google-тегов. В презентации та же мысль сформулирована ещё жёстче: GTG — это serving and forwarding для Google-native measurement, тогда как server-side GTM — это полноценный processing layer, где можно контролировать, enrich, redact, filter и route data сразу в несколько ad и analytics platforms. Для нас именно это и стало главным “снятием путаницы”: 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 важнее, чем многие думают. В официальной документации по custom domain configuration Google называет same-origin best practice и отдельно подчёркивает, что именно такой вариант даёт security and durability benefits server-set cookies. Если tagging server живёт на дефолтном cloud endpoint, этих преимуществ нет. Для нас это означает простую вещь: если проект реально упирается в 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.
Но если у проекта сложная атрибуция, несколько рекламных платформ, требования к anonymization и data governance, необходимость ограничивать, обогащать или фильтровать события, а также борьба за устойчивость в Safari и более долгоживущие cookies, мы по-прежнему считаем правильным смотреть в сторону server-side GTM. Тут позиция Google тоже довольно однозначна: server-side tagging даёт more detailed privacy controls и помогает improve data quality, а same-origin custom domain — это best practice именно из-за server-set cookie benefits и 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-стека без большой перестройки архитектуры. Но если задача шире — multi-platform tracking, устойчивость к ограничениям браузеров, строгий контроль над данными, deduplication между источниками, офлайн- и CRM-сигналы, серверно управляемые cookies и более серьёзная privacy-логика — полноценный sGTM по-прежнему остаётся более сильной и гибкой базой.
И ещё один вывод, который мы точно забираем в работу: любые миграции и апгрейды трекинга нельзя включать “на авось”. И Google, и Pinterest в своих материалах отдельно делают акцент на валидации сетапа — через Tag Assistant, Test Events, проверку event flow и deduplication. Поэтому наш подход после этого вебинара только укрепился: сначала архитектура, потом QA, потом переключение на production, а не наоборот. Именно такая дисциплина обычно и определяет, улучшит ли новая схема данные на практике или просто добавит ещё один уровень сложности в отчёты.
Итог
Если свести всё к одной мысли, то для нас этот вебинар оказался ценным не потому, что показал “ещё одну настройку в интерфейсе Google”, а потому что очень ясно разложил зрелость подходов. Google Tag Gateway — это хороший инструмент для first-party доставки Google-тегов и укрепления сигнала. Server-side GTM — это уже полноценная data layer architecture со своим уровнем контроля, гибкости и устойчивости. А значит, правильный вопрос для бизнеса звучит не “что моднее — GTG или sGTM?”, а “какой уровень измерения нужен именно нашему проекту сейчас”.
