Data Retention & Privacy
What the platform stores about learners and games, how long each kind of data is kept, how learners are identified in xAPI data, and how to exercise privacy rights. This page is the developer-facing summary; the binding documents are the Privacy Policy, the Data Processing Agreement and the sub-processor list.
Raw xAPI statements
Every statement your game sends is stored verbatim in the LRS (xapi_statements), and is immutable: a game can neither edit nor delete a stored statement. Each night the platform also rolls every statement up into a compact fact row — the table that powers teacher dashboards, Insights and your Analytics Readiness page.
Raw statements are kept indefinitely, or as agreed in an institutional agreement. By default edu.games does not delete learning records: every statement stays in the LRS for as long as the platform exists, and so does its fact row, so evidence behind an Insights chart never expires. An institution can agree a different retention period for its own students’ records.
What the rollup keeps
| statement_id, stored, occurred | the statement id and both timestamps |
| game_id, student_id, class_id, org_id | which game, which platform account (if the actor resolved to one), and the class and school membership at the time it was stored |
| registration | the play-session grouping id |
| verb_iri, verb_class, objective_iri, competency_id | what happened, to which objective, mapped to which competency |
| success, score_scaled, duration_seconds, confidence | the result fields the emission profile defines |
| decision_point, decision_choice, sequence_index, state | Choice- and Full-level context extensions |
Nothing free-form survives in the fact row — no names, no display strings, no arbitrary extensions. Dashboards and Insights read only the fact rows; the raw statement is consulted only when someone opens the evidence behind a chart point.
State and profile documents
The activities/state, activities/profile and agents/profile documents are mutable, scoped to your credential, and — for state — to the launch actor. They have no automatic expiry: they persist until your game overwrites or DELETEs them. Keep them to game state (progress, settings) and never store personal details in them. Sandbox sessions write under a separate sandbox credential and never mix with real learners’ data.
Game builds and uploads
- Live builds stay for as long as the game exists.
- Replaced browser zips are archived for 90 days after being superseded, then deleted by the nightly storage cleanup.
- Replaced desktop builds retire after a short grace window once a newer build is approved; a staged build rejected in review is deleted immediately.
- Uploads that never finalized are removed after 48 hours.
The mechanics are in Review & Game Lifecycle.
How learners are identified
Inside the edu.games player your game never sees a name or an email. The launch context carries an opaque platform actor — an xAPI account with homePage https://edu.games and an id that is the student’s internal profile id — plus a 2-hour launch token bound to that identity. The LRS stamps the token’s identity onto every statement it stores and discards any actor the client supplied, so a game cannot misattribute data even by mistake. Anonymous play uses an anon:-prefixed id that is new on every load; sandbox runs use fixed test personas on edugames.dev.
- Never put student names, emails or free text about a student in a statement, in
result.response, or in a state document. The Emission Profile makes this a hard rule; the Analytics Readiness inspector flags non-platform actors. - If you integrate from a server with Basic key/secret auth, identify learners with the
accountform and an opaque id of your own — notmbox. See the xAPI Overview. - Only the display name a client sends is kept, and only because it is cosmetic; leave it out.
Student personal data in games
The Content Policy prohibits collecting student personal data beyond what your declared xAPI integration requires. Concretely: no sign-up forms, no third-party analytics or tracking pixels, no persistent identifiers of your own — the game frame is sandboxed without storage for this reason — and no sending learner data anywhere but the launch-context endpoint. Games embedded in a school’s LMS via LTI receive synthetic accounts, so the same rule holds there.
Access, correction and deletion
Anyone can request access to, correction of, or deletion of their personal data, and opt out of marketing email at any time; edu.games may verify identity before actioning a request. Where a school or institution is the data controller — the usual case for classroom learning records — requests go to the institution, which directs edu.games under the DPA; where edu.games is the controller, contact privacy@edu.games. EU and UK users additionally hold rights of rectification, erasure, restriction, objection and portability, and may complain to their supervisory authority (the ICO in the UK, a national authority in the EU, the OAIC in Australia); California residents have the CCPA/CPRA rights described in the Privacy Policy. Diagnostic data sent to Sentry follows Sentry’s standard retention window.
- Privacy Policy — full retention and rights statements.
- Data Processing Agreement — for schools and institutions.
- Sub-processors — the services that handle data on our behalf.
- FAQ — the short answers.