The short version
Client-side tracking — Meta Pixel, Google's gtag.js, the platform's javascript SDK — fires from the user's browser. It is intercepted by ad-blockers (40%+ in DACH), suppressed by ITP and ETP, fragmented across third-party cookie loss, and increasingly under-counted on iOS. Server-side tracking — CAPI on Meta, Enhanced Conversions on Google, S2S postbacks at your platform layer — fires from your own server, where none of those issues apply. It is not a redundancy. It is the primary signal in 2026, with client-side as the fallback.
What CAPI actually does
Meta's Conversions API is a server-to-server endpoint that lets you send events directly from your backend (or your CDP, or your tracking stack) into Meta's attribution system, bypassing the browser. The same conversion event — say, a deposit — is sent twice: once via Pixel from the browser, once via CAPI from your server. Meta deduplicates them on a shared event ID and uses whichever signal is richer.
The richer signal is almost always the server one. It can include hashed PII (email, phone, IP, user agent) that the browser cannot share post-ATT, plus the actual deposit amount, currency, and a trustworthy timestamp. Match quality — the metric that determines how confidently Meta can tie the event to a user it has shown your ad to — typically jumps from ~5/10 to ~9/10 when CAPI is properly implemented.
The practical consequence: the algorithm sees more of your real conversions, optimises against the right event, and CPA stops drifting up over time as iOS share grows in your market.
What postbacks do
"Postback" is the term used in performance media for an HTTP call from the buying surface (or a tracking platform like Voluum, RedTrack, BeMob) to your platform's backend whenever a click, registration, deposit, or revenue event fires. They are the connective tissue between the ad ecosystem and your operator BI.
Postbacks do three things at scale:
- Deterministic attribution. Each click carries a click ID. When the user converts, the platform fires a postback with that click ID. No probabilistic matching, no last-click guessing. Either it matched or it did not.
- Real-time hand-off to ad accounts. Most native, push, and pop networks rely on postbacks to optimize. Without them, you are running cold on those surfaces.
- BI feed. Postbacks let your data team join media spend and player LTV at the click level. That is where cohort-level CPA-to-LTV ratios come from.
If your operator is on a platform like SoftSwiss, Everymatrix, Slotegrator, or a custom stack, postbacks are configured at platform level and forwarded to whichever attribution system you run. Most platforms support 30+ postback parameters; we typically use 12 of them.
Why you need both, not one
CAPI and postbacks solve different problems. CAPI feeds the algorithm — it tells Meta and Google what a converting user looks like so they can find more. Postbacks feed your BI — they tell your platform which click drove which deposit so you can run honest unit economics.
Operators who run only CAPI have great Meta optimization but cannot reconcile spend to LTV. Operators who run only postbacks have honest reporting but feed Meta the same degraded client-side signal everyone else uses, and pay the algorithmic tax. Operators who scale run both.
The architecture we deploy
For our pilots, the typical stack looks like this:
- Browser — gtag.js + Meta Pixel + TikTok Pixel (client-side, fallback signal).
- Tag manager — sGTM in our cloud, hashing and dedup on event ID.
- Server-side gateway — sends to CAPI, Google Enhanced Conversions, TikTok Events API, and our internal event lake.
- Tracking platform — Voluum or RedTrack, click ID generation, postback orchestration.
- Operator platform — postback fired on registration, FTD, redeposits, withdrawals.
- BI layer — Looker / Metabase, joining all of the above on click ID and player ID.
This is what "the stack lives here" means when our Tallinn engineering office answers your tech-due-diligence call. We will not share code, but we will walk through the architecture in detail during discovery.
Common failure modes
Hashing inconsistency
The most common cause of low CAPI match quality is inconsistent hashing of email and phone. Lowercase, trim whitespace, normalize phone to E.164, then SHA-256. Operators who skip the normalisation step and just hash whatever the browser produces get match quality of 4–5; operators who normalize get 8–9.
Event ID drift
Pixel and CAPI must fire the same event_id for deduplication to work. If your sGTM and your client-side fire different IDs (because one uses GA4's session ID and the other uses your own UUID), Meta double-counts. CPA looks great. It is wrong.
Postback timing
If your platform fires the FTD postback before the deposit clears (e.g. on intent rather than on settlement), you will report deposits that get charged back. Tie the postback to the settled-deposit event, not the initial submission.
Click ID coverage
If your tracking platform's click ID is not appended to every ad URL across every channel, postbacks for the missing channels will not match and those events become orphaned. Check the URL builder weekly.
What "good" looks like
For an operator running €500K+/month with our stack, the targets are:
| Metric | Threshold | Why |
|---|---|---|
| CAPI match quality (Meta) | ≥ 8.5/10 | Algorithm optimises on real signal |
| Event dedup rate | > 95% | No double-counting between Pixel and CAPI |
| Postback coverage | 100% | No orphaned conversions |
| Click-to-FTD latency | < 5 sec | Most networks need real-time hand-off |
| BI reconciliation gap | < 3% | Spend matches platform within rounding |
Why most operators stop here
The reason a serious tracking stack is rare in iGaming, even at €500K+ spend, is that it sits across four teams that rarely speak: media, engineering, platform, BI. Nobody owns it end-to-end. The agency owns CAPI on the ad side, the platform vendor owns postbacks, the data team owns BI. The interfaces between them rot.
Our position is straightforward: tracking is one of the four pillars of scaling FTDs, and it has to be owned by one team that can move across all four boundaries. Until that is true, the stack stays brittle and CPA stays drifting.