Client-side vs server-side event tracking

WHAT THIS TESTS This checks whether you can match tracking placement to event semantics and trust needs, rather than treating it as a single global choice.

A GOOD ANSWER COVERS Client-side tracking instruments the browser or app and is the only place to capture pure interface signals: clicks, scroll depth, hovers, time on screen. It is rich but lossy: ad blockers and privacy tooling drop a meaningful fraction of events, flaky networks lose more, and a determined user can forge or suppress events, so it is untrustworthy for anything sensitive. Server-side tracking fires from your backend when a request is processed; it is reliable, hard to tamper with, immune to ad blockers, and authoritative for transactions, entitlements, and revenue, but it is blind to interactions that never reach the server. The mature answer is hybrid: route each event to the layer where it is most reliable, and stitch them by a shared identity.

COMMON WRONG ANSWERS Saying server-side is always better, then having no way to measure scroll or a button hover. Saying client-side is fine for revenue, exposing counts to ad blockers and fraud. Ignoring identity stitching so the two streams cannot be joined.

LIKELY FOLLOW-UPS How does server-side tracking, sometimes via a server side tagging gateway, help with ad blocker resilience and PII control? How do you reconcile a client purchase event with the server's authoritative one? Which side owns consent enforcement?

ONE CONCRETE EXAMPLE An add-to-cart click is tracked client-side because it is a UI intent. The actual purchase completed is tracked server-side at payment confirmation, so revenue numbers are accurate and cannot be spoofed. Both events carry the same user ID, letting analysis connect intent to the trustworthy outcome.