General guidance, not legal advice. Data protection rules differ by country and change often (UK rules on analytics consent changed in 2025–26). Check the current guidance from the UK Information Commissioner’s Office (ICO), or the regulator where your players are, before shipping, and take proper advice for a commercial release.

Summary

Telemetry (see telemetry) is the automatic collection of data about how people play: sessions, deaths, choices, purchases, performance. It drives game-analytics, but once data can be linked to an individual it becomes personal data, and data protection law applies. For most games that means UK GDPR (with the Data Protection Act 2018) for UK players, the EU GDPR for EU players, and separate rules (PECR in the UK, the ePrivacy Directive in the EU) for storing or reading identifiers on a player’s device. Designing telemetry responsibly is partly legal compliance and partly design ethics: players should understand what is collected and why, and the data should be used for them, not against them.


Key ideas

  • Player IDs are personal data. GDPR treats online identifiers (device IDs, account IDs, IP addresses) as personal data when they can be linked to a person. A “random” player ID tied to one device usually counts.
  • Lawful basis. Processing personal data needs a lawful basis. For analytics the usual candidates are consent or legitimate interests; the second needs a documented balancing test and still requires transparency and a way to object.
  • Device access is a separate rule. Storing or reading identifiers on a device (cookies, SDK identifiers) falls under PECR / ePrivacy, which generally requires consent unless an exemption applies. The UK’s Data (Use and Access) Act 2025 added a narrow exemption for collecting statistics about how a service is used in order to improve it, provided users get clear information and an easy way to opt out; it does not cover advertising or secondary uses. The change (section 112 and Schedule 12, which add a new Schedule A1 to PECR) has been in force since 5 February 2026 (SI 2026/82). Check the ICO’s current guidance for the exact conditions before relying on it.
  • Principles (GDPR Article 5). Lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation (delete what you no longer need); security; accountability.
  • Children. The ICO’s Age Appropriate Design Code (the “Children’s code”, in force from September 2020 with conformance expected from September 2021) applies to online services likely to be accessed by under-18s, which includes many games. It expects high-privacy settings by default, profiling and geolocation off by default, and no nudge techniques that push children to weaken their privacy. US games for under-13s also face COPPA.
  • Anonymised vs pseudonymised. Pseudonymised data (names replaced by IDs) is still personal data. Only data that can no longer be linked to a person by any reasonably likely means is anonymous. Aggregated counts (“1,198 players started Level 4”) are usually safe; event logs per player usually aren’t.

In practice

  1. Start from questions. List the design questions telemetry must answer (“where do players quit?”) and collect only the events that answer them. “Log everything” fails data minimisation.
  2. Write a plain-language notice. Say what you collect, why, how long you keep it and who you share it with.
  3. Design an honest consent prompt. Equal-weight Accept and Decline buttons, no pre-ticked boxes, no guilt-tripping copy, and withdrawal as easy as giving consent (GDPR Article 7(3)): put it in Settings. A consent screen with a big “OK” and a hidden “Manage” link is a dark pattern (see dark-patterns).
  4. Default to private for children. If under-18s are likely to play, follow the Children’s code: telemetry beyond what the service strictly needs should be off by default.
  5. Set retention and deletion. Decide how long raw events live, aggregate early, and support deletion requests.
  6. Unity Gaming Services Analytics. Since SDK 5, the Analytics SDK stays dormant until the game tells it to collect: older versions call AnalyticsService.Instance.StartDataCollection() after consent (and StopDataCollection() on withdrawal); Unity 6.2+ with Analytics SDK 6.1+ uses the end-user consent API instead, setting analytics intent to granted or revoked. Events recorded while collection is off are discarded. RequestDataDeletion() handles deletion requests. Check Unity’s current privacy documentation, as the API has changed between versions.
// Analytics SDK 5.x pattern (legacy in newer versions; check current docs)
public void OnConsentAnswered(bool granted)
{
    if (granted) AnalyticsService.Instance.StartDataCollection();
    else AnalyticsService.Instance.StopDataCollection();
}

Evidence

  • The course lecture series treats telemetry ethics as “collect less, explain more, use it for players”: telemetry linked to a player ID is usually personal data; you need a lawful basis and a clear privacy notice; data minimisation; extra duties for children under the ICO Children’s code; and a design-ethics test: would players be comfortable seeing what you collect and what you do with it? It also warns that predicting who will pay and targeting them is a dark pattern with better targeting, and that optimising a retention metric alone can reward compulsion over fun (course lecture series, see source-player-psychology-lectures).
  • In 2022 the US Federal Trade Commission’s settlement with Epic Games over Fortnite included a COPPA penalty for collecting children’s data and separate refunds over purchase dark patterns: an example of privacy and dark-pattern enforcement arriving together.

Implications

  • Privacy is a design constraint that shapes the analytics plan, so involve it in pre-production, not at launch.
  • Good telemetry design and good privacy practice mostly agree: fewer, purposeful events produce clearer dashboards.
  • Arguably the ethical line is less “what may we collect?” than “what will we do with it?”: the same churn prediction can trigger a helpful difficulty tweak or a manipulative offer.

Open questions

  • How should a game behave for players who decline: is it fair to design and balance a game from data that only consenting players provide?
  • Where is the line between helpful personalisation and profiling under the Children’s code?

game-analytics · telemetry · dark-patterns · legal-and-business-basics · overview-ethical-game-design · f2p-monetisation-design · player-lifecycle · player-modelling · playtesting · accessibility-and-localisation