Client vs server tracking: pros, cons, examples

WHY IT MATTERS Placement decides whether an event is complete, reliable, and trustworthy. The right answer is per event, weighing context against reliability.

WHAT IT TESTS Whether you can articulate concrete pros and cons and assign events correctly.

A GOOD ANSWER COVERS Client-side tracking runs in the browser or mobile app. Pros: it naturally captures interface context, clicks, page or screen views, scroll depth, hovers, and viewport and device details, and it can fire before any backend call. Cons: ad blockers and privacy settings drop a meaningful fraction of events, flaky networks and page-close cause loss, and a determined user can spoof or replay events, so it is unreliable for anything that must be exact. Server-side tracking runs in your backend. Pros: it is reliable being immune to ad blockers and supporting retries, secure and authoritative since the user cannot tamper with it, and it sits next to your source-of-truth business data. Cons: it is blind to purely client interactions that never hit the server, and it loses device or UI context unless the client forwards it.

WHEN IT MATTERS Use client-side for engagement and interface signals where some loss is acceptable; use server-side for accuracy-critical, trusted, revenue-bearing events. Mature stacks blend both and reconcile identities.

COMMON WRONG ANSWERS Declaring server-side strictly better, since it misses UI behavior. Declaring client-side strictly richer, since it is lossy and spoofable. Tracking revenue client-side where it can be blocked or faked. Ignoring ad blocker impact on counts.

ONE CONCRETE EXAMPLE Best captured on the client: a video_play or button_hover event, a pure interface interaction the server never sees. Best captured on the server: a subscription_renewed event fired when billing confirms the charge, so the revenue record is reliable and tamper-proof regardless of what the client does, and the two streams are reconciled by identity during analysis.