You’ve heard the term “server-side tracking” thrown around like it’s the holy grail of analytics. But let’s be honest—most explanations either oversimplify it to the point of uselessness or dive so deep into technical jargon that you need a PhD to follow along.
This article cuts through the BS. We’ll explore what server-side tracking actually is, why it exists, how browsers and ad blockers try to stop tracking, and the technical tricks (CNAME cloaking, reverse proxies, Google Tag Gateway) that marketers use to stay ahead.
Fair warning: We’re going technical, but not academic. Let’s dive in.
What Is Server-Side Tracking (And Why Should You Care)?
The Client-Side Problem
Traditional web tracking—what we call “client-side tracking”—works like this:
- A user visits your website
- Your site loads JavaScript tags (Google Analytics, Facebook Pixel, etc.)
- These scripts execute in the user’s browser
- The browser sends data directly to
google-analytics.com,facebook.com/tr, and other third-party domains - Those platforms set cookies in the user’s browser to track them across sessions
The problem? This entire flow is visible and controllable by the user’s browser. Ad blockers can see these requests going to known tracking domains and block them. Privacy-focused browsers like Safari and Firefox have built-in protections that limit cookie lifespans or block third-party tracking altogether.
According to research on CNAME cloaking published by Unit 42, traditional ad blocking is highly effective: “Ad blockers work with a blocklist of URLs and patterns” and can prevent most third-party tracking by simply maintaining lists of known tracking domains.[^1]
Enter Server-Side Tracking
Server-side tracking fundamentally changes this architecture:
- Your website sends data to your own domain (e.g.,
tracking.yoursite.com) - Your server receives this data
- Your server processes, transforms, and forwards data to analytics platforms using server-to-server communication
- The user’s browser never directly communicates with Google, Facebook, or other platforms
This isn’t just “sending data to a different URL.” It’s a complete architectural shift that moves tracking logic from the client (browser) to the server.
As Google’s official documentation explains: “The purpose of the server container is to provide an intermediary endpoint that you own between the browser or device where events are recorded and the third-party endpoints.”[^2]
Why Use Server-Side Tracking?
1. Bypass Ad Blockers (Mostly)
Ad blockers primarily work by maintaining lists of known tracking domains. When you route tracking through your own domain, ad blockers don’t recognize it—at least not immediately.
2. First-Party Cookies
Server-side tracking allows you to set cookies on your own domain. These are “first-party cookies” which browsers treat more favorably than third-party cookies. They last longer and aren’t subject to the same restrictions.
3. Data Control
With server-side tracking, you control what data gets sent to which platforms. You can:
- Filter out personally identifiable information (PII) before sending to vendors
- Enrich data from your CRM or database
- Validate and normalize data before it reaches analytics platforms
According to Google’s server-side documentation: “Server-side tagging gives you full control over the data that is distributed to third parties. Within the server container, you can remove any personally identifiable information (PII) before passing the data on to marketing partners.”[^2]
4. Multi-Platform Support
A single server-side setup can feed data to multiple platforms using their respective APIs:
- Google Analytics 4 (via Measurement Protocol)
- Meta Conversions API
- TikTok Events API
- Snapchat Conversions API
- LinkedIn Conversions API
5. Website Performance
Client-side tags slow down your website. Every additional JavaScript library increases page load time. With server-side tracking, you load one lightweight script on your site, and your server handles the heavy lifting.
As research from Analytics Mania demonstrates: “In a server-side tagging setup, the client only has to generate one HTTP request per event that gets sent to the server container. Then, the server container generates and dispatches vendor-specific requests. The result is improved website performance.”[^3]
How Browsers and Ad Blockers Actually Block Tracking
To understand why server-side tracking works, you need to understand how blocking mechanisms actually function. Spoiler: they’re simpler than you think, and that’s exactly why server-side can circumvent them.
Method #1: Domain Blocklists (The Primary Method)
Ad blockers like uBlock Origin, AdBlock Plus, and Ghostery rely heavily on filter lists—essentially databases of known tracking domains and URL patterns.
The most popular filter lists include:
- EasyList: Blocks most ads from international webpages
- EasyPrivacy: Removes tracking scripts and web bugs
- AdGuard Tracking Protection: Blocks various analytics tools
According to research on ad blocker functionality: “Filter lists are the backbone of ad blocking. Essentially a set of rules used by ad blockers to determine which content should be blocked on web pages.”[^4]
When your browser tries to load a script from a domain in these lists, the ad blocker intercepts and blocks the request. Simple, fast, effective.
Example filter rules:
||google-analytics.com^
||googletagmanager.com^
||facebook.com/tr^
||connect.facebook.net^
Method #2: URL Pattern Matching
Ad blockers also use simple pattern matching to catch tracking scripts on known domains:
/track/analytics/collect/pixeladframe.jsgtag.js
Research from the EasyList project confirms: “Ad blockers compare a site’s scripts with the ones from this list. If it finds scripts that match those in the database, the software prevents them from loading.”[^5]
Important distinction: These patterns primarily apply to already-identified tracking domains. A random endpoint like yoursite.com/collect won’t automatically be blocked just because it contains /collect in the path.
Method #3: CNAME Detection (Advanced, Limited)
This is where things get interesting—and where Safari and Firefox diverge significantly.
CNAME (Canonical Name) records in DNS allow one domain name to point to another. Trackers started using this technique (called “CNAME cloaking”) to disguise third-party tracking as first-party:
tracking.yoursite.com (CNAME) → tracker.analytics-provider.com
To the browser’s blocklist, this looks like a first-party request to yoursite.com. But in reality, the DNS resolves to a third-party tracker.
Safari’s Response: Intelligent Tracking Prevention (ITP)
Apple’s WebKit team implemented CNAME detection in Safari 14 (November 2020). As documented in their official announcement:
“ITP now detects third-party CNAME cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days. Third-party CNAME cloaking is defined as a first-party subresource that resolves through a CNAME that differs from the first-party domain and differs from the top frame host’s CNAME, if one exists.”[^6]
Key point: Safari doesn’t block the request—it just limits cookies to 7 days, which significantly reduces tracking effectiveness.
Firefox’s Response: uBlock Origin DNS API
In Firefox, uBlock Origin can leverage Mozilla’s browser.dns API to perform DNS lookups and detect CNAME cloaking. As reported by BleepingComputer:
“In order to block first-party trackers that utilize CNAME records, uBlock Origin would first need to perform a DNS lookup of the hostname loading a script to determine the underlying domain that it resolves to… Firefox supports an API to resolve the hostname of a DNS record, which can unmask CNAME shenanigans.”[^7]
Chrome’s Limitation:
Chrome and Chromium-based browsers don’t provide a DNS resolution API to extensions. As confirmed in the uBlock Origin documentation: “For Chrome, there is no DNS API available, and so no easy way to detect this.”[^8]
What Ad Blockers DON’T Do (Despite What You Might Think)
Here’s where I need to correct some common misconceptions:
❌ Script Fingerprinting / Checksum Analysis
Ad blockers do not calculate hashes or checksums of JavaScript files to identify tracking scripts. This would be:
- Too CPU-intensive
- Ineffective (scripts change frequently with updates, minification, etc.)
- Prone to false positives
❌ Deep Payload Inspection
Ad blockers generally don’t analyze the content of HTTP requests to detect tracking behavior. Why?
- Performance cost would be prohibitive
- Would require parsing every request
- Too many false positives (legitimate APIs often look similar to tracking)
❌ Systematic Blocking of Path Patterns on All Domains
An endpoint like yoursite.com/collect isn’t automatically blocked just because it contains /collect. Ad blockers need additional signals (domain reputation, explicit rules) to block such requests.
The research paper “CNAME Cloaking-based Tracking on the Web” confirms: “Browser extensions are not allowed access to the DNS layer of the request—i.e., they can’t see the CNAMEs… Tools need to include as many rules as there are websites using this CNAME Cloaking method.”[^9]
Filter list limits also matter: Browser extensions face hard limits on the number of rules they can maintain:
- Safari: 50,000 rules maximum
- Chrome (Manifest V3): 30,000 rules maximum
This makes it practically impossible to maintain blocklists for every subdomain used in CNAME cloaking across the web.
CNAME Cloaking: The “Clever” Workaround (With Limitations)
Now that we understand how blocking works, let’s examine the technical tricks marketers use to circumvent these protections.
What Is CNAME Cloaking?
CNAME cloaking is a DNS technique where you create a subdomain on your domain that points (via CNAME record) to a third-party tracking service:
DNS Configuration:
tracking.yoursite.com CNAME → analytics-provider.com
From the browser’s perspective:
- The request appears to go to
tracking.yoursite.com(first-party) - Ad blockers see your domain, not
analytics-provider.com - The request passes through
From the DNS perspective:
- The CNAME record redirects to the actual tracking service
- The tracking service receives the data
- Cookies can be set that appear to be from your domain
As research from NextDNS explains: “Tracking providers ask their clients to delegate a subdomain for data collection and link it to an external domain using a CNAME record. The website and the external tracking site appear to originate from the same domain allowing cookies on the tracking site to appear as if they [were from] the original domain.”[^10]
The Problem: Safari ITP Still Detects It
Remember how Safari performs DNS resolution to detect CNAME cloaking? This means that even though ad blockers (browser extensions) might not detect your CNAME, Safari’s native ITP does.
Result: Your cookies get capped at 7 days maximum expiration.
From the WebKit announcement: “ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days.”[^6]
The Real Solution: IP Address Matching
Here’s a critical technical detail that most server-side tracking guides gloss over:
Safari ITP 16.4+ (released March 2023) doesn’t just check DNS—it also checks IP addresses.
According to Stape’s documentation on Safari ITP bypass:
“If the first two numbers of the IP addresses of your SGTM server and the website server don’t match, the cookie lifetime extension will not work. For example, if the website server’s IP address is 1.2.3.4 and the SGTM server’s IP address is 44.55.6.7, the first two numbers (1.2 vs 44.55) do not match; thus, cookies set from the server will still expire in 7 days.”[^11]
The fix: Use the same load balancer or CDN for both your website and your server-side tracking endpoint. This ensures matching IP addresses and allows cookies to maintain their full expiration periods.
Reverse Proxy: The “Proper” Implementation
A reverse proxy is a more robust approach than simple CNAME cloaking. Here’s the difference:
CNAME (DNS-level redirect):
Browser → tracking.yoursite.com
DNS resolves → analytics-provider.com (visible to ITP)
Reverse Proxy (Application-level routing):
Browser → tracking.yoursite.com (A record to YOUR IP)
Your Server (Nginx/Apache) → forwards to analytics-provider.com (backend)
Key advantages:
- No DNS trail: The browser only sees your domain and your IP address
- No ITP detection: There’s no CNAME to detect—it’s a real A record pointing to your infrastructure
- Full control: You can transform requests, add authentication, filter data
Example Nginx configuration:
location /collect {
proxy_pass https://analytics-provider.com;
proxy_set_header Host analytics-provider.com;
proxy_set_header X-Forwarded-For $remote_addr;
}
The Cookie Problem (Why You Still Need Server-Side Logic)
Here’s the catch: even with a perfect reverse proxy, you can’t just forward requests to Google Analytics or Meta and expect everything to work.
Why? Because of how cookies work with HTTP responses.
When Google Analytics wants to set a cookie, it sends an HTTP header like:
Set-Cookie: _ga=GA1.2.xxxxx; Domain=.yoursite.com; Max-Age=63072000
But Google’s servers don’t know they should set cookies for yoursite.com—they only know about google-analytics.com.
This is exactly why server-side GTM exists: It’s not just a reverse proxy—it’s an application layer that:
- Receives data from your website
- Sets first-party cookies for your domain
- Transforms the data according to each platform’s API specifications
- Authenticates with platforms using your tokens/credentials
- Sends data to Google, Meta, etc. via their official APIs
As Louder Online’s comparison explains: “Server-side GTM unlocks significantly more use cases: Send events to multiple endpoints and conversion APIs like Meta, Snap, TikTok, Linkedin, and others, not just Google. Real-time data enrichment [from] CRMs, CDPs, or CSV-based sources.”[^12]
Google Tag Gateway: The Simple Solution (With Big Limitations)
In 2024, Google released Tag Gateway (previously called “First-Party Mode”)—a simpler alternative to full server-side GTM. Let’s be clear about what it is and what it isn’t.
What Is Google Tag Gateway?
Google Tag Gateway uses your CDN (primarily Cloudflare) to proxy Google tags through your domain:
Traditional:
yoursite.com → loads gtag.js from googletagmanager.com
With Tag Gateway:
yoursite.com → loads gtag.js from yoursite.com/measurement/gtag.js
Cloudflare proxies → actual script from Google
According to Google’s documentation: “Google tag gateway for advertisers lets you deploy a Google tag using your own first-party infrastructure, hosted on your website’s domain.”[^13]
How It Works (Under the Hood)
When you enable Tag Gateway with Cloudflare:
- Cloudflare intercepts requests to your designated measurement path
- Cloudflare fetches the actual script from Google
- Cloudflare serves it as if it came from your domain
- JavaScript executes in your domain context
- Tracking requests also route through your domain before reaching Google
As explained by Love’s Data: “Cloudflare fetches the original script from Google and returns it as though it came from your server. The script executes in the browser, capturing analytics or advertising signals as first-party data. Collected data is sent back to Google, again via your own domain.”[^14]
The Big Limitation: Google Ecosystem Only
Here’s the critical constraint: Tag Gateway only works for Google properties (GA4, Google Ads, GTM).
Why can’t you use the same approach for Meta, TikTok, or other platforms?
1. No Partnership Agreement
Tag Gateway works because Google and Cloudflare have an official partnership. Google has authorized Cloudflare to proxy its scripts and has configured its infrastructure to accept these proxied requests.
Meta, TikTok, Snapchat, etc., do not have such agreements with Cloudflare or any other CDN.
2. Authentication and Security
Meta Conversions API requires:
- An access token for authentication
- Event matching parameters (email, phone, etc.)
- Specific data structures
A simple reverse proxy can’t provide these—you need application logic to:
- Authenticate with Meta’s API
- Transform data into the correct format
- Handle rate limiting and retries
As research comparing Tag Gateway and server-side GTM confirms: “Tag Gateway is ideal for businesses focused solely on the Google ecosystem… By contrast, sGTM offers a far more flexible, platform-agnostic solution capable of integrating with Facebook, TikTok, LinkedIn, and others.”[^12]
3. Script Behavior and Domain Validation
The Meta Pixel JavaScript (fbevents.js) expects to communicate with facebook.com. It likely contains domain validation and security checks that would break if you simply proxied it through your domain.
When to Use Tag Gateway vs. Server-Side GTM
According to industry analysis by FiveNine Strategy:
Google Tag Gateway:
- Best for Google-only setups (GA4 + Google Ads)
- Easier setup, lower cost
- Recovers 70-85% of lost tracking
Server-Side GTM:
- Enterprise solution for multi-platform tracking
- Complex setup, higher cost
- Recovers 90-95% of tracking
- Full data control and transformation
Their recommendation: “Under $250k/month ad spend? Choose Google Tag Gateway. Over $250k with technical resources? Go server-side.”[^15]
The Uncomfortable Truth: It’s Discretion, Not Evasion
Let’s address the elephant in the room: server-side tracking isn’t some magical “unblockable” solution. It’s a cat-and-mouse game, and the mice are getting smarter.
Ad Blockers Could Evolve
Everything we’ve discussed—CNAME cloaking, reverse proxies, first-party tracking—works because ad blockers have chosen not to implement more aggressive detection methods.
They could theoretically:
- Analyze request patterns to identify tracking behavior
- Use machine learning to detect anomalous data flows
- Maintain heuristic rules for common server-side tracking patterns
- Block common paths like
/collector/gtmeven on first-party domains
Research into CNAME cloaking detection using machine learning demonstrates this is technically feasible. A 2021 paper showed: “We propose a supervised machine learning-based approach to detect CNAME cloaking-based tracking without the on-demand DNS lookup… Our evaluation shows that CNAMETracking Uncloaker is able to filter out CNAME cloaking-based tracking requests.”[^16]
Why haven’t they?
- Performance costs: Deep packet inspection is CPU-intensive
- False positives: Many legitimate services use similar patterns
- Rule limits: Browser extensions hit hard limits (30k-50k rules)
- Resource constraints: Filter list maintainers are mostly volunteers
GDPR Still Applies
This should be obvious, but it bears repeating: server-side tracking does not exempt you from privacy regulations.
Just because you can collect data doesn’t mean you should or that it’s legal. GDPR, CCPA, and other privacy laws require:
- User consent before tracking
- Clear privacy policies
- Data minimization
- Right to deletion
As NextDNS’s analysis of CNAME cloaking notes: “This exploit… clearly violates Europe’s GDPR, which clearly states that ‘user-centric tracking’ requires consent, especially in the case of a third-party service usage.”[^10]
It’s About Resilience, Not Evasion
The real value of server-side tracking isn’t “beating ad blockers”—it’s building a resilient measurement infrastructure that:
- Reduces dependency on third-party cookies
- Gives you control over your data
- Provides flexibility to adapt to future privacy changes
- Improves data quality through server-side enrichment
- Supports multiple platforms from a single integration
As Google’s documentation states: “The purpose of the server container is to provide an intermediary endpoint that you own between the browser or device where events are recorded and the third-party endpoints.”[^2]
It’s about ownership and control, not about sneaking past privacy protections.
Final Thoughts: The Future of Tracking Is First-Party
Here’s what I believe after 10 years in this space:
Third-party tracking as we knew it is dying. Not because of ad blockers alone, but because of a convergence of factors: privacy regulations, browser restrictions, consumer awareness, and platform policies.
Server-side tracking is the bridge to a more sustainable model where:
- Companies own their data collection infrastructure
- Data flows through authenticated, API-based channels
- Privacy controls happen server-side, not at the mercy of browser extensions
- Attribution becomes more deterministic and less probabilistic
But it’s not a silver bullet. It’s a tool—one that requires investment, technical expertise, and ongoing maintenance. For many businesses, it’s overkill. For others, it’s essential infrastructure.
The real question isn’t “Should I use server-side tracking?” but rather “What problem am I trying to solve, and is server-side tracking the right solution?”
If you’re trying to bypass user consent or track people who don’t want to be tracked—you’re fighting a losing battle, and you should reconsider your approach.
If you’re trying to build robust, privacy-compliant measurement that gives you control over your data pipeline—then yes, server-side tracking makes a lot of sense.
The future of analytics isn’t about being sneaky. It’s about being transparent, compliant, and technically sophisticated.
References
[1]: Unit 42, Palo Alto Networks. “CNAME Cloaking: Disguising Third Parties Through the DNS.” Available at: https://unit42.paloaltonetworks.com/cname-cloaking/
[2]: Google Tag Manager Help. “Client-side tagging vs. server-side tagging.” Available at: https://support.google.com/tagmanager/answer/13387731
[3]: Analytics Mania. “Google Tag Manager Server-Side Tagging with Stape.” Available at: https://www.analyticsmania.com/post/server-side-tagging-with-stape/
[4]: Eyeo / AdBlock. “Understanding EasyList: The backbone of ad blocking.” Available at: https://resources.eyeo.com/understanding-easylist-the-backbone-of-ad-blocking
[5]: TMS Outsource. “How Do Websites Detect Adblock? It’s Quite Simple, Actually.” Available at: https://tms-outsource.com/blog/posts/how-do-websites-detect-adblock/
[6]: WebKit. “CNAME Cloaking and Bounce Tracking Defense.” November 12, 2020. Available at: https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/
[7]: BleepingComputer. “uBlock Origin Now Blocks Sneaky First-Party Trackers in Firefox.” November 20, 2019. Available at: https://www.bleepingcomputer.com/news/security/ublock-origin-now-blocks-sneaky-first-party-trackers-in-firefox/
[8]: The Register. “Bad news: ‘Unblockable’ web trackers emerge. Good news: Firefox with uBlock Origin can stop it.” November 21, 2019. Available at: https://www.theregister.com/2019/11/21/ublock_origin_firefox_unblockable_tracker/
[9]: Ceron, J.M., et al. “CNAME Cloaking-based Tracking on the Web.” Research paper. Available at: https://arxiv.org/pdf/2102.09301.pdf
[10]: NextDNS / Romain Cointepas. “CNAME Cloaking, the dangerous disguise of third-party trackers.” December 18, 2019. Available at: https://medium.com/nextdns/cname-cloaking-the-dangerous-disguise-of-third-party-trackers-195205dc522a
[11]: Stape. “Safari ITP – Everything You Need to Know.” Available at: https://stape.io/blog/safari-itp
[12]: Louder Online. “Google Tag Gateway vs Server-Side GTM: What marketers and developers need to know.” July 13, 2025. Available at: https://louder.com.au/2025/07/14/google-tag-gateway-v-ssgtm/
[13]: Google for Developers. “Google tag gateway for advertisers.” Available at: https://developers.google.com/tag-platform/tag-manager/gateway
[14]: Love’s Data. “Google Tag Gateway: Setup Guide, Pros and Cons.” August 27, 2025. Available at: https://www.lovesdata.com/blog/google-tag-gateway/
[15]: FiveNine Strategy. “sGTM vs Google Tag Gateway: Which Tracking Setup Wins?” September 15, 2025. Available at: https://fiveninestrategy.com/google-tag-gateway-vs-server-side-gtm/
[16]: Doi, M., Fukuda, K., Mitsuya, M. “CNAME Cloaking-based Tracking on the Web: Characterization, Detection, and Protection.” IEEE Transactions on Network and Service Management, 2021. Available at: http://www.fukuda-lab.org/publications/2021/DMF_tnsm2021.pdf
