Responsible Telemetry Use

Use game records to ask better instructional questions. Students can inspect their own supported Download Game Data CSV, including the general behavioral record available when that file is submitted. Explain the purpose and context of review before asking for a file.

Read interactions in context

activeResponseTimeMs is visible-document time, not verified attention. hiddenTimeMs is hidden-document time. unfocusedTimeMs may overlap hidden time; do not add them together.
tabSwitchCount records visibility transitions, not the destination or activity in another tab.
copyCount records a relevant copy action, not copied content. Selection behavior does not identify its purpose.
Rapid guessing is an assessment/behavioral signal, not proof of misconduct. An incomplete run can reflect interruption or data loss.

Do not create automated cheating scores, make single-field accusations, or infer intent without supporting evidence. Consider mode, response history, assistance, missing data and the student’s explanation. These measurements alone do not establish cognition or learning.

Ordinary collection supports operational, instructional, and product analytics: improving game and content quality, understanding aggregate usage, identifying commonly missed concepts, questions, and objectives, supporting future faculty dashboards, and evaluating aggregate gameplay and interaction patterns. It is not research by default. Separately designated research requires its own institutional/research decisions and dataset handling. For exact definitions, use the Telemetry Data Dictionary.

Know which build and copy you have

Public polished games, including Managerial Intelligence Directorate, Economic Realm, Macro Command System, and Micro Domains, remain local-only for telemetry for now. Supported gameplay records stay on the device unless deliberately downloaded and submitted; downloading a CSV does not transmit or submit it. Private or class-specific builds, including Composer-generated games, can transmit anonymous gameplay and interaction data only when the instructor/deployer explicitly enables collection. Collection is OFF by default. Names, email addresses, LMS account identifiers, university identifiers, and free-text responses are not intentionally included in application telemetry. The private control stops future transmission and cancels pending events; it does not delete accepted server records. See collection and opt-out boundaries.

A downloaded local CSV stays on the student/faculty device unless deliberately shared. Submission through your LMS or another system transfers custody to that recipient/system. An admin export creates another copy outside the telemetry database. Server deletion cannot remove arbitrary downloads, submitted copies or backups.

Optional telemetry on HTTPS hosts

You can choose to collect anonymous gameplay data when you create a game with the official Mastery Quests Composer. Collection is OFF by default. To send data, the game must be published on a supported HTTPS website. Permission to send data lasts 365 days for each generated game. Collection stops if that permission expires or is withdrawn, or if a player turns it off in their browser. Players can still play and download their game data. Data already received stays subject to the separate 730-day retention policy.

A game opened directly from a file on your computer can be played and can save a CSV, but it cannot send gameplay data to Mastery Quests. Publish the same file on a supported HTTPS website to enable collection while its permission is valid. Your LMS or network may still block data collection, so test the game the way students will open it. Anonymous records cannot confirm who played or reliably link the same player across different websites.

The National Engine uses an older data-collection setup. Check its own notice for details.

Handle files deliberately

Use the institution-approved storage and submission location; limit access to the people authorized for the stated purpose.
Avoid public links and unnecessary copies. Treat a browser/run identifier as linkable even when it is not a name.
Record where exports are held, who received them and the approved disposal decision. Dispose of each copy through the receiving system’s process; do not assume a server purge reaches it.
Ordinary administrative exports have a normal 730-day disposal horizon. Store administrative exports only in restricted owner-controlled storage; minimize copies and recipients. Keeping a dataset longer requires separate research-dataset designation with documented purpose, custodian, version, access, retention and disposal. No automatic permanent exemption exists; D1 purge cannot erase those files. This project policy is not a compliance approval.

Updated September 10, 2026.