Google Tag Gateway: what it is and why it changes server-side tagging

Google quietly released Tag Gateway in late 2025, and it changes how server-side tagging works in a way that most people haven’t fully grasped yet. I’ve been running it in production for three months now on two client properties. I have opinions.

The short version: Tag Gateway is a Google-managed first-party endpoint that sits between your website and your server-side GTM container. It eliminates the custom domain DNS setup that has been the most painful part of sGTM deployments. But it introduces new trade-offs in cost, control, and privacy that you need to understand before switching.

What Tag Gateway actually is

In a traditional sGTM setup, the architecture looks like this:

1. Your website sends tracking data to data.yoursite.com (a custom subdomain you set up).
2. DNS routes data.yoursite.com to your Cloud Run or App Engine instance running the sGTM container.
3. The sGTM container processes the data and forwards it to GA4, Google Ads, Meta, etc.

The custom subdomain is what makes it “first-party.” Ad blockers see a request to data.yoursite.com and let it through because it looks like a regular first-party request. ITP treats the cookies as first-party because they’re on your domain. This is the whole point of server-side tagging.

But setting up that custom subdomain is a pain. You need to configure DNS records, provision SSL certificates, verify domain ownership, and make sure the whole chain works. For agencies managing dozens of clients, this is hours of billable work per client that nobody enjoys.

Tag Gateway removes the DNS step entirely.

With Tag Gateway, the architecture becomes:

1. Your website sends tracking data to a Google-managed endpoint.
2. Tag Gateway routes it to your sGTM container.
3. Your sGTM container processes and forwards it as before.

Google provisions the endpoint. Google handles SSL. Google manages the infrastructure between the browser and your container. You don’t touch DNS.

How it differs from traditional sGTM

The differences matter more than they seem at first glance.

DNS and domain setup. Traditional sGTM: you create a CNAME or A record pointing a subdomain to your Cloud Run service. You manage SSL certificates (usually automatic via Google-managed certs, but still something that can break). Tag Gateway: none of this. Google gives you an endpoint URL, you point your GTM web container at it, done.

Request routing. Traditional sGTM: the browser makes a direct request to your subdomain, which resolves to your Cloud Run instance. One hop. Tag Gateway: the browser makes a request to a Google-managed endpoint, which proxies it to your container. Two hops. This adds a small amount of latency (typically 10-30ms in my testing). For tracking data, this is negligible. Nobody is going to notice an extra 20ms on a tracking request.

First-party context. This is the nuanced part. Traditional sGTM with a custom subdomain is unambiguously first-party. The request goes to your domain. Cookies are set on your domain. There’s no Google infrastructure visible in the request chain from the browser’s perspective. Tag Gateway is… more complicated. The initial request goes to a Google-managed endpoint. Google then proxies it to your container. Whether this counts as “first-party” depends on your interpretation and, increasingly, on how browsers and privacy tools classify it.

As of today, Tag Gateway works. Browsers treat the requests as first-party because Google’s endpoint operates in a way that maintains first-party cookie context. But I wouldn’t bet my career on this remaining true forever. Browser vendors are getting more aggressive about identifying and restricting proxy-based tracking architectures.

Container management. No change. Your sGTM container works exactly the same way regardless of whether traffic arrives via custom subdomain or Tag Gateway. Your tags, triggers, variables, and clients don’t need modification.

Setting it up

The setup is genuinely simple compared to traditional sGTM, which is the main selling point.

Step 1: Go to your sGTM container settings in Google Tag Manager. Under “Server Container,” you’ll see a new option for Tag Gateway. Enable it.

Step 2: Google provisions a Tag Gateway endpoint for your container. This takes a few minutes. You’ll get a URL that looks something like https://tg-xxxxx.google.com (the exact format may vary, but it’s a Google-owned domain).

Step 3: In your GTM web container, update the server container URL in your GA4 Configuration tag. Replace your custom subdomain URL with the Tag Gateway URL. If you were previously sending to https://data.yoursite.com, you now send to the Tag Gateway URL.

Step 4: Publish your web container. Done.

If you’re also running a custom subdomain, you can run both in parallel. Tag Gateway doesn’t require you to remove your existing DNS setup. I recommend running both for a week during transition to verify that data flows correctly through both paths before decommissioning the custom subdomain.

Cost implications

This is where people need to pay attention.

Traditional sGTM costs are straightforward: you pay for Cloud Run (or App Engine, or whatever compute you’re using). A typical small-to-medium site pays $30-100/month. A high-traffic site pays $200-800/month. You control the infrastructure, so you control the cost.

Tag Gateway adds a layer. As of my last check, Google charges for Tag Gateway based on the number of events processed. The pricing is separate from your Cloud Run costs. You still pay for the compute (your container still runs on Cloud Run), AND you pay for Tag Gateway’s proxy service.

For a property processing 10 million events per month, Tag Gateway adds roughly $50-150/month on top of existing infrastructure costs. For smaller properties doing 1-2 million events, the added cost is more like $15-40/month.

Is this worth it? Depends entirely on whether the DNS setup is a pain point for you. If you’re an agency deploying sGTM for 20 clients and you spend 2-3 hours per client on DNS configuration, Tag Gateway saves you 40-60 hours of setup time. That math works easily. If you’re a single property with a competent DevOps person who set up DNS in 20 minutes, the ongoing cost increase is harder to justify.

Privacy considerations

This is the section where I’m going to give you my honest take, which might differ from Google’s marketing materials.

