When the Observer tested 150 UK gambling websites, 52 of them sent visitor data to Meta through the Meta Pixel before the visitor had a chance to accept or refuse tracking.
The findings were published in February 2025 and widely reported, naming several well-known brands. A few months earlier, the UK Information Commissioner’s Office (ICO) had reprimanded Sky Betting & Gaming for sharing visitors’ data through advertising cookies before they could accept or reject them.
The same pixel that collects too much before consent also collects too little after it. Safari caps its cookies, many players refuse tracking, and the conversion that matters most, a first deposit, often happens days after the click. This article covers why browser-based tracking fails in both directions in regulated gambling markets and why the two failures need different fixes: consent controls stop the pixel from firing too early, and moving the conversion signal to the server recovers what the browser misses.
Why is the browser pixel a liability in regulated markets?
Every acquisition team knows the pixel. Fewer think about how little of it they control. The operator decides when the script loads, but the ad platform’s code decides what it reads and sends once it runs.
Apple’s WebKit engineers said as much in 2019, when Safari started limiting tracking through link parameters: many developers had no idea the tracking was happening, because updates to third-party scripts had added it without their knowledge. On a gambling site the stakes are higher, because the visitor may be a self-excluded player or someone in financial trouble.
So one broken consent banner or one script update can turn a marketing tag into a data protection breach. In Great Britain, both the gambling regulator and the data protection authority watch marketing closely, so a single tag can create two enforcement problems.
Where do the missing conversions go?
The other half of the problem is loss. Three mechanisms drive it.
Browsers restrict what the pixel can store. Since ITP 2.1, Safari caps persistent cookies written by JavaScript at seven days. Since ITP 2.2, it caps them at one day when the visitor arrives through a link carrying a query string from a domain classified as a tracker. That is exactly how ad click IDs travel. Most browsers on iOS run on WebKit, so this applies to most iPhone users regardless of the browser they choose.
Consent and blocking remove the pixel entirely. A player who refuses marketing cookies, or runs an ad blocker, never fires the event. That is the correct outcome legally, and it still leaves a gap in the data the bidding algorithm learns from.
Gambling journeys are long. Registration, identity checks and the first deposit often happen in separate sessions, sometimes days apart, especially when verification is manual. Anyone who has compared a campaign report with the cashier’s records will recognize what follows: the deposit, the event operators optimize towards, is the one most likely to fall outside a one-day or seven-day cookie window.
The result: reports undercount the conversions worth the most, and the bidding algorithm learns mostly from players who convert quickly.
What changes when tracking moves server-side?
In server-side tracking, the operator’s own back end records the conversion, because it already knows when a player registered, passed verification or deposited. The operator’s server then sends a structured event to the ad platform. The browser is not involved in that step, so cookie caps and blockers don’t affect it.
Meta’s version is the Conversions API (CAPI). Events are matched using hashed customer identifiers. Meta’s developer documentation recommends a “redundant setup”: the pixel and CAPI send the same events, with a shared event ID so Meta counts each one once. The pixel isn’t replaced. It keeps capturing on-site behavior, while the server reports the conversions the browser misses.
Programmatic buying works on the same principle with a different key. When a player clicks an ad bought through a demand-side platform (DSP), the DSP assigns a click ID. When the conversion happens, the operator’s server fires a postback to the DSP carrying that ID. The DSP matches it to the original impression and feeds it into optimization. The postback needs only the click ID and the event, not the player’s name or contact details.
The compliance gain is control. The operator decides what leaves its systems: only events from players who consented, checked against self-exclusion lists, with anything sensitive removed first.
Isn’t server-side tracking just a way around consent?
It can be misused that way, and that objection deserves a direct answer. Moving a tag from the browser to a server doesn’t change the law. Storing a click ID in a cookie still falls under ePrivacy rules (PECR in the UK). Sending player data to an ad platform is still processing under the GDPR that needs a lawful basis.
What server-side changes is the ability to enforce those rules. A browser tag fires and then depends on the consent tool working correctly. A server event goes out only if the back end’s own logic allows it. Done properly, server-side tracking can send less data than a pixel does, and send it more accurately. It does not, on its own, stop a browser pixel from firing before consent. That still depends on the consent tool loading first.
How should a regulated operator set it up?
The operator’s back end becomes the single point that decides which events are sent and to whom. A minimal event map for a regulated market looks like this:
| Event | Sent from | Condition before sending | Sent to |
|---|---|---|---|
| Registration | Server | Marketing consent recorded | Ad platforms, DSP postback |
| Identity verified | Server | Marketing consent recorded; age and identity checks passed | DSP postback (optimization signal) |
| First deposit | Server | Marketing consent recorded; not on self-exclusion or cooling-off list | Ad platforms, DSP postback |
| Deposit value | Server | Value banded rather than exact, where policy requires | Ad platforms only if needed for value bidding |
| Page views, on-site behavior | Browser pixel | Fires only after consent | Ad platforms |
Three checks make this work in practice. The click ID has to be captured on landing and stored against the player record, so the deposit can be attributed days later. Events need a shared ID across browser and server so they are counted once. And the self-exclusion check has to run before any event leaves, not after.
On the programmatic side, the DSP has to accept postbacks natively. Epom DSP supports native server-to-server (S2S) postback integration, so operators and affiliates can close that attribution loop without a separate build on the DSP side. The work described above sits in the operator’s own back end.
For operators in tightly regulated markets, staying on pixel-only tracking has two costs. Optimization is weaker on the conversions that matter, and the compliance risk sits entirely in browser tags the operator does not fully control.
Where the conversion signal should live
The Observer findings and the Sky Betting & Gaming reprimand point to the same weakness: data that depends on browser tags the operator does not fully control. Server-side tracking does not replace consent controls or the pixel. It moves the events that matter most, registrations and first deposits, into a system the operator runs, where consent and self-exclusion checks happen before anything leaves. For a regulated operator, that signal is both more accurate and easier to defend.