Client-side vs. Server-side Event Tracking: When and Why?

WHAT THIS TESTS: Your ability to reason about system design trade-offs, specifically data reliability, security, and implementation cost. The interviewer wants to see if you understand that event tracking is not just about collecting data, but about collecting trustworthy data for critical business decisions. It's a test of business-aware engineering judgment.

A GOOD ANSWER COVERS: Four key points in order. First, define client-side (browser/mobile SDKs) and server-side (backend API calls) tracking. Second, contrast the core trade-offs: client-side is easy for UI events and automatically captures rich device context, but is unreliable due to ad blockers (which can block 20-40% of events), network failures, and browser behavior. Server-side is the source of truth—highly reliable, secure, and able to track non-UI events—but requires more engineering effort and loses automatic client context unless passed explicitly. Third, state a clear, defensible strategy, such as tracking all critical, state-changing events on the server and using client-side only as a supplement. Fourth, provide a specific, contrasting example.

COMMON WRONG ANSWERS: The biggest red flag is treating them as interchangeable or stating a preference without strong justification. Many candidates dramatically underestimate the data loss from ad blockers and network issues on the client. Another mistake is not recognizing that server-side is the only option for events that don't have a user interface, like a payment being confirmed via a webhook or a nightly data processing job completing. Finally, suggesting a "server-side only" approach without acknowledging the implementation overhead and the loss of rich client context is a sign of inexperience.

LIKELY FOLLOW-UPS: "How would you handle a situation where you need both rich client context and server-side reliability for a single event?" (Answer: The client sends context to the server, which then triggers the canonical server-side event). "How would you design a system to unify events from both sources?" (Answer: Discuss Customer Data Platforms like Segment/Rudderstack, or a custom ingestion pipeline with a clear schema and de-duplication logic). "What are the cost implications of each?"

ONE CONCRETE EXAMPLE: Use server-side tracking for a "Subscription Purchased" event. This is a critical business metric directly impacting revenue. It must be 100% accurate. You cannot risk an ad blocker or a user closing their browser after payment but before a client-side event fires. The source of truth is your server confirming a successful charge from a payment processor like Stripe. Conversely, for a "Button Hovered" event, client-side tracking is appropriate. The data is not business-critical, and the high volume would make server-side tracking prohibitively complex and expensive. The trade-off of lower accuracy for ease of implementation is acceptable here.