Why is an S2S postback better than the browser pixel?

It passes the conversion from the server and is not lost to blockers, ITP or session loss. For delayed gambling deposits it is decisive.

How do I avoid duplicate conversions?

Deduplicate by a single event_id: pixel and CAPI send one event with the same key, and Facebook merges them into one.

Should I send registration or deposit to Facebook?

Optimize for payers: map FTD to Purchase and registration to a separate event. Otherwise the algorithm brings cheap but non-paying traffic.

What is the click id and why does it matter?

A unique click identifier (subid/external_id). The postback uses it to tie the deposit to a specific visit, source and ad.

No — any S2S tracker works (RedTrack, Binom, etc.). Keitaro is popular, but the click id → postback → CAPI chain is the same.

Postbacks Keitaro ↔ Facebook CAPI

A deposit must reach the tracker and the pixel from the network exactly once — no loss, no duplication. Here is the end-to-end chain: click id on entry, postback from the network into Keitaro, the event sent to Facebook Conversions API, and deduplication with the browser pixel. The cleanliness of this chain decides how FB optimizes the buy.

Why you need a server-side postback

The browser pixel loses some conversions to blockers, ITP and session loss between the click and a deposit that happens hours later. A server-to-server postback passes the conversion straight from the network server into the tracker and CAPI, so the deposit arrives even when the browser event is lost. For gambling with delayed deposits this is critical.

Click id as the link

Everything hangs on a unique click id (subid / external_id) that travels from the click through the showcase and offer to the postback. It ties the deposit to a specific visit, source and ad. If the click id is lost along the way, attribution falls apart and FB gets conversions with no campaign link.

Event deduplication

If the same event goes via both the browser pixel and CAPI, it must be deduplicated by event_id, or FB counts two deposits instead of one. A single event_id across both channels is the standard fix: pixel and server send one event with the same key and Facebook merges them into one.

Mapping network statuses

Networks send different statuses: registration, first deposit, repeat deposit, rejected. Map them cleanly to pixel events (for example FTD to Purchase) so FB optimizes for payers, not registrations. Wrong mapping is a common reason the algorithm brings cheap but non-paying traffic.

How it is wired in APEX

APEX passes the click id through the showcase and offer, receives tracker postbacks inbound and sends events to Facebook CAPI outbound — with a correct event_id for deduplication. This removes manual script gluing and cuts conversion loss between the click and a delayed deposit.

FAQ

Why is an S2S postback better than the browser pixel?: It passes the conversion from the server and is not lost to blockers, ITP or session loss. For delayed gambling deposits it is decisive.
How do I avoid duplicate conversions?: Deduplicate by a single event_id: pixel and CAPI send one event with the same key, and Facebook merges them into one.
Should I send registration or deposit to Facebook?: Optimize for payers: map FTD to Purchase and registration to a separate event. Otherwise the algorithm brings cheap but non-paying traffic.
What is the click id and why does it matter?: A unique click identifier (subid/external_id). The postback uses it to tie the deposit to a specific visit, source and ad.
Is Keitaro required?: No — any S2S tracker works (RedTrack, Binom, etc.). Keitaro is popular, but the click id → postback → CAPI chain is the same.

Build your PWA in APEX in minutes

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

Get started free