Server-Side vs Client-Side Tracking: Which Approach?
Architectural comparison: ad blockers, ITP, data control, privacy, cost. When to go server-side and when client-side is enough.
Two fundamentally different collection architectures
Client-side tracking is the traditional web analytics model: a JavaScript script runs in the user’s browser, collects interaction data, and sends it directly to analytics and marketing platforms (Google Analytics, Facebook, etc.). It is simple, proven, and how the vast majority of sites work today.
Server-side tracking shifts this logic to the server. The browser sends data to an endpoint you control (your own server or a cloud service), and that server redistributes the data to final destinations. The browser never communicates directly with third-party servers.
This architectural difference has profound implications for data quality, compliance, performance, and cost.
Impact on data quality
Client-side tracking is now seriously degraded. Ad blockers (used by 30 to 40% of internet users depending on the sector) block collection scripts. Browsers impose increasing restrictions: Intelligent Tracking Prevention (Safari) limits first-party cookies to 7 days, Firefox Enhanced Tracking Protection blocks known trackers, and Chrome plans similar restrictions.
The concrete result: a site relying solely on client-side loses a significant portion of its data. User journeys are fragmented, attribution is distorted, and reported volumes underestimate reality.
Server-side bypasses most of these obstacles. Requests go to your own domain (first-party), making them invisible to ad blockers. Cookies are set by the server (server-set cookies), escaping ITP limitations. The collection rate can increase by 15 to 30% depending on audiences.
| Criterion | Client-side | Server-side |
|---|---|---|
| Ad blocker blocking | Vulnerable (30-40% loss) | Bypassed (first-party domain) |
| ITP/ETP restrictions | Cookies limited to 7 days | Server-set cookies (no ITP limit) |
| Load time | Third-party scripts = page weight | Lighter (single endpoint) |
| Data control | Data sent directly to third parties | Server-side filtering and enrichment |
| Infrastructure cost | None | Server(s) to provision |
| Technical complexity | Low (copy-paste tags) | High (infra, mapping, monitoring) |
| Debugging | Browser DevTools | Server logs, more complex |
| Data latency | Real-time | Near real-time (extra hop) |
Privacy and compliance
Server-side offers a structural advantage in data protection. Since all requests pass through your server, you can filter, anonymize, or delete data before it reaches third-party platforms. You can remove IP addresses, truncate identifiers, or make data transmission conditional on the user’s consent status.
With client-side, once the script is loaded, you have only limited control over what the tag actually collects. Facebook or TikTok pixels, for example, capture signals (URL, user agent, IP address) that you do not fully control.
This increased server-side control does not mean it exempts you from consent. Regulatory authorities consider that cookie placement and personal data collection require consent regardless of the technical architecture. But server-side makes compliance easier by providing a centralized control point.
Real cost and complexity
The main barrier to server-side is its cost. A GTM Server-Side container on Google Cloud costs between 50 and 500 euros per month depending on traffic, not counting configuration and maintenance time. Managed solutions like Addingwell or Stape simplify deployment but add a monthly subscription (starting from 30 to 100 euros per month).
Beyond infrastructure, you need to factor in configuration time: mapping each client-side tag to its server-side equivalent, configuring the server container’s clients and tags, testing data flows, and monitoring continuously. A complete server-side migration project typically represents between 5 and 15 days of consultant work.
Which approach to choose?
Client-side remains relevant for sites with low data stakes, projects with a limited budget, or cases where ad blockers are not a significant problem (professional audiences on desktop, for example).
Server-side is justified when data quality is critical: e-commerce sites with significant media budgets, businesses whose marketing attribution drives significant investments, or organizations with advanced compliance requirements.
The most common approach today is hybrid: a client-side container for initial collection and a server-side container for processing and redistribution. This is the model promoted by Google with GTM Server-Side, and it offers the best compromise between data quality, compliance, and controlled cost.