After testing 150 gambling sites in the UK, the Observer found that 52 shared visitor data with Meta using the Meta Pixel before individuals had the opportunity to decline such tracking. These findings, publicized in February 2025, brought attention to numerous established brands. Months prior, the UK Information Commissioner’s Office (ICO) had already issued a warning to Sky Betting & Gaming for sharing data through advertising cookies before users could accept or reject them.
The Meta Pixel not only collects excessive data prior to consent but also fails to capture essential data later. Features like Safari’s cookie restrictions, users opting out of tracking, and the delay in crucial actions like first deposits—often occurring days after initial interaction—highlight why browser-based tracking proves inadequate in regulated gambling markets. A proper solution requires two distinct strategies: controlling consent to prevent premature pixel activation and relocating the conversion signal to the server to rectify browser data loss.
The tracking pixel is a liability within regulated sectors because its management is fundamentally limited. While operators can dictate when the pixel script loads, the ad platform ultimately controls what data it gathers and submits upon execution.
In 2019, engineers from Apple’s WebKit noted that many developers were unaware of tracking, as updates to external scripts often included it without their knowledge. In the realm of gambling, this situation is especially precarious as visitor profiles may include self-excluded individuals or those facing financial difficulties.
A single malfunctioning consent banner or an unanticipated script modification could reclassify a marketing action as a data protection violation. With both the gambling authority and the data protection office closely monitoring marketing practices in Great Britain, a single tracking tag could present dual compliance issues.
Conversely, many conversions remain untracked. Several factors contribute to this loss. Browsers limit how much data the pixel can retain. With Intelligent Tracking Prevention (ITP) 2.1, Safari restricts persistent cookies from JavaScript to a maximum of seven days. Furthermore, ITP 2.2 caps these cookies at one day for visitors arriving via links marked as trackers. This restriction affects the vast majority of iPhone users, as many browsers on iOS utilize WebKit.
Consent refusals or ad blockers also prevent the pixel from functioning; users opting out of marketing cookies never trigger the event. This is legally sound but creates data gaps for the bidding algorithm to learn from.
The gambling customer journey is often lengthy, involving registration, identity verification, and the first deposit over various sessions, which can sometimes span days—frequently leading to a mismatch between campaign reports and cashier records. Consequently, the deposit, which operators strive to optimize for, typically fails to align within the restricted one-day or seven-day cookie parameters.
This shortfall means that reports frequently underreport the most valuable conversions, causing the bidding algorithm to focus primarily on players who convert rapidly.
What occurs when tracking shifts to the server? In a server-side environment, the operator’s backend accurately logs conversions since it already recognizes when a player registers or deposits. This backend then dispatches structured events to the ad platform, sidestepping browser limitations altogether.
Meta has implemented the Conversions API (CAPI), which uses hashed customer identifiers for event matching. Their developer documentation emphasizes a “redundant setup,” where both the pixel and CAPI relay the same events, sharing a common event ID to eliminate duplicate counts. The pixel continues to monitor on-site behavior while the server records the conversions that the browser misses.
Programmatic buying adheres to a similar logic with a key distinction. When a player engages with an ad purchased via a demand-side platform (DSP), the DSP assigns a click ID. Following the conversion, the operator’s server sends a postback to the DSP that includes the click ID. The DSP uses this to associate the conversion with the initial impression and integrates it into the optimization process. The postback solely requires the click ID and event data, without needing the player’s personal information.
This shift enhances compliance, giving operators authority over what data is sent out: only events from consenting players, cross-checked against self-exclusion lists, and redacted of sensitive information.
Concerns about server-side tracking potentially bypassing consent are valid and merit direct consideration. Transitioning tracking from the browser to a server doesn’t alter legal requirements. Storing a click ID in a cookie remains subject to ePrivacy regulations in the UK, and sending player data to an ad platform still needs adherence to GDPR stipulations, requiring a legitimate justification.
Server-side tracking refines the enforcement of these regulations. A browser tag can fire based on consent tools working correctly, while a server event only dispatches if backend logic confirms it. Proper implementation can allow for transmitting less data than the pixel, while ensuring it is conveyed accurately. Nonetheless, this transformation does not inherently prevent the browser pixel from operating before consent is granted; that outcome continues to hinge on the proper loading of the consent tool.
Regulated operators should establish a system where their backend solely determines which events are transmitted and to whom. A streamlined event mapping for a regulated market would encompass:
– **Event: Registration**
– **Sent from:** Server
– **Condition before sending:** Marketing consent recorded
– **Sent to:** Ad platforms, DSP postback
– **Event: Identity verified**
– **Sent from:** Server
– **Condition before sending:** Marketing consent recorded; age and identity checks passed
– **Sent to:** DSP postback (optimization signal)
– **Event: First deposit**
– **Sent from:** Server
– **Condition before sending:** Marketing consent recorded; not on self-exclusion or cooling-off list
– **Sent to:** Ad platforms, DSP postback
– **Event: Deposit value**
– **Sent from:** Server
– **Condition before sending:** Value banded rather than exact, where policy requires
– **Sent to:** Ad platforms only if needed for value bidding
– **Event: Page views, on-site behavior**
– **Sent from:** Browser pixel
– **Condition before sending:** Fires only after consent
– **Sent to:** Ad platforms
Three practical checks ensure effectiveness: tracking click ID upon landing to associate it with the player record, employing a shared ID across both browser and server for accurate event counting, and conducting self-exclusion checks before any event is transmitted.
On the programmatic end, the DSP needs to support postbacks natively. The Epom DSP, for instance, offers inherent server-to-server postback integration, allowing operators and affiliates to close the attribution gap without additional development work on the DSP side. The discussed processes integrate seamlessly within the operator’s backend framework.
For operators in tightly monitored markets, remaining solely on pixel-based tracking entails significant drawbacks. It limits optimization on crucial conversions and amplifies compliance risks that stem from browser tags, which operators do not fully control. The Observer’s findings coupled with the warning issued to Sky Betting & Gaming emphasize the necessity for data management that is more robust in regulated environments. Server-side tracking upgrades the reliability and defensibility of conversion signals, ensuring utmost accuracy and compliant operations in the gambling landscape.
