Why S2S postback beats pixel tracking
A conversion that happened but was never recorded is worse than one that never happened at all — it's a publisher who did the work and doesn't get paid, and an advertiser whose reporting quietly understates its own results. The tracking method underneath a payout model decides how often that happens. Here's how the two most common methods actually differ.
Pixel tracking fires from the visitor's browser and breaks on ad blockers, privacy settings, and early exits. S2S postback fires from the advertiser's own server and doesn't depend on the visitor's browser at all. It takes a little more setup, but it's the more reliable foundation for a programme paying out real money.
What pixel tracking is
A tracking pixel is a small script or 1x1 image placed on a confirmation page — the "thank you for your order" or "signup complete" screen. When that page loads in the visitor's browser, the script fires and reports the conversion back to the network. It's simple to install: paste a snippet, done.
Where pixel tracking breaks
The pixel only fires if three things all happen: the confirmation page loads fully, the script isn't blocked, and the visitor stays long enough for it to execute. Any one of those failing means a real conversion goes unrecorded.
Ad blockers and browser privacy settings
A meaningful share of browsers block third-party tracking scripts by default. Those conversions still happen — they just never get reported, and the publisher who sent that traffic never gets paid for it.
Multi-device and multi-session journeys
A visitor who clicks on their phone and completes the purchase later on a laptop breaks a pixel-only setup unless a separate mechanism stitches the two sessions together, which most simple pixel implementations don't do.
Early exits
If a visitor closes the tab, loses connection, or navigates away before the confirmation page finishes rendering, the pixel never gets the chance to fire — even though the transaction on the advertiser's side already went through.
None of these failures show up as errors — the pixel just quietly doesn't fire. The only way most programmes notice is a publisher flagging a conversion that never got credited.
What S2S postback is
Server-to-server postback works from the other direction. Instead of relying on the visitor's browser to report the conversion, the advertiser's own backend sends a request directly to the network the moment a conversion is confirmed in their system — matched to the original click using a click ID passed through at the start of the visit.
Why S2S is more reliable
Because the confirmation comes from the advertiser's server rather than the visitor's browser, it doesn't depend on scripts loading, ad blockers being absent, or the visitor staying on a page long enough. It fires based on what actually happened in the advertiser's own system of record — the same system that would process a refund or fulfill an order — which is about as close to ground truth as tracking gets.
Side-by-side comparison
| Factor | Pixel tracking | S2S postback |
|---|---|---|
| Where it fires from | Visitor's browser | Advertiser's server |
| Affected by ad blockers | Yes | No |
| Survives multi-device journeys | Only with extra setup | Yes, via click ID |
| Setup effort | Low — paste a snippet | Moderate — backend integration required |
| Ongoing reliability | Degrades as browsers restrict tracking further | Stable once configured |
Is pixel tracking ever the right call?
Yes — when there's no backend access to hook into, such as a publisher-side landing page with no server component, or during a fast test launch where a full S2S integration isn't worth setting up yet. Pixel tracking is a reasonable starting point; it just shouldn't be the permanent foundation for a programme that's paying out real money on what it reports.
The tracking method is the foundation every payout model in our CPS, CPL, and CPI guide sits on. A CPS programme with leaky pixel tracking underpays honest publishers by design — not because anyone's cheating, but because the method itself is dropping real conversions.
How Kapvexa handles it
S2S postback is the default tracking method on Kapvexa, with pixel and link-based tracking available as a fallback where a backend integration isn't yet in place. Every click gets a click ID at the start of the session, so conversions confirmed later — on any device — still attribute back to the publisher who sent the traffic.
Mistakes to avoid
| ❌ Costly habit | ✅ Better approach |
|---|---|
| Running pixel-only tracking on a paid programme | Move to S2S postback wherever backend access exists |
| Assuming a silent pixel failure means no conversion happened | Cross-check against the advertiser's own order or lead records |
| No click ID passed at the start of the visit | Issue one on every click so later postbacks can attribute correctly |
| Treating pixel tracking as permanent | Use it as a bridge until backend access allows a proper S2S integration |
| Ignoring multi-device journeys | Rely on server-side matching instead of browser-session continuity |
FAQ
Does S2S postback replace the need for a tracking pixel entirely?
For conversion events, yes, wherever the advertiser has backend access to send the postback. Pixels still have a role for simpler, front-end-only integrations where no backend hook is available.
Why would a pixel fail to fire even on a real conversion?
Ad blockers, browser privacy settings, script errors, slow page loads, and visitors closing the tab before the confirmation page fully renders can all prevent a pixel from firing even though the conversion genuinely happened.
Is S2S postback harder to set up than a pixel?
It takes a bit more setup, since it requires the advertiser's backend to send a request to a postback URL on conversion. Once configured, it needs no further maintenance and doesn't depend on anything happening in the visitor's browser.
Can pixel and S2S tracking run at the same time?
Yes, and some programmes do exactly that during a transition period — running both and comparing the numbers is a fast way to see how much a pixel-only setup is undercounting.
Does S2S tracking work for mobile app installs?
Yes — for apps it's typically implemented through an attribution SDK that reports the install and any in-app events back through a server-side callback, the same underlying principle as web postback.
Track every conversion the way it actually happened.
S2S postback by default, matched to the click that earned it.
Talk to Kapvexa