GTM First-Party Mode vs Server-Side GTM: What's the Actual Difference?

When Google launched First-Party Mode in mid-2024 and then rebranded and expanded it as the Google Tag Gateway in May 2025, many analytics professionals were confused about how it related to Server-Side GTM — a product that’s been available since 2020 and does something that sounds very similar.

Both products involve routing Google tag traffic through your own domain. Both help with ad blockers. Both are described as “privacy-preserving.” But they’re architecturally different, suited to different situations, and have very different cost and complexity profiles.

This guide cuts through the marketing language and explains exactly what each product does and doesn’t do.

The Problem Both Products Solve

Ad blockers maintain lists of known tracking domains. When a user visits your site with uBlock Origin or Brave’s shields enabled, outgoing requests to www.googletagmanager.com, www.google-analytics.com, and googleads.g.doubleclick.net are blocked before they leave the browser.

The result: GA4 receives no data from those users. Google Ads conversion tracking sees no conversions. Your analytics undercount by anywhere from 10% to 40% depending on your audience.

Both First-Party Mode (Google Tag Gateway) and Server-Side GTM address this by routing Google tag requests through your own domain — which isn’t on any blocklist.

What First-Party Mode / Google Tag Gateway Does

First-Party Mode (now branded as Google Tag Gateway for Advertisers) is a proxy for Google’s tag infrastructure that runs at the edge of your domain — typically via a CDN like Cloudflare or Akamai.

What gets proxied:

The gtag.js or gtm.js loader script (downloads from your domain instead of googletagmanager.com)
GA4 measurement requests (sent to your domain instead of google-analytics.com)
Google Ads conversion pings

What doesn’t change:

Tags still fire in the user’s browser
Data still ultimately goes to Google’s servers — just via your domain as a relay
No business logic processing happens — it’s pure proxying
Only Google’s own tags are supported (no Meta, TikTok, etc.)

Architecture:

User's Browser
  ↓
your-domain.com/gtag/js   (Cloudflare Worker or nginx proxy)
  ↓
