In December 2022, Epic Games agreed to pay $520 million to settle two Federal Trade Commission cases over Fortnite. Of that, $275 million was a civil penalty for violating the Children's Online Privacy Protection Act, the largest penalty the FTC had ever obtained for breaking one of its rules. The other $245 million went to refunding players tricked by dark-pattern purchase flows. Two years later, in January 2025, the agency reached a $20 million settlement with the developer of Genshin Impact on related ground.

If you build or publish games, your consent duties don't live only inside the game client. They live on your marketing site, your web store, your account and login pages, your community forums, and any browser-playable build. This guide covers what a studio has to get right on the web side, where cookies and tracking scripts actually run.

Why games draw regulator attention

Two features of games raise the stakes above a typical website.

Audience age. A large share of players are children or teenagers, and COPPA (the Children's Online Privacy Protection Rule) applies to any online service "directed to children" under 13, or where you have actual knowledge you're collecting a child's data. The FTC finalized updates to that rule in 2025 that tighten how you obtain parental consent and how long you can keep a child's data. In the EU, GDPR Article 8 sets the digital-consent age somewhere between 13 and 16 depending on the member state, and the UK's Age Appropriate Design Code adds its own duties.
Money mechanics. Loot boxes, in-game currency, and one-tap purchase prompts sit right next to data collection. The Genshin settlement barred selling loot boxes to players under 16 without verifiable parental consent and called out misrepresented odds. Regulators read data practices and monetization together.

This isn't the same as gambling. If you run a real-money betting or casino product, read our iGaming consent guide instead. This one is about game studios and publishers.

Cookies on the web, SDKs in the app

Split the problem by surface, because the rules attach differently to each.

Marketing and store websites run browser cookies and tags: analytics, ad pixels, affiliate tracking, A/B testing. These need consent the same way any site does, opt-in in the EU and UK, opt-out with a Do Not Sell or Share path in the US states that grant one.
The game client (mobile or desktop) doesn't use cookies, but it loads advertising and analytics SDKs that collect device identifiers. Those carry the same consent duties through a different mechanism. Our mobile app consent guide covers ATT, the mobile TCF SDK, and Firebase Consent Mode.

The mistake studios make is treating the marketing site as low-risk because "it's just a landing page." That landing page is often where a child first arrives, and it's usually loaded with ad pixels the growth team bolted on for a campaign.

Age screening comes before tracking

If your game or site reaches a general audience but has a meaningful under-13 population, you need a neutral age screen before you set non-essential cookies or fire ad SDKs. "Neutral" means it doesn't nudge kids to lie about their age, so no pre-filled adult birth year, no "you must be 18" hint. For anyone who identifies as under 13 (or the local threshold), you switch off behavioral tracking and advertising until you have verifiable parental consent.

That means your consent tooling has to gate scripts by age as well as by region. A visitor under the age threshold gets analytics and ad tags blocked no matter what they click. Our age assurance and children's privacy guides go deeper on building that gate.

The tracking stack to watch

A typical game studio site carries more third-party code than the team realizes:

Ad and remarketing pixels (Meta, Google, TikTok) that build audiences from page visits.
Attribution and mobile-measurement tags that connect a web click to an app install.
Web and product analytics that record which trailers, characters, or store pages a visitor looks at.
Community and support widgets (Discord embeds, live chat, forums) that set their own cookies.
Creator and affiliate tracking for influencer campaigns.

Each of those either needs consent or needs to be off for younger players. You can't gate what you haven't found, so start with a scan, then keep scanning, because marketing teams add tags constantly.

How CookieBeam fits a game studio

CookieBeam handles the web consent and script-control layer. It doesn't run in-app SDK consent or your parental-verification workflow, but it covers the browser surfaces where most studios are exposed.

Pre-consent script blocking. Ad pixels, analytics, and attribution tags stay blocked until a visitor consents, so nothing fires on a page a child might land on before you've established a basis. See how script blocking works.
Condition-aware rules. Combine geo-targeted regional consent with your age gate, so under-threshold users get non-essential tracking withheld everywhere, EU visitors get opt-in, and US visitors get opt-out.
Continuous scanning. The scanner crawls your marketing, store, and account pages, flags new cookies and outbound connections, and catches the pixel a campaign added last week.
Per-purpose consent logs. Timestamped records of what each visitor agreed to, which is the evidence you want if the FTC or a data protection authority asks how you handled a child's data.

Checklist for game studios

Map every web surface: marketing site, store, account pages, forums, browser builds.
Scan each one for cookies, pixels, and SDKs, then classify what you find.
Add a neutral age screen before non-essential tracking on anything reaching kids.
Block ad and analytics tags for under-threshold users until you have verifiable parental consent.
Run EU opt-in and US opt-out from one configuration, and honor Global Privacy Control.
Handle in-app SDK consent separately from web cookies, since the mechanism differs.
Log consent and keep re-scanning as your growth stack changes.