The argument for Tag Gateway being more privacy-friendly: Google positions Tag Gateway as a managed solution that ensures proper data handling. They handle the SSL, the infrastructure security, and the data transit between browser and container. For organizations without strong DevOps capabilities, this means fewer opportunities to misconfigure something in a way that leaks data.

The argument against: You’re routing all your tracking data through Google’s infrastructure before it reaches your container. Yes, your container is also running on Google Cloud, so Google technically already has access to the infrastructure. But Tag Gateway adds an explicit proxy layer that Google operates. If your privacy posture or your DPA (Data Processing Agreement) is based on the principle that data goes directly from the user’s browser to your server, Tag Gateway changes that flow.

For EU properties operating under GDPR, this matters. The question isn’t just “is the data processed securely?” but “who is processing it and under what legal basis?” Tag Gateway introduces Google as an additional data processor in the chain between browser and your container. Your privacy documentation and processing records should reflect this.

My take: for most businesses, this is a non-issue in practice. Google is already your processor for GA4, Google Ads, and likely your cloud infrastructure. Adding Tag Gateway to that chain doesn’t materially change your privacy risk profile. But if you’re in healthcare, finance, or another highly regulated industry where data flow documentation is scrutinized, you’ll want your legal team to review this.

As I discussed in my article on Consent Mode v2, compliance in analytics isn’t a binary checkbox. It’s a spectrum of interpretation, and your position on that spectrum determines how you evaluate infrastructure choices like this one.

Tag Gateway vs. traditional sGTM vs. Stape

Let me compare the three main options for running server-side tagging in 2026.

Traditional sGTM (self-hosted on Cloud Run)

Pros:

• Full control over infrastructure and data flow
• Unambiguously first-party when using custom subdomain
• Lowest ongoing cost for single-property deployments
• Maximum flexibility for custom configurations

Cons:

• DNS setup required (the main pain point)
• You manage SSL certificates (usually automated, but still)
• You handle scaling, monitoring, and uptime
• Requires some Cloud infra knowledge

Best for: Technical teams, single-property setups, organizations with strict data sovereignty requirements.

Tag Gateway

Pros:

• No DNS configuration needed
• Google manages the proxy infrastructure
• Easy to set up (15 minutes vs. 2-3 hours)
• Works alongside existing custom subdomain setups

Cons:

• Additional cost on top of Cloud Run
• Adds a proxy hop (minor latency increase)
• Less control over the data path
• Privacy implications of routing through Google’s proxy
• Long-term durability uncertain (will browsers continue treating it as first-party?)

Best for: Agencies managing multiple clients, non-technical teams, rapid deployments.

Stape (managed sGTM hosting)

Pros:

• Fully managed infrastructure (they handle everything)
• Fixed, predictable pricing
• Built-in monitoring and alerting
• Good UI for non-technical users
• Custom domain setup included in their service

Cons:

• Third-party dependency (your tracking runs on their infra)
• Less flexibility for custom configurations
• Vendor lock-in risk
• Monthly cost is higher than self-hosted for high-traffic properties

Best for: Teams that want sGTM without touching any infrastructure, mid-size businesses, marketing teams without DevOps support.

Who should switch to Tag Gateway

Switch now if:

• You’re an agency deploying new sGTM containers regularly and DNS setup is eating your time.
• You’re setting up sGTM for the first time and don’t have a DevOps person to handle DNS and Cloud Run configuration.
• You want to test sGTM quickly before committing to full custom domain setup.

Wait if:

• Your current sGTM setup with a custom subdomain is working fine. There’s no operational benefit to switching, and you’ll pay more.
• You’re in a regulated industry where data routing documentation matters. Let the privacy guidance around Tag Gateway mature first.
• You’ve already invested in Stape or another managed solution. Tag Gateway doesn’t offer meaningful advantages over established managed providers.

Don’t use it if:

• Data sovereignty is a hard requirement and your legal team objects to the additional Google proxy layer.
• You need maximum control over every aspect of the data pipeline.
• You’re already running a smooth server-side tagging setup with custom domains and don’t want to add complexity for marginal convenience.

My take

Tag Gateway solves a real problem. DNS configuration is genuinely the biggest friction point in sGTM adoption. I’ve watched marketing teams abandon server-side tagging entirely because they couldn’t get their IT department to create a CNAME record. Tag Gateway removes that blocker.

But I’m cautious about the long-term play. Google is positioning Tag Gateway as the easy path, and easy paths in tracking tend to get noticed by privacy tools eventually. If browsers start treating Tag Gateway endpoints differently from true custom subdomains, the whole value proposition collapses. You’d need to retrofit custom domains anyway.

For new deployments where the client can’t or won’t handle DNS, I’m recommending Tag Gateway as a starting point with a plan to migrate to a custom subdomain later. It gets server-side tagging running immediately, and migration is straightforward since the container itself doesn’t change.

For existing setups that work, I’m telling clients to stay put. The marginal convenience doesn’t justify the added cost and uncertainty.

And for anyone concerned about Google Ads conversion tracking accuracy, the good news is that Tag Gateway doesn’t change how your sGTM container processes and sends data. Your conversion tracking, your GA4 events, your Meta CAPI calls, everything downstream of the container works identically. The change is only in how data gets from the browser to the container. The quality of your tracking data is determined by what happens inside the container, not how data arrives at its door.

Tag Gateway is a convenience feature dressed up as an infrastructure product. It makes sGTM accessible to more people, which is good for the ecosystem. Just understand what you’re trading for that convenience before you commit.