Client-side vs server-side purchase tracking (CAPI) for mobile apps
Updated July 10, 2026 · 6 min read
Client-side tracking sends events from inside your app using an SDK; server-side tracking (Meta's Conversions API, or CAPI) sends the same events from your backend. The difference matters because client events are the ones that get dropped — by ATT denial, ad blockers, network loss, and app crashes — while server events are not.
For a modern app you want both, sending each event once via deduplication. Here's how to reason about it.
What client-side tracking is good at
Client-side events carry rich device and browser identity (the ad-click identifiers, cookies, and app instance data) that make attribution accurate. When the user has granted permission, the client SDK is the highest-quality signal you have.
Its weakness is fragility: on iOS a denied ATT prompt suppresses it, and any purchase confirmed after the app is backgrounded or killed may never fire.
What server-side tracking (CAPI) is good at
Server-side events fire from your backend, so they aren't affected by ATT, ad blockers, or the app's runtime state. If your server knows a purchase happened, Meta will hear about it.
Its weakness is identity: your server doesn't automatically have the click identifiers the client does. You have to capture those at checkout time and pass them through to the server call, or match quality suffers.
Why you need both
Each covers the other's blind spot:
- ATT-denied iOS users: only the server path delivers the purchase.
- Post-purchase crashes: the server already has the confirmation.
- Attribution accuracy: the client path supplies the identity the server lacks.
- Redundancy: if one path drops an event, the other still lands it.
Deduplication: sending once, counting once
If both paths send the same purchase, Meta must know they're the same event or it will double-count. You solve this with a shared event ID: generate one ID for the purchase and send it on both the client event and the server (CAPI) event. Meta collapses them into a single conversion.
The value and currency must match on both, too. Mismatched values undermine deduplication and value-based optimization.
Frequently asked questions
What is the Conversions API (CAPI)?
The Conversions API is Meta's server-side method of sending events (like purchases) directly from your backend to Meta, instead of from the user's device. Because it doesn't run in the app or browser, it isn't affected by App Tracking Transparency, ad blockers, or the app crashing after a purchase.
Do I need both client-side and server-side tracking?
For accurate optimization, yes. The client path provides rich identity for attribution but is fragile; the server path is reliable but identity-poor. Running both — deduplicated with a shared event ID — gives you the accuracy of the client and the reliability of the server.
How does event deduplication work?
You assign each purchase a single event ID and send that same ID on both the client-side and server-side events. Meta uses the ID (together with the event name) to recognize the two as one event and count it a single time.
Isn't server-side tracking enough on its own?
It's reliable, but on its own it often lacks the click identifiers that make attribution precise, so Event Match Quality drops. Pairing it with the client event — or explicitly forwarding the captured click identity to your server — restores match quality.
Related guides
Not sure which of these is breaking your app?
Zoruko audits your app code for broken Meta and TikTok signal chains — free — and ships each fix as a pull request you review.
Run a free audit