The symptom
Someone on the team comes back from a call with a Google rep, or a client forwards an in-product prompt from Google Ads, asking why you haven't set up "tag gateway" yet. Two weeks earlier the same client asked whether you'd finally moved them to "server-side Google Tag Manager." Both questions land in the same Slack thread, both have "Google" and "gateway" or "tag manager" in the name, and nobody on the account is fully sure whether they're the same project, competing projects, or two steps in a sequence.
So the account stalls. Nobody wants to promise a client an infrastructure change without knowing what it actually buys them, and nobody wants to be the one who set up the wrong thing first.

Why they get confused
The names are built to be confused. Both route Google's tags through a domain the visitor already trusts instead of loading them straight from a Google-owned domain, and both sit under the same Tag Manager help section. Past that, they solve different problems at different layers.
Google's own documentation describes Google tag gateway for advertisers as infrastructure Google runs, not a container you configure. Set up from Google Ads, Google Analytics, Campaign Manager 360 or Tag Manager, it loads Google's tags from your domain and forwards the resulting measurement events back to Google. To run it, all of a domain's traffic has to pass through a Google Cloud Global External Application Load Balancer, or a supported CDN integration, Cloudflare has one-click setup, Fastly and Akamai are also listed. That's a routing decision at the load balancer or CDN layer. And what it covers is narrow by design: Google Ads, Google Ads Data Manager and Google's own tags. Google's documentation makes no mention of Meta CAPI, TikTok's events API, LinkedIn's Insight Tag, or a CRM feed. If part of the account's ad spend sits outside Google, tag gateway does nothing for that part.
Server-side Google Tag Manager is a different layer: a container you run and control, that receives events and decides where they go. It can forward to Google Ads and GA4 the same way tag gateway does, but it can just as easily forward to Meta, TikTok, LinkedIn or a data warehouse, because you own the routing logic instead of adopting Google's. That's also why picking the hosting vendor for it barely changes the outcome, as we found when comparing Stape against Taggrs: the configuration on top of the container decides the recovery rate, not which tool name is on the invoice.
The two aren't competing for the same decision. One is a narrow, Google-run pipe for Google's own products. The other is a general container you own. What confuses agencies is that both get pitched as "the fix" for the same symptom, browsers and ad blockers refusing to trust a Google-branded domain, without either side saying which part of that symptom it actually fixes. We covered that same first-party origin problem in general terms in what a first-party tag gateway actually does; this article is about the two specific, Google-named options for solving it.
What good looks like
Before choosing infrastructure, know what's actually missing. That's an audit question, not an implementation question, and it's the step both gateways skip past. If the gap is specifically inside Google Ads and GA4 conversion counts, and the domain already routes through a supported load balancer or CDN, tag gateway is a genuinely low-effort way to close it. Google states the setup needs "no changes to the existing tag code" on the page. If the gap includes Meta, TikTok, a CRM feed, or anything Google doesn't touch, tag gateway only ever solves part of it, and server-side Google Tag Manager is needed regardless.
Either way, the infrastructure choice isn't what determines how much signal comes back. Archon Signal starts by measuring what's actually being lost across every destination, not just Google's, then builds the first-party collection layer that fits the account, a server-side container where the reach has to go beyond Google, tag gateway where it genuinely doesn't, sometimes both running side by side on the same domain. Properly configured server-side collection recovers 15-40% more conversions than an unconfigured client-side setup, and that gain comes from the configuration on top, not from which Google product name sits on the infrastructure. Consent refusals and network failures always take a share of what any setup collects, so the honest ceiling here is roughly 95% of events, never all of them.
Frequently asked
Can we run tag gateway and server-side Google Tag Manager together?
Yes. Google's own combined setup guide describes a CDN serving Google's scripts from one path on your domain while a separate server-side Google Tag Manager instance handles data collection, enrichment and control from another. The two sit at different layers and aren't mutually exclusive.
Does tag gateway replace server-side Google Tag Manager?
No. It replaces the part of the job that was already Google-only, loading Google's tags from a Google domain. It doesn't do anything a server-side container does for Meta, TikTok, LinkedIn or CRM data, since Google's own documentation never describes it touching a destination outside Google Ads, GA4 and Floodlight.
What does tag gateway actually require from our infrastructure?
All of the domain's traffic needs to route through a Google Cloud Global External Application Load Balancer, or through a supported CDN, Cloudflare, Fastly or Akamai on Google's current list. A classic or legacy load balancer isn't supported. That's a real infrastructure dependency, not a checkbox inside Tag Manager.
Is Google tag gateway free to run?
Google states the integration itself carries no charge, you pay only your normal Google Cloud Load Balancer or CDN costs, infrastructure most sites already run for reasons that have nothing to do with tracking.
Which one should a client with a mostly-Google media mix set up first?
Start with the audit, not the infrastructure. If Google Ads and GA4 conversions are the confirmed gap and the domain already sits behind a supported load balancer or CDN, tag gateway is the lighter lift. If the account needs anything a server-side container does that tag gateway doesn't, or the infrastructure prerequisite isn't in place, building the container is the one move that covers both now and later.
Not sure which gap this account actually has, or whether either gateway earns its setup cost yet? Get a free tracking audit and find out before anything gets built.