Server-Side Events as the Default
Track events from your servers, not your clients — logs with a user ID are already events.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 92%
Iyengar's stated biggest mistake in product analytics: treating SDK tracking and product analytics as synonymous and instrumenting from client-side web and mobile SDKs. Ad blockers drop 20-30% of web events; mobile forces you to reinvent tracking twice and leaves you hostage to app-version adoption. The fix is a default inversion: track events server-side, where you get full reach, full control over updates, and a workflow engineers already know — structured logs with a user ID in them.
Origin
Vijay Iyengar's 'hot take' as Head of Product at Mixpanel, drawn from watching customers' data quality degrade over years of client-side SDK instrumentation, and from the growing pattern of companies sourcing events straight from their data warehouse.
Core principles
- 01SDK tracking is not the same thing as product analytics — that conflation is the root mistake.
- 02Client-side tracking systematically produces poor data quality that is hard to maintain.
- 03The server is an environment you control; the client is not.
- 04Events are just logs with a user ID in them. Engineers have been doing this forever.
- 05If it is easier for the developer, it will get done in a higher-quality way.
- 06Client-side context can be layered on later as a supplement — server-side is the default, not the only channel.
How to run it
- 1
Recognise the three failure modes of client-side tracking
Web: ad blockers and JavaScript unreliability drop 20-30% of events, so analytics never reconcile with your internal databases. Mobile: you reinvent tracking for iOS and Android separately, producing semantically duplicate events owned by two teams. Mobile again, worse: new tracking only reaches users on the latest app version, while old and broken tracking keeps firing from the wild indefinitely.
Watch out The version-lock problem is the one people underrate — you cannot fix a tracking mistake retroactively on clients you don't control.
- 2
Make the server the default emission point
Instrument events on your servers instead of your clients. Every platform — web, mobile, TV, whatever comes next — passes through your servers, so you instantly get 100% reach with one implementation.
- 3
Frame it to engineers as structured logs
Don't sell it as a new SDK to learn. Engineers have tracked events from servers forever — they're called logs. An event is a log with some structure and a user ID in it.
Pro tip Lowering the developer's cognitive cost is the actual quality mechanism: easier instrumentation gets done properly.
- 4
Supplement with client-side context only where you must
If you need context that genuinely only exists on the client, add it later as a supplement. Server-side stays the default.
- 5
Consider the warehouse as the source
The data warehouse (bigquery, snowflake, redshift) is becoming the loading dock for all company data — product, marketing, sales, support tickets, Gong calls — all of which is naturally modelled as events. Increasingly, companies add no SDK tracking anywhere and simply source events they already trust from the warehouse.
Pro tip Reverse-ETL tools (census, hightouch) are effectively rebuilding the CDP on top of the warehouse; treat the warehouse as the trusted event source and move it into an event-optimised tool for analysis.
Watch out SQL is optimised for rows, tables, and joins — not for sequences and segmentations of events. The warehouse is a great store and a poor analysis surface for this.
In the wild
On web, ad blockers and JavaScript unreliability cause client-side tracking to drop 20-30% of events. The result is analytics that simply do not match a company's own internal databases — which destroys trust in the data before any analysis begins.
→ Moving emission server-side eliminates the drop and restores reconciliation with internal systems.
Mixpanel has seen huge growth in companies using their data warehouse as the source of events — not adding SDK tracking anywhere, and instead asking why they can't analyse support tickets and Gong calls as easily as user behaviour, since every customer interaction is an event with a timestamp.
→ Mixpanel's strategy pivoted toward tightening integration with reverse-ETL tools and the warehouse rather than pushing SDK adoption.
Common mistakes
Equating product analytics with SDK tracking
For many teams 'set up analytics' automatically means 'put a track() call in the web and mobile apps'. That conflation is the source of the data-quality problem, not an implementation detail of it.
Instrumenting iOS and Android separately
Two languages, two platforms, often two teams — producing many duplicate events that mean the same thing semantically but differ by platform, and which then have to be reconciled forever.
Assuming you can fix client tracking after ship
New tracking only applies to users on the latest version and beyond. Old and broken tracking keeps arriving from users who never update, so mistakes are effectively permanent.
Is it for you?
Best for
Engineering and data leaders setting up (or rescuing) product analytics instrumentation, especially with a mobile plus web surface
Not ideal for
Purely client-side interactions with no server round-trip that genuinely cannot be inferred server-side — those still need a client supplement
From the transcript
“but I think the biggest mistake is is setting up analytics using client-side sdks client-side tracking”
“but that's a mistake because it we've just seen time and time again it leads to poor data quality and difficulty to maintain that that…”
“is just track events from your servers right instead of your clients and that is three benefits one it's instantly cross-platform web and mobile and…”
“Engineers have been tracking events from servers forever it's called logs right”
From the episode
An inside look at Mixpanel’s product journey
Vijay Iyengar (Head of Product)