www.googletagmanager.com  (Google's actual server)

The user’s browser thinks it’s talking to your domain. Your CDN or server transparently forwards the request to Google. Google processes it as normal.

What’s deployed: A configuration in Cloudflare Workers (or Akamai), a DNS change to create the proxy route, and an update to your GTM container to use your domain instead of Google’s. No new servers to manage. No additional Google Cloud billing.

What Server-Side GTM Does

Server-Side GTM is a complete tag management runtime that you deploy on your own server infrastructure (typically Google Cloud Run).

What gets moved to the server:

Tag execution — tags fire on your server, not in the user’s browser
Data processing — you can transform, enrich, filter, and route data before it reaches any vendor
Vendor routing — from one server-side endpoint, you can send data to Google, Meta, TikTok, Snapchat, and any other vendor

What changes:

Browser receives far fewer vendor scripts (reduces page weight and CPU)
Server receives raw event data and decides what to forward and where
You own the data at the server level before it reaches any vendor
Full audit log of what data leaves your infrastructure

Architecture:

User's Browser (simplified, few scripts)
  ↓ single request
your-tracking-subdomain.com  (your Cloud Run server running sGTM)
  ↓ routes to multiple vendors
Google Analytics ← → Meta CAPI ← → TikTok Events API

The user’s browser sends one consolidated request to your server. Your server processes it, applies consent rules, enriches the data if needed, and forwards to the appropriate vendors.

What’s deployed: A Google Cloud Run service (managed container), a custom subdomain with CNAME, server-side GTM container configuration, and migration of all vendor tags from client-side to server-side equivalents.

Side-by-Side Comparison

	First-Party Mode / Tag Gateway	Server-Side GTM
Where tags fire	Browser (unchanged)	Server
Google tags supported	✅ Yes	✅ Yes
Meta/TikTok/other vendors	❌ No	✅ Yes
Ad blocker bypass	✅ Yes (for Google)	✅ Yes (for all proxied vendors)
Data transformation	❌ None	✅ Full control
PII filtering	❌ Not applicable	✅ Strip before sending to vendors
Cookie lifetime	No change	✅ Can set via HTTP headers (bypasses ITP)
Infrastructure required	CDN (Cloudflare/Akamai)	Google Cloud Run
Monthly cost	~$0–5 (CDN edge functions)	$5–50+ (Cloud Run)
Setup time	30–60 minutes	2–5 days
Ongoing maintenance	Minimal	Moderate
Page performance	Slight improvement (script from edge CDN)	Significant improvement (fewer browser scripts)

Use Case 1: “I just want GA4 to survive ad blockers”

Recommendation: Google Tag Gateway

If your only goal is ensuring GA4 and Google Ads conversion tracking work for users with ad blockers, the Google Tag Gateway achieves this at minimal cost and complexity.

You don’t need a Cloud Run server, you don’t need to migrate your entire tag setup, and you don’t need ongoing server maintenance. A Cloudflare Worker, a DNS change, and an update to your GTM container’s server URL setting — done in an afternoon.

This is the right choice for most small and mid-size businesses that run primarily on Google’s ad stack.

Use Case 2: “I also run Meta, TikTok, or other ad platforms”

Recommendation: Server-Side GTM

The Google Tag Gateway only proxies Google traffic. If you’re also running Meta Pixel, TikTok Pixel, Snapchat, Criteo, or any non-Google vendor, the Tag Gateway does nothing for those tags.

Server-Side GTM lets you consolidate all vendor tags behind one server-side endpoint. Your browser sends one request; your server fans it out to Google, Meta, TikTok, and wherever else simultaneously.

The cost and setup complexity are significantly higher, but if you’re running a multi-platform ad mix and attribution accuracy matters, server-side is the right architecture.

Recommendation: Server-Side GTM

If you need to ensure that PII (email addresses, IP addresses, personally identifiable parameters) never reaches ad vendors without explicit consent — and you want that guarantee to be enforced at the infrastructure level rather than just in tag configuration — server-side GTM is the only option.

With sGTM, you can:

Strip IP addresses from all outbound requests
Redact email hashes before forwarding to Meta CAPI
Block all vendor requests for users who declined consent
Keep a full audit log of every event and where it was forwarded

The Google Tag Gateway has no data transformation capability — it’s pure forwarding. What goes in comes out unchanged.

Use Case 4: “I want both — best of both worlds”

Recommendation: Google Tag Gateway + Server-Side GTM together

These are not mutually exclusive. Some organisations use both:

Server-Side GTM handles vendor routing and data transformation
The Google Tag Gateway (via Cloudflare) proxies the gtm.js loader script itself, ensuring the GTM snippet loads even on networks that block googletagmanager.com

In this architecture, even the script that initialises your server-side setup is protected from ad blockers — maximum resilience.

The Practical Setup Path

Setting Up Google Tag Gateway (Cloudflare)

Cloudflare Workers → Create Worker → deploy the proxy script (see our Google Tag Gateway guide)
Add Worker Routes for /gtag/* and /g/*
GTM → Admin → Container Settings → Tagging Server URL → https://yourdomain.com
Test in DevTools: verify requests go to your domain, not google-analytics.com

Setting Up Server-Side GTM

Create a server-side GTM container at tagmanager.google.com
Google Cloud Console → deploy via Automatically provision tagging server
Add custom subdomain CNAME → metrics.yourdomain.com
Server container → add GA4 client + GA4 tag
Client-side GTM → GA4 Configuration tag → server_container_url → https://metrics.yourdomain.com
Migrate other vendor tags (Meta, TikTok) to server-side equivalents
Test via Tag Assistant and vendor debug views

Which Should You Set Up First?

If you’re starting from scratch: Google Tag Gateway first. It’s faster, cheaper, and addresses the most immediate ad blocker problem for Google Analytics. You can add Server-Side GTM later if your multi-vendor needs grow or your ad spend justifies the infrastructure cost.

If you’re running £10,000+/month in multi-platform advertising and ROAS attribution matters: Server-Side GTM directly. The Tag Gateway’s Google-only scope isn’t enough for your needs.

We implement both Google Tag Gateway and Server-Side GTM setups depending on what each client’s situation actually requires. Book a free consultation to get a clear recommendation for your stack.