I’ve been through this myself, running experiments with each approach, and I’ve seen what works and what doesn’t. In this article, I’ll walk through the three main tracking methods for GA4, what they actually do under the hood, and how to decide which one makes sense for your situation.
Client-Side Tagging
Third-Party Mode
This is the classic setup — the one most websites are still running. You drop gtag.js or Google Tag Manager into your site, and the browser sends data directly to google-analytics.com. Since that domain is owned by Google (a third party, relative to your site), it’s called third-party mode.
Here’s the catch: browsers like Safari (with ITP) and Firefox (Enhanced Tracking Protection) have been aggressively limiting third-party cookies and blocking these requests. If you’ve noticed your GA4 numbers dropping over the last couple of years, this is a big reason why.
| Aspect | Details |
|---|---|
| Setup difficulty | Easy. Drop in the snippet, you’re done. |
| Ad block impact | High. Most blockers catch google-analytics.com. |
| Cookie lifespan | Limited by browser — Safari caps it at 7 days. |
| Data richness | Full browser data (referrer, screen size, etc.). |
| Performance | More JS in the browser, but usually negligible. |
If you’re just starting out or running a small site, this is still a perfectly fine place to start. Just know that your numbers won’t be 100% accurate.
Google Tag Gateway
Google Tag Gateway solves one specific problem: instead of the browser sending data to google-analytics.com, it sends it to your own domain, which then forwards it to Google. From the browser’s perspective, the request looks like a first-party request — so ad blockers and ITP are much less likely to interfere.
How it works: You set up a CNAME record on your domain (something like gtag.yourdomain.com) that points to Google’s servers, with a reverse proxy (like Cloudflare) in front to handle the forwarding. The GTM or gtag code loads from your domain, and data flows through it.
| Aspect | Details |
|---|---|
| Setup difficulty | Moderate. You need DNS access and a CDN/reverse proxy. |
| Ad block impact | Reduced. Many blockers don’t catch first-party requests. |
| Cookie lifespan | Longer. First-party cookies aren’t subject to ITP’s 7-day cap. |
| Data richness | Same as TPM — still full browser data. |
| Performance | Negligible difference from TPM. |
Don’t get me wrong: this isn’t a silver bullet. Some aggressive blockers (like uBlock Origin) have started catching known CNAME patterns, and it doesn’t help with consent-mode compliance. It’s a decent middle ground, but not a permanent solution.
Server-SideTagging
Server-side tagging takes a different approach entirely. Instead of running tracking logic in the browser, you run a server-side GTM container on your own server (or a cloud VM). The browser sends data to your server first, your server processes it — filters, transforms, removes PII, whatever you need — and then forwards it to GA4 and any other destinations.
The big difference? Ad blockers can’t touch server-to-server requests. If a user has an ad blocker, the client-side code on your site still captures the event and pings your server. From there, it reaches GA4 no problem.
| Aspect | Details |
|---|---|
| Setup difficulty | High. You need a server, Docker, and GTM server-side config. |
| Ad block impact | Near zero. Server-to-server requests aren’t blockable. |
| Cookie lifespan | You control it. Can set 1-year (or longer) first-party cookies. |
| Data richness | Some browser data needs extra work — hybrid client+server setup recommended. |
| Cost | Ongoing server costs (Cloud Run, AWS, etc.) plus potential SAAS fees. |
| PII control | Excellent. Filter or hash PII before it leaves your server. |
If your traffic is significant and data accuracy matters to your business, server-side tagging is worth the investment. That said, the setup is genuinely more complex — I’ve spent plenty of evenings debugging Docker configs myself.
If you don’t want to manage a server yourself, there are paid SAAS solutions that simplify this a lot — Stape, TAGGRS, and JENTIS are the ones I see most often. They handle the infrastructure so you just configure the tags.
Which One Should You Use?
Here’s my honest take, based on what I’ve seen work:
- Small site, low traffic, just getting started? Stick with standard client-side third-party mode. It’s free, it’s easy, and the data loss from blockers is manageable at that scale.
- Medium traffic, seeing noticeable data gaps, want a quick improvement? Try Google Tag Gateway. The CNAME setup is a one-time thing, and it recovers a decent chunk of that lost data.
- High traffic, running e-commerce, or accuracy is critical for your business? Go server-side. It’s more work upfront, but it’s the only approach that truly sidesteps blockers and gives you full control over your data pipeline. The paid SAAS options make this more accessible than it used to be.
And if you’re really serious, there’s nothing stopping you from combining first-party mode (client-side) with server-side tagging — best of both worlds. That’s what I run on my own sites.
Final Words
There’s no one-size-fits-all answer here, and I’ve learned that the hard way. The “right” tracking method depends on your traffic volume, your technical resources, and how much data loss you can tolerate. I hope this guide gave you a clearer picture of the tradeoffs.