If you've ever stared at your tracker showing 40 conversions while Ads Manager insists there were only 22, you already understand the problem this guide is about. It's the difference between an algorithm that optimizes toward profitable users and one that's flying half-blind on the data it actually received. On paid social, the platform optimizes on what it sees, not on what truly happened - so every conversion that never reaches Meta or TikTok is a signal you paid for and then threw away.
Most people running social traffic still rely almost entirely on the browser pixel. A few years ago that was fine. Today it leaks badly, and the leak is getting worse. This is a walkthrough of why client-side tracking fails, what server-side tracking actually fixes, and how to wire it up so your attribution survives the trip from click to conversion - with the specific wrinkles that matter when there's a tracker sitting in the middle, which there almost always is in affiliate setups.
The big one is Apple's App Tracking Transparency. When a user opts out (most do), the identifiers the pixel depends on get stripped or limited. On top of that you've got ad blockers, aggressive privacy browsers, consent banners that gate scripts until the user clicks, and the slow death of third-party cookies. None of these are edge cases anymore - together they can quietly eat a double-digit percentage of your events.
Same case in other social media ex.: TikTok has an extra problem that catches a lot of media buyers off guard: most users tap your ad and land inside TikTok's in-app browser, a restricted WebView. That environment limits cookie access and strips identifiers the pixel needs to match the conversion back to a user. So even a "perfectly installed" TikTok pixel can silently under-report, and you'd never know from looking at the install status.
The result is the same on both platforms: conversions happen, your offer or network records them, but the ad platform never hears about a chunk of them. Optimization suffers, your reported CPA looks worse than reality, and scaling decisions get made on bad numbers.
The goal isn't to replace the pixel - it's redundancy. Think of it as two paths carrying the same event:
Pixel still fires in the browser and is useful for page views, view-content, add-to-cart and remarketing signals.
The server-side event is the resilient backup that catches conversions the browser dropped. For a high-value final action like a purchase or lead, the server event is usually the more reliable of the two.
When both paths work, you get far better coverage. But running both creates a new risk that trips up almost everyone the first time: the same conversion arriving twice.
The fix is deduplication, and it hinges on one thing: a shared event_id. Both the browser event and the server event must carry the same event_id and the same event name (e.g. Purchase). When the platform sees two events with matching identifiers, it merges them and counts one.
A few practical rules that save you grief:
The answer is the click identifier. When a user clicks your ad, the platform appends its click ID to the URL - fbclid for Meta, ttclid for TikTok. Your tracker needs to capture and store that click ID at the moment of the click. Then, when the conversion postback comes in, the tracker fires the server-side event to CAPI / Events API and passes that stored click ID back. That's what closes the loop and tells the algorithm: this specific click converted.
Concretely, the identifiers worth passing on the server event are:
So don't chase a perfect match. Chase a stable, explainable gap. Once CAPI/Events API is live and deduplicated, that gap should shrink and then hold steady. A gap that suddenly widens is your early warning that something broke - a missing click ID, a changed event name, an expired access token.
Most people running social traffic still rely almost entirely on the browser pixel. A few years ago that was fine. Today it leaks badly, and the leak is getting worse. This is a walkthrough of why client-side tracking fails, what server-side tracking actually fixes, and how to wire it up so your attribution survives the trip from click to conversion - with the specific wrinkles that matter when there's a tracker sitting in the middle, which there almost always is in affiliate setups.
Why browser pixel leaks?
The pixel is a piece of JavaScript that fires in the user's browser. That's its weakness. Anything that interferes with the browser interferes with your data, and a lot of things now do.The big one is Apple's App Tracking Transparency. When a user opts out (most do), the identifiers the pixel depends on get stripped or limited. On top of that you've got ad blockers, aggressive privacy browsers, consent banners that gate scripts until the user clicks, and the slow death of third-party cookies. None of these are edge cases anymore - together they can quietly eat a double-digit percentage of your events.
Same case in other social media ex.: TikTok has an extra problem that catches a lot of media buyers off guard: most users tap your ad and land inside TikTok's in-app browser, a restricted WebView. That environment limits cookie access and strips identifiers the pixel needs to match the conversion back to a user. So even a "perfectly installed" TikTok pixel can silently under-report, and you'd never know from looking at the install status.
The result is the same on both platforms: conversions happen, your offer or network records them, but the ad platform never hears about a chunk of them. Optimization suffers, your reported CPA looks worse than reality, and scaling decisions get made on bad numbers.
What CAPI and the Events API actually do
Meta's Conversions API (CAPI) are the server-side answer to all of the above. Instead of relying on a script in a flaky browser, you send the conversion event directly from a server to the platform's measurement endpoint. No ad blocker, no WebView, no cookie banner sits in the way.The goal isn't to replace the pixel - it's redundancy. Think of it as two paths carrying the same event:
Pixel still fires in the browser and is useful for page views, view-content, add-to-cart and remarketing signals.
The server-side event is the resilient backup that catches conversions the browser dropped. For a high-value final action like a purchase or lead, the server event is usually the more reliable of the two.
When both paths work, you get far better coverage. But running both creates a new risk that trips up almost everyone the first time: the same conversion arriving twice.
Deduplication. The part everyone gets wrong
If your browser pixel and your server send the same Purchase event without telling the platform they're the same event, you get counted twice. Inflated conversions, a CPA that looks too good to be true, and an optimization signal full of phantom data.The fix is deduplication, and it hinges on one thing: a shared event_id. Both the browser event and the server event must carry the same event_id and the same event name (e.g. Purchase). When the platform sees two events with matching identifiers, it merges them and counts one.
A few practical rules that save you grief:
- Generate the event_id once, at the moment of the action, before any tag fires - then pass that same value into both the pixel and the server call. A common pattern is combining the order/transaction ID with a timestamp.
- The event name must match exactly on both sides. Purchase on the browser and CompletePayment on the server will never dedupe.
- Timing matters. On TikTok, duplicate events with the same event_id are merged when they arrive within a 48-hour window of the first one. Meta similarly expects the two versions close together. Don't fire the server event days late and expect clean merging.
keeping attribution through a tracker
Here's where affiliate setups differ from a plain e-commerce store. You usually have a tracker (RedTrack, Voluum, BeMob, Binom and similar) sitting between the ad and the offer, and the conversion itself fires on the network/advertiser side and comes back to you as a postback (S2S). The browser is often long gone by the time the conversion is confirmed. So how does the platform know which click earned the sale?The answer is the click identifier. When a user clicks your ad, the platform appends its click ID to the URL - fbclid for Meta, ttclid for TikTok. Your tracker needs to capture and store that click ID at the moment of the click. Then, when the conversion postback comes in, the tracker fires the server-side event to CAPI / Events API and passes that stored click ID back. That's what closes the loop and tells the algorithm: this specific click converted.
Concretely, the identifiers worth passing on the server event are:
- Click IDs - fbc (derived from fbclid) and the _fbp cookie for Meta; ttclid and ttp for TikTok. These are the single biggest lever on match quality.
- Hashed user data where you legitimately have it - email, phone, IP address, user agent. More valid match signals = higher match quality = better optimization.
Why your tracker and Ads Manager will never perfectly agree
Set your expectations now: these numbers will not match to the unit, and that's normal. They count different things. Your tracker logs every conversion the network reports to you. The ad platform only counts conversions it can attribute to one of its clicks, inside its attribution window (Meta's default is typically 7-day click, 1-day view; TikTok offers its own configurable windows). A conversion that falls outside the window, or that the platform can't match to a click, simply won't appear in Ads Manager even though it's real revenue in your tracker.So don't chase a perfect match. Chase a stable, explainable gap. Once CAPI/Events API is live and deduplicated, that gap should shrink and then hold steady. A gap that suddenly widens is your early warning that something broke - a missing click ID, a changed event name, an expired access token.
A verification checklist before you trust the data
Don't declare victory the moment events show up green. Run the pixel and server side in parallel for a few weeks and confirm:- Both browser and server events are arriving in Events Manager, for the same event names.
- Deduplication is actually firing - you're seeing one merged conversion, not two.
- Match quality is healthy (on Meta, aim for an Event Match Quality comfortably above the midpoint; on TikTok, watch the match quality score) - driven mostly by click IDs and hashed user data.
- The click ID is present on server-side conversions, not blank.
- Your access tokens are valid and not about to expire silently.
- The tracker-to-Ads-Manager gap is stable and you can explain it.
