Browser, app, and server purchase tracking for web and mobile CAPI
Updated July 10, 2026 · 9 min read
Browser and app tracking observes the user runtime: browser cookies, click identifiers, app SDK context, paywall exposure, and immediate intent. Server tracking observes verified business facts: payment settled, subscription renewed, receipt validated, refund issued.
A serious Meta or TikTok setup does not choose one. It uses both, then makes the two paths converge on one event identity and one revenue truth.
Browser and app path: rich identity, limited authority
The browser Pixel and mobile App SDK see things your backend often cannot see naturally: _fbp, _fbc, app scoped identifiers, device context, paywall opens, checkout CTA timing, and user agent context. That makes the client path important for matching and upper funnel diagnostics.
Its weakness is authority. A success callback, redirect page, or receipt callback can be skipped, duplicated, blocked, backgrounded, or executed before payment state is final.
Server path: strong authority, limited identity
CAPI fired from a backend, Stripe webhook, RevenueCat webhook, Adapty webhook, or receipt validation service is authoritative because it can wait for verified money. It is also resilient to ad blockers, app termination, redirect abandonment, and browser script failures.
Its weakness is identity. By the time the webhook fires, the request is coming from Stripe or a subscription platform, not from the user's browser or device. Unless identity was copied into checkout metadata or a first party order row, the server event arrives financially correct but attribution poor.
The split-brain bugs
Broken implementations usually have one of these shapes:
- Client only: good identity for users who allow tracking, but missing conversions when scripts are blocked, ATT is denied, or checkout completes on the server.
- Server only: reliable revenue delivery, but weak match quality because _fbp, _fbc, app identifiers, user agent, and first party visitor IDs were never forwarded.
- Dual path without dedup: both paths fire but with unrelated event IDs, inflating conversion count and corrupting value optimization.
- Dual path with different semantics: client fires Subscribe or InitiateCheckout while server fires Purchase for the same transaction, creating misleading funnel math.
Reference architecture
Ad click
-> landing page captures fbclid, _fbp/_fbc, visitor_id
-> paywall emits ViewContent
-> checkout creation freezes event_id + identity envelope
-> client emits InitiateCheckout / optional Purchase with event_id
-> Stripe, RevenueCat, Adapty, or backend verifies money
-> CAPI emits authoritative Purchase with the same event_id
-> Meta deduplicates client + server into one conversionDeduplication: the convergence layer
Deduplication is the mechanism that lets the two paths converge. Generate or persist one event_id for the conversion and send it through both producers with the same event_name. That lets Meta combine rich client identity with verified server signal.
The event_id alone is not enough for clean learning. The value, currency, transaction ID, and event semantics should also describe the same economic fact.
Frequently asked questions
What is the Conversions API (CAPI)?
The Conversions API is Meta's server method for 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 and server tracking?
For serious paid acquisition, yes. The client path provides strong browser or app identity but is fragile. The server path provides verified revenue but needs forwarded identity. Running both with deduplication gives Meta stronger input than either path alone.
How does event deduplication work?
You assign each purchase a single event ID and send that same ID on both the client event and server event. 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 tracking enough on its own?
Not usually. Server tracking is reliable, but without forwarded click and visitor identity it often has weak match quality. You still need browser or app identity captured before checkout and replayed into the server event.
Related guides
Not sure which signal path is breaking?
Zoruko audits your web and mobile code for broken Meta and TikTok signal chains, then ships each fix as a pull request you review.