Can you drop the pixel entirely and rely only on S2S?

You can, and for expensive conversions it's arguably more reliable, but for fast signals at the top of the funnel a pixel is usually still cheaper and quicker for the platform's algorithm to act on.

Why is a postback better than a pixel for confirming a deposit?

Because a deposit is a delayed event that can happen with the original browser session long gone; a pixel simply has no way to catch it at that point, while a server-side postback doesn't depend on the user's browser at all.

What is conversion deduplication and why does it matter when using both methods?

It's the mechanism that stops the same conversion from being counted twice — once from the pixel, once from the postback. It's usually solved with a shared event ID or clickid that lets the platform recognize it as one event.

Does the clickid get lost when switching from pixel to S2S tracking?

It shouldn't, as long as the clickid is carried through the whole chain from the start — click, through the PWA, to the affiliate program — regardless of which method ends up confirming the conversion.

Does APEX support S2S postbacks out of the box?

Yes, including integration with trackers and affiliate programs such as Keitaro↔FB CAPI, so expensive conversions can be confirmed server-side without building that logic yourself.

S2S Postback vs. Browser Pixel: Which One to Trust for Deposits

S2S postback vs browser pixel is an old tracking question that gets sharper in PWA arbitrage, where a pixel can drop out easily and a deposit might land days after install. Here's the mechanical difference, where each method holds up better, and why combining both beats relying on either alone.

How a Browser Pixel Works

A pixel — say, a Facebook Pixel event — fires in the user's browser at the moment of conversion: the page loads, the script runs, an event gets sent to the platform's server. It's fast and simple for events that clearly happen right there in the browser, like a “thanks for registering” page loading.

Where a Pixel Breaks Down

A pixel depends entirely on the user's browser finishing the job: ad blockers, privacy modes (Safari's ITP restrictions, for instance), a slow page load, or a closed tab before the event fires can all quietly stop it from ever sending. PWAs add another failure point: if the conversion happens after the user moves into the installed app rather than a regular browser tab, the pixel's context is easy to lose entirely.

How an S2S Postback Works

A server-side postback gets sent directly from the affiliate program's or tracker's backend to the ad platform's server (Facebook CAPI, for instance), bypassing the user's browser completely. The affiliate program decides for itself when a conversion is actually confirmed — a deposit that genuinely cleared, not just a “payment” page loading — and fires the postback at that point, tied back to the original clickid.

Why S2S Is More Reliable for Deposits

A deposit can happen hours or days after a PWA install, often with the original browser session long gone. A browser pixel has no way to “wait around” for a delayed event like that, while an S2S postback doesn't depend on whether the original tab is even still open — it fires server-side, at the affiliate's backend, exactly when the payment system confirms the deposit actually cleared.

When a Browser Pixel Still Earns Its Place

A pixel is genuinely useful for fast optimization signals — an “installed the PWA” or “opened the registration page” event helps a platform's algorithm find similar audiences quickly, even when it's not the final, valuable conversion. Relying on a pixel alone for expensive target events like deposits is a real risk, but cutting it out of the mix entirely isn't optimal either — it's cheaper and faster for the top of the funnel.

Using Both Together

A solid setup uses the pixel for early, cheap events (open, registration) to keep the platform's algorithm optimizing fast, and treats the S2S postback as the source of truth for expensive confirmed conversions (deposit), with deduplication through a shared clickid so the same event never gets counted twice. APEX supports exactly this kind of postback setup — including a Keitaro↔FB CAPI integration — so expensive events get confirmed server-side instead of hoping a browser pixel makes it all the way to the platform.

FAQ

Can you drop the pixel entirely and rely only on S2S?: You can, and for expensive conversions it's arguably more reliable, but for fast signals at the top of the funnel a pixel is usually still cheaper and quicker for the platform's algorithm to act on.
Why is a postback better than a pixel for confirming a deposit?: Because a deposit is a delayed event that can happen with the original browser session long gone; a pixel simply has no way to catch it at that point, while a server-side postback doesn't depend on the user's browser at all.
What is conversion deduplication and why does it matter when using both methods?: It's the mechanism that stops the same conversion from being counted twice — once from the pixel, once from the postback. It's usually solved with a shared event ID or clickid that lets the platform recognize it as one event.
Does the clickid get lost when switching from pixel to S2S tracking?: It shouldn't, as long as the clickid is carried through the whole chain from the start — click, through the PWA, to the affiliate program — regardless of which method ends up confirming the conversion.
Does APEX support S2S postbacks out of the box?: Yes, including integration with trackers and affiliate programs such as Keitaro↔FB CAPI, so expensive conversions can be confirmed server-side without building that logic yourself.

Build your PWA in APEX in minutes

Cloaking, anti-bot, push, split tests and your own domains — in one service.

Get started free