Skip to the fixes
Built for founders and technical leads: a checklist you can start working through today.
FairShare is built by the team at Appreciation Engine, and over the past decade, we've built data infrastructure the right way: privacy first, by design. Getting privacy right isn’t just about staying out of trouble with regulators. It’s about building something players can actually trust.
These are the most common privacy gaps we’ve seen that undermine player trust - and what to do about them. If your game touches player emails, usernames, device IDs, or behavior, this article applies to you.
The Most Common Gap: SDKs Firing Before Consent
Here’s how it plays out:
Firebase is one of the most commonly used backend toolsets for Unity developers, which means many studios end up with Firebase Analytics in their stack. It collects device ID, IP address, session data, custom events as soon as the app initializes by default - with or without user consent.
A studio ships their game and two weeks later a player in Germany complains to their local regulator: “I played for 30 seconds and these people have my device fingerprint”. A GDPR complaint lands. The studio didn’t realize Firebase was collecting information before the consent screen ran. Their dev lead installed it, tested that events fired and shipped it. By the time the complaint landed, they were scrambling to figure out how to configure Firebase to wait. Studios using GameAnalytics, AppsFlyer, Sentry, Unity Analytics and other analytic tools face the same risk.
It’s already happened:
In 2023, Voodoo games was fined €3 million (nearly 3.5M USD) by the Commission Nationale de l’Informatique et des Libertés (CNIL), France’s data protection agency, for using Apple’s IDFV (Identifier for Vendors) without their users’ consent. Despite displaying Apple’s ATT (App Tracking Transparency) window asking for consent, Voodoo still read the IDFV associated with users before they could opt in or out. Since data was collected before consent was given, Voodoo was in violation of the French Data Protection Act and player privacy rights.
The fix:
Always configure your SDK to wait for a consent signal. The data must only be collected once consent is given, not before.
Gap #2: Deletion Workflows that Fall Apart
Here’s how it plays out:
A small studio gets an email: “I’m in California. Delete my data per CCPA.” They panic - they were so focused on the game itself that they didn’t have a defined workflow for dealing with player data requests. One employee deletes the user row from their database and replies that it’s done.
They deleted one row in Postgres, but they didn’t delete:
- The user's record in Firebase Analytics
- Their email in Mailchimp
- Their crash reports in Sentry
- Every log line containing their IP or session token
The user data was still there in violation of the CCPA.
It’s already happened:
Like the CCPA, the GDPR mandates a users’ Right to Erasure - users have the right to request their data is deleted. A 2026 report by the European Data Protection Board (EDPB) showed that while data controllers understand the Right to Erasure, they fail to enact it fully due to operational issues.
One of the biggest issues: no documented procedures. This led to subjective handling of requests, unclear scope of what needed to be deleted, and an inability to consistently fulfill player data rights.
The fix:
If you handle player data, ensure that you have a documented process for deletion requests so that you can fulfill requests fully and within the legislated timeline (one month for GDPR and 45 days for CCPA). At the very least, this process needs to cover:
- How to recognize a deletion request
- Who is responsible for processing it
- How to inventory all data so nothing is missed
- How each request is documented for compliance records.
Gap #3: Consents that seem air-tight but aren’t
Here’s how it plays out:
A game has a singular checkbox at signup: “I agree to the terms and privacy policy”. The box is pre-ticked and players can’t proceed without it. The studio thinks that players can just read the policy and it’s their choice whether to proceed or not.
Under the GDPR, CCPA and other regulations, that’s not consent - it’s a consent wall. Consent is not freely given if you block a user from accessing a game unless they consent to all data collection beyond what’s strictly necessary for game function.
It’s already happened:
In 2025, privacy advocacy group NOYB (None of Your Business) filed a formal GDPR complaint against Ubisoft for requiring players to stay connected to Ubisoft's servers to play single-player games with no online functionality. This allowed Ubisoft to silently send data to Google, Amazon, and other third parties. Players had no way to opt out of that data collection without losing access to games they'd paid for. Ubisoft had created a consent wall.
While the Ubisoft complaint is still unresolved, a similar case in 2023 involving WhatsApp Ireland resulted in the company being fined €5.5 million for forcing users to click “agree and continue” with no granular options.
The fix:
Consent needs to be freely given. That means disclosure of what is strictly needed for game function and granular toggles, by default off, for each type of data use:
- “I need this to play” (no toggle, just disclosure)
- “Send me emails”
- “Help us improve with analytics”
Gap #4: Data you’re keeping too long, in places you forgot about
How it plays out:
A studio has analytics set up. Their system is sending requests that look like this:
POST https://api.example.com/track?userId=12345&playerEmail=someone@gmail.com
The player's email is in the URL. Every proxy, load balancer, and CDN in the chain logs it. It lives in server logs and browser history. Nobody set a retention policy on those logs. Two years later, they're still there.
The same studio has a deletion process. It works - they tested it. But when they run a disaster recovery drill and restore a backup from six months ago, deleted player data comes back. An access request arrives the following month. The player's data is in the export. The studio can't explain why.
This is more common than you’d think. It’s what happens when data accumulates in places nobody thought to include in a retention policy.
It’s already happened:
In 2026, General Motors faced the largest CCPA settlement to date: $12.75 million for retaining location and driving data from OnStar long after it was needed, then selling it to data brokers. GM isn't a game studio, but the principle is identical: keep data longer than you need it and you're liable for what happens to it.
The pattern is widespread. In the 2026 EDPB report mentioned earlier, an overarching theme among the organizations surveyed was that they were unable to identify and find all the personal data included in data access and erasure requests. If you don’t know where the data is, you don’t know how long you’re keeping it.
The fix:
The most important thing is to map all the places your player data lives, not just your primary database. Some more tips:
- Never put personal data in URLs, use request bodies instead
- Set a log retention policy and auto-purge - 30 days is a common standard
- Include backups in your retention planning. Know what they contain and how long they're kept
Why this should matter to your studio
None of the studios in the examples above were being reckless. They were doing what they do best: building games.
But GDPR, CCPA, and other privacy legislation don't care about intent. They care about what you collect, whether you asked permission first, and whether you can actually delete it when someone asks. App stores are paying attention too. Apple and Google have both tightened their privacy requirements, and inadequate consent flows or broken age gates can result in rejection or removal. The studios that get complaints are the ones who didn't know the rules and found out the hard way - but the legal risk is only part of it.
Players notice.
People are more aware of their privacy rights than ever, and that awareness is accelerating as AI makes data collection feel more personal, more consequential, and harder to ignore. A pre-ticked analytics checkbox, a consent screen you can't say no to, a data breach you buried - these erode the trust that keeps players coming back and recommending your game to others.
Player loyalty is one of the hardest things to build and one of the easiest to lose. Studios that treat privacy as an afterthought are gambling with something that can't be bought back.
What privacy-ready studios have in common
Studios that stay compliant aren’t doing anything extraordinary. Here’s what they have in common:
They’ve done a privacy audit and instead of asking “Is this legal?” they ask “Where does our player data live, what have we asked permission for, and can we actually delete it when asked?”.
They’ve documented their data policies and procedures, including:
- What data they collect
- Where it lives
- Why they have it
- How long they keep it
- How they handle deletion and other data subject requests
They've wired consent to their SDKs. Nothing fires before the player explicitly opts in.
They've tested deletion. Picked a real player account and deleted it end-to-end. Database, backups, third-party tools. Confirmed it was gone.
They think about player data the same way they think about player experience - it matters from day one.
We built a privacy audit for studios like yours
We put together a technical guide for indie studios. It walks through the exact systems you should check: your SDKs, your database encryption, your logs, your backups, your consent flow, your deletion capability, age gating if kids play.
It includes a to-do list and self-audit prompts you can paste into Claude or ChatGPT. Describe your stack, get back a risk report of what's broken. Then a checklist of fixes sorted by priority. 18 pages written for founders and technical leads who want to know what matters and what doesn't.
Two ways to close the gap
Download the free technical audit to check your own stack today, or skip the guesswork and apply to be one of FairShare's first 25 Pioneer Partners.
