Client-side tracking alone is getting less reliable every year, not because any one browser or OS shipped a single dramatic change, but because ad blockers, intelligent tracking prevention, in-app browsers, and privacy-preserving defaults now each quietly clip a slice off the same signal. No single loss is catastrophic on its own. Added together, a client-only setup can under-report conversions by a wide and inconsistent margin, and because the loss varies by browser, device, and channel, it doesn’t show up as a clean, explainable drop — it shows up as noisy, hard-to-trust numbers that make every optimisation decision downstream a little shakier.
Server-side tracking flips part of the model: instead of relying on the browser or app to fire a pixel that might get blocked, your own server sends the conversion event directly to the ad platform or analytics tool, using data you already control. Most teams landing on this aren’t abandoning client-side tracking — they’re running both, and the interesting data now lives in the gap between what the two report.
Data Points to Track
- Match rate between client and server events: the percentage of conversions that show up in both the client-side pixel and the server-side send for the same underlying action
- Event deduplication ID coverage: whether every event fired from both paths carries a shared identifier so the ad platform can merge them instead of double-counting
- Server-side send latency: time between the actual conversion and the server-side event reaching the destination platform, since some networks weight fresher signals more heavily in optimisation
- Client-only vs. server-only event rate: conversions captured by one path but not the other, segmented by browser, device type, and in-app-browser vs. full browser
- Enrichment field completeness: how much additional first-party data (hashed email, order value, customer status) the server-side send includes that the client-side pixel never had access to
Setup Steps
- Stand up a server-side endpoint (your own, or a tag-manager server container) that can receive conversion events from your backend and forward them to each ad platform’s Conversions API.
- Generate a shared event ID at the point of conversion and pass it to both the client-side pixel and the server-side send, so downstream deduplication actually works instead of inflating conversion counts.
- Enrich server-side events with first-party data your client-side pixel never sees — order value, customer lifetime status, hashed contact details — since this is most of the accuracy gain over pixel-only tracking.
- Monitor match rate as an ongoing metric, not a one-time migration check, since browser and OS-level tracking restrictions keep shifting and a good match rate today can degrade quietly over months.
- Reconcile weekly against your own backend’s source-of-truth conversion count, treating any platform’s reported number as an estimate to validate rather than a figure to accept at face value.
Actionable Insights
A falling match rate is usually the platform-reported number becoming more trustworthy relative to the client-only baseline, not less — it means server-side is catching conversions the pixel alone was silently missing, which is the whole point of running both. Segment the client-only vs. server-only rate by device and browser to see exactly where the client-side gap is worst; in-app browsers and privacy-forward browsers typically show the largest divergence, and that’s where the server-side signal matters most.
The teams getting real value out of this aren’t chasing a perfect 100% match rate — they’re using the gap itself as a diagnostic, and treating their own backend conversion count as the number every ad platform’s reporting gets checked against, rather than the other way around.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert