This question comes up at the same point in almost every integration: a studio has decided rewarded video is worth an afternoon of work, then someone on the team asks whether serving it to players in Germany or France creates a legal problem. The short answer is no, as long as consent is handled properly — and most of the handling is not the publisher’s job. The parts that are, are listed below. This is a technical explanation of how consent flows through a web rewarded video ad, not legal advice; a data protection lawyer should sign off your final privacy policy.

Are rewarded video ads GDPR compliant?

Rewarded video ads are GDPR compliant when three conditions hold: consent for ad-related data processing is collected from the player before any personal data is read or written, that consent is encoded and passed to every vendor in the chain, and a refusal results in a genuinely non-personalised ad rather than a personalised one served anyway. Nothing about the rewarded format itself is non-compliant. GDPR does not regulate ad formats; it regulates the processing of personal data belonging to people in the EU and EEA, whoever is doing the processing and whatever the creative looks like. A rewarded video ad is an opt-in video placement a player chooses to start in exchange for an in-game benefit — a continue, a hint, extra currency, a revive. Because the player initiates it, rewarded video sits in a better position than most formats on the consent question: it is already an explicit, deliberate interaction rather than something that interrupts. That does not substitute for consent to data processing, but it does mean the format is not fighting the spirit of the regulation. If you are new to the mechanics of the format, our developer’s guide to rewarded video ads covers how the loop works before any of the consent layer is added. The practical risk for a web publisher is not the format. It is shipping a rewarded video SDK to European traffic with no consent management platform in front of it, or with one that collects a choice and then never transmits it downstream. That is where exposure comes from.

What GDPR actually regulates inside a rewarded video ad

GDPR regulates four things inside a rewarded video ad call, and it helps to separate them because they have different legal bases and different fixes.

• • Storing or reading information on the player’s device. Cookies, local storage, device identifiers. This is governed by the ePrivacy Directive as implemented in each member state, and it generally requires consent before the read or write happens — not after.

• • Using that information to select and personalise an ad. Profile building, audience segmentation, cross-site behavioural targeting. Under the IAB framework this is consent-based.

• • Measuring the ad. Impression counting, viewability, completion events, frequency capping. Some measurement purposes can run on legitimate interest depending on the vendor’s declared basis; some vendors declare consent for all of it.

• • Transmitting data to other parties. Every demand partner in a programmatic auction that receives the bid request is a separate controller or processor with its own disclosure obligations.

What GDPR does not regulate: the reward itself, the fact that the ad is video, the fact that it is skippable or not, or how long it runs. A 30-second rewarded video served without any personal data is no more a compliance event than a static house ad. That distinction matters, because it is what makes non-consented monetisation possible rather than a dead end.

What is TCF 2.3 and what does it do for rewarded ads?

The IAB Europe Transparency and Consent Framework (TCF) is the industry standard for recording a user’s consent choices and passing them, in a machine-readable form, to every advertising vendor that touches the request. TCF 2.3 is the current version of that framework. For rewarded video, TCF is what turns “the player clicked Accept” into something a demand partner three hops away can actually act on.

What the consent string carries

A TCF consent string (the TC string) encodes which processing purposes the user agreed to, which special features they allowed, which vendors are covered, and under which legal basis each vendor is operating. A certified consent management platform writes that string, exposes it through the standard __tcfapi interface on the page, and the ad tag reads it before making a request. If the string says no consent for personalised advertising, compliant vendors must not use personal data to select the creative.

Why the version number matters

Demand partners enforce the framework version they support. A publisher running an outdated or home-rolled consent layer will often find that buyers simply drop out of the auction rather than risk processing an unreadable signal — which looks like a fill rate problem but is really a compliance plumbing problem. Running the current TCF version is as much a revenue decision as a legal one. AppLixir covers this ground in depth for enterprise publishers in the TCF v2.3 guide.

How AppLixir handles consent for European players

AppLixir has TCF 2.3 and GDPR compliance built into the platform via Didomi, a certified consent management platform. For a web game studio, that means the consent prompt, the TC string generation, the vendor disclosure list and the signalling to downstream demand are handled by the integration rather than by the publisher’s engineering team. The sequence on a European player’s first session looks like this:

1. 1. The player loads the game. The consent layer resolves before any ad request is made.

1. 1. Didomi presents the consent notice with purposes and vendors disclosed, and records the player’s choice.

1. 1. A TC string is written and made available through the standard framework API.

1. 1. When the player clicks the rewarded video button, the ad request carries the consent signal to demand partners.

1. 1. The ad is served — personalised or contextual depending on the signal — and the reward callback fires on completion either way.

The important property of that sequence is step five. The reward is not conditional on the consent answer. A player who declines still watches a video and still gets their extra life. See how the AppLixir integration works for the request and callback flow in detail.

What the publisher still has to configure

A built-in consent management platform covers the hardest part of GDPR compliance for rewarded video, but it does not cover all of it. The following remain the publisher’s responsibility, and they are where most audit findings land.

• • Scope of the consent prompt. Decide whether the notice is shown only to EEA and UK traffic or globally. Geo-gating reduces friction for non-European players; a global prompt is simpler to reason about and often preferred by studios with mixed audiences.

• • Reward parity. Do not gate the reward behind acceptance. Consent that is the price of a game mechanic is not freely given, and conditioning the reward on it undermines the validity of every consent you collect.

• • Your privacy policy. It must name advertising as a processing activity, describe the purposes, point to the vendor list, and explain how a player withdraws consent. The CMP should link to it.

• • A visible way to change the answer. Withdrawal has to be as easy as giving consent. In practice that is a persistent “Privacy settings” entry in your options menu that reopens the notice.

• • Children’s data. If your game is directed at children, the age of digital consent ranges from 13 to 16 depending on the member state, and personalised advertising to under-age users should be off. This is a product decision, not a toggle the ad platform can make for you.

• • Not calling the SDK too early. If your game pre-initialises the ad unit on load, make sure that initialisation does not read or write device storage before the consent layer has resolved. This is the single most common technical mistake.

• • Data subject requests. You need a route for access, deletion and objection requests, and a named contact. Route ad-related requests to your ad partner.

Separately, server-side reward validation is worth building regardless of jurisdiction. Verifying completion on your server rather than trusting a client callback is an anti-fraud measure, not a privacy one, but it uses its own event data and should be covered in your policy. Our guide to preventing rewarded ad fraud and reward abuse covers the verification pattern.

What happens when a European player refuses consent?

A European player who refuses consent still sees rewarded video. The ad is selected contextually — based on the page, the game category and the general context, with no personal data and no cross-site identifier — and the reward callback fires exactly as it does for a consented player. Monetisation continues at a lower effective rate rather than dropping to zero.

Player state	Ad served	Data used for selection	Revenue effect
EEA/UK, consent granted	Personalised rewarded video	Consented identifiers and purposes, signalled via TC string	Full programmatic demand; AppLixir delivers $4+ CPM on web rewarded video platform-wide
EEA/UK, consent refused	Contextual rewarded video	Context only — no personal data, no cross-site identifiers	Lower CPM than consented traffic; reward loop and fill continue. [DATA NEEDED: AppLixir EEA consented vs non-consented CPM delta]
EEA/UK, no CMP deployed	Unpredictable	Undefined — no signal for vendors to read	Compliant buyers withhold bids; fill and CPM both suffer, plus regulatory exposure
Outside EEA/UK	Per that region’s applicable framework	As permitted locally	Unaffected by the European consent decision

The row that should worry a publisher is the third one. Running no consent layer does not mean you keep personalised revenue and take a legal risk; it usually means you lose revenue and take a legal risk, because buyers treat an absent signal as a reason to stay out of the auction. If you are modelling what European traffic is worth to you, read the revenue mechanics in how much rewarded video ads pay on the web alongside this page.

Why mobile ad network consent tooling does not transfer to the web

Unity Ads, AdMob, AppLovin and ironSource all have mature GDPR tooling. None of it helps a web game publisher, because none of those networks serve browser games. They are mobile SDK networks built for native iOS and Android applications; their consent flows are built on mobile platform primitives — app-level consent dialogs, mobile advertising identifiers, SDK initialisation inside a native runtime — and those primitives do not exist in a browser tab. This matters practically for studios shipping a Unity WebGL build or an HTML5 title. A team that ran rewarded video in a mobile app and assumed the same stack would carry over to the web version finds that neither the ad serving nor the consent layer comes with it. The browser needs a web consent management platform exposing __tcfapi on the page, and a demand source that bids on web inventory. Our breakdown of whether Unity Rewarded Ads and AdMob work on WebGL goes through what does and does not run in a browser. Distribution platforms are a different case. If your game is published on Poki, CrazyGames or a similar portal, that platform operates its own consent layer on its own domain for the traffic it owns, and it handles European players there. That is complementary to, not a substitute for, a consent layer on your own site. Most studios run both: portal distribution for reach, and their own domain with their own rewarded video and their own CMP for the traffic they control directly. The compliance obligations on your own domain are yours.

A pre-launch compliance checklist for EEA and UK traffic

Before serving rewarded video to European players, confirm the following. Most of it is a one-time setup rather than ongoing work.

• • A certified consent management platform is live and presents before any ad-related storage access. AppLixir publishers get this via Didomi on TCF 2.3.

• • The TC string is readable through the framework API when the rewarded video request fires — verify in a browser console, not by assumption.

• • Declining consent produces a contextual ad and a successful reward, tested end to end on a European IP or with geo simulation.

• • A privacy settings control exists in the game UI and reopens the consent notice.

• • The privacy policy names advertising processing, purposes, the vendor list and the withdrawal route.

• • Age handling is decided if the title is directed at or likely to attract children.

• • Reward delivery is verified server-side so that neither consent state can be exploited for duplicate rewards.

AppLixir’s minimum publisher threshold is 5,000 daily active users, and the platform serves 100M+ monthly impressions across web game and content inventory. For studios at or above that scale with meaningful European traffic, the consent layer is usually the reason to move from a patchwork of display tags to a single web rewarded video integration — one CMP, one vendor disclosure, one place where consent is reasoned about. You can see how the format compares against display inventory on the same page in rewarded ads for websites.

FAQ

Are rewarded video ads GDPR compliant for players in Europe?

Yes. Rewarded video ads are GDPR compliant for European players when consent for ad-related data processing is collected before any personal data is read or written, signalled to downstream vendors through the IAB Transparency and Consent Framework, and honoured when refused. The rewarded format carries no inherent compliance problem; the obligations attach to the data processing behind the ad request. AppLixir provides TCF 2.3 consent handling via Didomi as part of the platform.

What is TCF 2.3 consent for rewarded ads?

TCF 2.3 is the current version of the IAB Europe Transparency and Consent Framework, the industry standard for recording and transmitting user consent choices to advertising vendors. For rewarded ads, a certified consent management platform collects the player’s choice, encodes it as a TC string, and exposes it so that the ad request carries the consent state to every demand partner. Running the current framework version matters commercially as well as legally, because buyers withhold bids when they cannot read a valid signal.

Does refusing consent stop rewarded ad revenue in Europe?

No. A European player who refuses consent still receives a contextually targeted rewarded video and still earns the reward on completion. Effective CPM is lower than on consented traffic because personalised demand drops out of the auction, but fill and the reward loop both continue. Gating the reward behind acceptance is the wrong response — it risks invalidating the consent you do collect.

Do Unity Ads or AdMob handle GDPR consent for my browser game?

They do not, because Unity Ads, AdMob, AppLovin and ironSource do not serve browser games at all. Their consent tooling is built for native mobile SDKs and depends on mobile platform identifiers and app-level dialogs that have no browser equivalent. A web game needs a web consent management platform exposing the TCF API on the page, paired with a demand source that bids on web inventory — which is what AppLixir’s web rewarded video platform provides.