The "server-side vs client-side" debate has spent years being one of those topics where the answer is genuinely "it depends" and everyone hates that. Here is the plain-English version, without vendor pitches, and with an honest table you can send to your CTO.
What each actually is
Client-side tracking runs in the visitor's browser. A small script executes, reads what happened (page view, click, scroll depth), and sends that information directly to a collection endpoint. Server-side tracking runs on your infrastructure. The browser sends minimal data to your server (or a lightweight edge worker), which then decides what to forward on and where.
Neither is inherently more "privacy-friendly" or "accurate" than the other. Both can be either, depending on how they are configured. What differs is where the control point is — and how much of the truth reaches you.
The honest trade-off table
| Dimension | Client-side | Server-side |
|---|---|---|
| Setup effort | Low — paste a snippet | Higher — a service and a small routing layer |
| Ad-blocker resilience | Weak — script blocked at source | Strong — first-party endpoint on your own domain |
| Data loss on modern browsers | Meaningful (Safari ITP, blockers, tracking-protection modes) | Small — you own the surface |
| Latency on first paint | Adds one third-party request | Adds nothing if the collector is edge-cached |
| Control over what leaves your infra | Whatever the vendor script decides | Whatever you decide |
| Ease of debugging | DevTools network tab | Server logs — different skill, but more complete |
| Cost at scale | Low, until the vendor tiers you | Small edge / function bill you actually see |
| Company-level B2B identification | Works but is fragile | Ideal fit — server can resolve IP → company privately |
That last row is the one B2B teams should stare at longest. Client-side identification depends on a script that a growing share of visitors either block outright or aggressively defang. Server-side puts the identification logic on your own infrastructure, where it cannot be silently switched off by a browser update.
Where company-level identification fits
Company-level identification is a natural server-side workload. The browser only needs to make a very small request to a first-party endpoint on your own domain. That endpoint runs on the edge (typically <20 ms in Europe), does the IP-to-company resolution privately, and returns nothing that reveals what happened to the client. The user experience is unchanged. The blocker landscape is bypassed. The data path stays inside a boundary you control.
This is not a trick. It is a straightforward consequence of moving the "who is this visitor" question from the client to a service you operate. Nothing about the visitor's browsing is changed; something about your ability to see the answer is.
What server-side is not
Server-side tracking is not a way to circumvent consent. If a processing activity requires consent, it requires consent regardless of where the code runs. What server-side does change is data loss and control — not the legal basis.
A note on performance
People often worry that "tracking" is what makes a page slow. In modern setups, that is a legacy fear. A well-built loader is a few kilobytes, deferred, and fired after the page is interactive; a well-built server endpoint responds in single-digit milliseconds from the nearest edge. Neither is what will make your Core Web Vitals bad. What makes them bad is the tag manager with fourteen third-party scripts nobody has audited in three years. Fewer, better-controlled data paths are almost always faster.
When client-side still wins
Client-side is not wrong. For low-stakes analytics where you already accept blocker-driven data loss (product usage sampling, in-app UX events, quick-and-dirty landing-page tests), client-side is faster to ship and cheaper to run. The point is not that one approach is universally better; it is that if your work depends on the data — B2B pipeline is a fair example — the server-side path is more resilient and more honest about what it is doing.
The right question is not "which one is best?" It is "for which decision is this data feeding, and how much data loss can that decision tolerate?" For "who visited us this week" — none, ideally. So the architecture answer follows.
Published by
lead.box Team
More articles
See lead.box on your own traffic
Start free — no card, no sales call required. Or book a 20-minute walk-through if you want the guided tour.