Client-Side vs. Server-Side Tracking
The difference is who sends your data: the user's browser (client-side) or your server (server-side). Client-side is simple but fragile against ad blockers. Server-side offers more control but adds cost. The footgun is thinking server-side is a magic fix.
The mental model
The defining question is: who runs the code that decides what data to send and where to send it? In client-side tracking, the user's browser does the work. In server-side tracking, a server you control acts as a middleman. This isn't a choice between good and bad, but a trade-off between simplicity and control.
How it works
Client-side tracking involves a JavaScript snippet running on the visitor's device. This script gathers event data, builds a payload, and sends a request directly to the analytics vendor's domain (e.g., google-analytics.com). Your server never sees this analytics request.
Server-side tracking flips this model. The browser sends a minimal event payload to an endpoint on your own domain. Your server receives this request, enriches it, filters it, and then forwards the processed data to analytics vendors using server-to-server APIs. You control what data leaves your ecosystem.
When to use it
Use client-side tracking for its speed and simplicity. It's ideal for projects with small budgets or when you just need basic analytics and can tolerate data loss from ad blockers. The setup is often just copying a single script tag.
Use server-side tracking when data accuracy and control are critical. It provides more resilience against ad blockers, allows you to stitch user identities, and lets you hash or remove sensitive data before it reaches any third party. This comes at the cost of higher complexity and operational overhead.
When not to use it
Avoid server-side tracking if you lack the budget or engineering team to set up and maintain the necessary infrastructure (containers, DNS, monitoring). The operational costs are not zero. Don't use client-side tracking as your sole source of truth for business-critical metrics, as its data can be incomplete due to blockers and browser privacy features.
One canonical example
A standard Google Analytics setup using gtag.js is pure client-side tracking. The script runs in the browser and sends a beacon to google-analytics.com. If an ad blocker stops the script or the beacon, the event is lost. In a server-side setup, that same browser event would instead go to a custom endpoint like metrics.your-app.com. A server container then processes the event and forwards it to Google's servers, bypassing browser-level domain blocking.
Interview question
Which statement accurately describes a primary benefit of implementing server-side tracking over client-side tracking?
- a.It allows for greater control over data enrichment and filtering before sending it to third-party vendors.Correct
- b.It completely eliminates the need for any JavaScript code on the user's browser.
- c.It significantly reduces the overall cost and complexity of setting up analytics.
- d.It guarantees 100% data capture by being fully immune to all ad blockers and browser privacy features.
Why? this is the answer
The card explicitly states that server-side tracking allows your server to "enrich it, filters it, and then forwards the processed data," giving you control over what data leaves your ecosystem. Option D is incorrect because while server-side tracking offers more resilience, no method guarantees 100% data capture or is fully immune to all privacy features.
Just read this? Test yourself on what you have been reading.
Read the original → analytics-alternatives.com
- #analytics
- #tracking
- #data engineering
- #privacy
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on analytics — each one lists the topics its interview covers.
See open roles