What We Learned at the Stape Webinar on Google Tag Gateway and Server-Side Tracking
For us, this wasn’t just a “update on a new feature,” but a very practical analysis of how first-party measurement is evolving today.
Why has this issue become so important in the first place?
One of the key takeaways from the webinar is that tracking gaps have become the norm: browser restrictions, iOS opt-outs, ad blockers, and discrepancies between browser-side and server-side measurement are undermining attribution and disrupting optimization. In the presentation itself, the speakers clearly demonstrate that because of this, businesses are losing some conversion signals, and server-side tracking is viewed as an additional layer that can clean, supplement, anonymize, and route data before sending it to advertising and analytics systems. This aligns with how Google itself describes server-side tagging: improved data quality, more granular privacy control, and a separate server-side layer for processing signals.
This is particularly relevant for us because today, nearly every performance project hinges not so much on configuring “yet another tag” as on signal stability. When advertising systems receive incomplete events, not only reporting suffers, but also smart bidding, audiences, value-based optimization, and decision-making in general. This is precisely why the topic of GTG and sGTM is no longer strictly technical—it is now a matter of marketing effectiveness itself.
The most useful aspect for us is the very clear division of roles between Google Tag Gateway and server-side Google Tag Manager. According to the official documentation, Google Tag Gateway for advertisers allows you to serve Google tags via your own first-party infrastructure on the website’s domain—through a CDN, load balancer, or web server. In essence, this is first-party delivery for Google tags. In the presentation, the same idea is stated even more clearly: GTG is serving and forwarding for Google-native measurement, whereas server-side GTM is a full-fledged processing layer where you can control, enrich, redact, filter, and route data directly to multiple ad and analytics platforms. For us, this is precisely what cleared up the confusion: GTG does not replace sGTM at the architectural level, but solves a more specific task.
The second important point: these approaches don’t always have to be pitted against each other. Google’s documentation explicitly states that if you use server-side tagging, the Google Tag Gateway can be integrated as part of the “most durable tagging setup.” In other words, GTG can very well be the first step or an additional first-party layer on top of an already configured server-side setup, rather than just an “alternative for the lazy.” For us, this is an important nuance because, in practice, mature projects rarely operate on an “either/or” basis—more often, it’s about the right combination of measurement layers.
What was the most helpful part of the Q&A?
The first key takeaway from the Q&A is that a same-origin path-based setup is more important than many people realize. In its official documentation on custom domain configuration, Google cites same-origin as a best practice and specifically emphasizes that this approach provides security and durability benefits for server-set cookies. If the tagging server resides on the default cloud endpoint, these benefits are lost. For us, this means one simple thing: if a project is really struggling with Safari, ITP, and the longevity of identifiers, then you need to look not only at “whether GTG is enabled,” but at the entire first-party serving scheme—with a server, your own domain, and path-based routing like /metrics.
The second conclusion is that GTG should not be viewed as a silver bullet against ad blockers and browser restrictions. In the presentation, GTG is shown as a solution with limited protection against blockers and without a full-fledged ITP bypass, and independent tests confirm that some requests can still go directly to Google endpoints and that “smarter” blockers still recognize such traffic. If maximum tracking resilience is critical for a project, a full-fledged sGTM with a first-party custom domain remains the stronger foundation, while in infrastructures like Stape, additional protection is provided by custom loaders and power-ups specifically designed to reduce losses from ad blockers.
We particularly liked the third takeaway from the Q&A for its practicality: GTG is about the Google stack, not the entire martech stack at once. Yes, it covers Google Tag Manager, GTM, Google Ads, and GA4, and through Google Tag Manager settings, it’s also available for Campaign Manager 360 / Floodlight. But as soon as a business needs multi-platform measurement—Meta, TikTok, CRM, call tracking, payment status, offline conversions, or Pinterest CAPI—the GTG approach alone is no longer sufficient. In this sense, the example with Pinterest is very telling: Pinterest’s official documentation recommends direct/server-to-server integration for greater control and requires deduplication via event_id if the Tag and Conversions API are used together. This orchestration logic is much closer to a full-fledged server-side architecture than to a GTG-only setup.
How does this affect our assessment of GTG and sGTM in WAMP clients?
After this webinar, we at WAMP gained an even clearer understanding of which projects GTG truly makes sense for, and where it’s better to go straight to sGTM. If a business has a relatively simple stack, relies primarily on Google products, has access to a CDN or other routing infrastructure, and the goal is to quickly strengthen first-party measurement without a complete overhaul of tracking, GTG looks like a solid quick win. Google has simplified setup through Google Ads, GA4, and GTM interfaces, separately supported integration with Cloudflare, and in May 2025, Google Ads Help cited an average 11% uplift in signals for advertisers who had already enabled the Google Tag Gateway for Advertisers.
But if a project involves complex attribution, multiple advertising platforms, anonymization and data governance requirements, the need to limit, enrich, or filter events, as well as the struggle for stability in Safari and longer-lasting cookies, we still believe it’s best to look toward server-side GTM. Google’s position here is also quite clear: server-side tagging provides more detailed privacy controls and helps improve data quality, while a same-origin custom domain is a best practice precisely because of the benefits of server-set cookies and first-party context. In other words, GTG is a good layer for signal enhancement, but sGTM is a level of data control.
Separately, we found the infrastructure-related takeaway from the Q&A particularly valuable: GTM heavily depends on whether the business controls its routing layer. Google’s official materials explicitly mention CDNs, load balancers, or web servers as mandatory components of the setup. This means that on platforms where access to such settings is restricted or hidden within a closed infrastructure, a first-party path-based implementation may be difficult. From a practical standpoint, this means that during the presale and audit phases, it is necessary to evaluate not only the marketing objectives but also the project’s technical freedom.
GTG limits
Data loss
sGTM
flexibility
Deduplication
For us, the main takeaway from the webinar is this: GTG is not a “new sGTM,” but a convenient first-party gateway for Google measurement. It is particularly useful when you need to quickly and accurately integrate the Google stack without major architectural changes. But if the scope is broader—multi-platform tracking, resilience against browser restrictions, strict data control, deduplication across sources, offline and CRM signals, server-managed cookies, and more robust privacy logic—a full-fledged sGTM remains the stronger and more flexible foundation.
And here’s another takeaway we’re definitely putting into practice: any tracking migrations or upgrades should never be done on a whim. Both Google and Pinterest emphasize setup validation in their materials—through Tag Assistant, Test Events, event flow checks, and deduplication. Therefore, our approach has only been reinforced after this webinar: first architecture, then QA, then switching to production—not the other way around. It is precisely this discipline that usually determines whether the new setup will improve data in practice or simply add another layer of complexity to reports.
Conclusion
To sum it all up, this webinar proved valuable to us not because it showed “yet another setting in the Google interface,” but because it clearly laid out the maturity of the different approaches. Google Tag Gateway is a good tool for first-party delivery of Google tags and for strengthening the signal. Server-side GTM is already a full-fledged data layer architecture with its own level of control, flexibility, and stability. This means the right question for a business isn’t “which is trendier—GTG or sGTM?”, but “what level of measurement does our specific project need right now.”
