Privacy Policy

Classperiment is a browser-based teaching application for running short classroom experiments. Students can join a classroom session with a session code, complete a task on their own device, review a local result page, and optionally share a pseudonymous summary with the instructor dashboard.

This privacy policy reflects the application's current implementation status. It is intentionally written to match the system as it works today, including browser-side storage, optional summary submission, and instructor live updates.

The controller for the processing described on this page is currently listed as Dr. Marian Sauter at the contact details shown above.

The fact that the service is hosted with netcup does not by itself determine who the controller is. Hosting concerns technical infrastructure; the controller is the person or entity deciding the purposes and means of the processing. The controller is therefore stated personally.

When this website is accessed, technically necessary connection data is processed. Depending on the web server, reverse proxy, and server configuration, this can include IP address, date and time of access, requested URL, browser and protocol information, referrer information, and server log data.

These data are processed in order to deliver the website, keep the service stable, and defend against misuse or attacks. Web server logs are rotated daily and deleted after 14 days; application logs are kept in the system journal, which is capped at 200 MB and overwrites the oldest entries (see section 14).

The operator also keeps an anonymous, aggregate usage statistic with one record per classroom session: counts (students who joined, started, and finished), the task, the app version, the instructor interface language, and a coarse country code. The country is derived from the network address at the moment a session is created or joined; the address itself is used only for this lookup and is neither stored nor logged. These records contain no session codes, no device identifiers, and no individual-level data, and are accessible only to the operator (legal basis: legitimate interest in understanding and reporting on the use of the service, Art. 6(1)(f) GDPR).

For usage analysis, the operator runs a self-hosted instance of the open-source software Umami on the same server (stats.classperiment.com). It records page views and a few technical events at phase boundaries (for example: consent given, practice completed, task completed, summary submitted, task started in the task catalogue, session created or started by an instructor, feedback sent, video started or played to the end on the pages for instructors). An event carries at most the task name, the feedback category, or the video name and the language. Recorded with each are the page path and page title without session codes or query parameters (only campaign tags such as utm_source from links in the operator's own announcements are kept), the referring page, the language, browser and device type, screen size, and the country derived from the IP address. Umami sets no cookies and stores nothing in the browser; visitors are counted with a hash of IP address and browser signature that changes daily, and the IP address itself is not stored. Browsers with the Do Not Track setting enabled are not counted. Analytics data never contain task results, answers to the optional questions, session codes, or names (legal basis: legitimate interest in understanding and reporting on the use of the service, Art. 6(1)(f) GDPR).

The pages for instructors (/teach and /tutorials) contain videos: a short overview and tutorials. The video files, preview images, captions and chapter markers are delivered by the operator's own server and played with the video player built into the browser; no third-party player and no external video platform is embedded, so no data are transmitted to third parties when a video is played. Retrieving these files involves the same connection data as any other request to this website (see the first two paragraphs of this section).

The application currently uses a technically necessary locale cookie named cognimize_locale to remember the selected language.

In addition, the application stores state locally in the browser. This local storage currently includes a pseudonymous client ID, the current session code, whether participation consent was confirmed, whether summary sharing is enabled, an optional self-chosen display pseudonym (kept on the device only, never transmitted), where given, the voluntary answers to the optional questions (kept on the device to prefill them in a later session), the current task configuration, local result data, and, where applicable, a queued summary payload for later retry if transmission fails.

For some tasks, the browser also keeps a marker per session that the task has already been started on this device. It serves only to recognise a repeated run, contains no answers (only the task, the session code and the session's current run, a test note for the instructor's test run, and the time it was set) and is removed together with the site data; markers older than seven days are deleted when a new marker is set. For the task “Judging statements”, whose statements should not be seen twice, the marker refers to the version of the statements instead of the session, also applies outside a classroom session and expires after one year.

For instructors, the browser additionally stores the per-session instructor key (required for session controls) and, after publishing, a publication management token (required to update or retract the published aggregate).

Students join a classroom session by entering or opening a six-character session code. When a session code is checked, the server processes the code and returns the current task configuration and session state if the session exists.

Once participation consent has been confirmed, the device reports the join to the server (session code and pseudonymous client ID), regardless of the summary-sharing setting; each device is counted once per session. If summary sharing is enabled, the start of the task is reported in the same way. The server uses these reports for the dashboard counters “joined” and “started” and keeps the client IDs for this purpose until the session is reset or removed (see section 14). For a task that runs in several versions (a random assignment to one version, or a balanced order of its material), the device asks the server for its version when the task starts, regardless of the summary-sharing setting; the server keeps the assigned version with the client ID for the same time, so the device keeps the same version after a reload. The join and start reports also carry the device class (laptop/desktop, smartphone, tablet or unknown), derived from the browser's description of the device; the server keeps it with the client ID for the same time, so the instructor can view the class results combined or by device class.

The service does not currently require students to create an account or provide a name or email address in order to participate.

The experimental task itself is currently executed primarily in the student's browser. Trial-level result data are stored locally on the device and are shown again on the local result page if the session is resumed on the same device.

The current implementation is therefore data-minimised, but not fully anonymous in the strict legal sense, because browser-side identifiers, connection data, and technical metadata are still involved.

After the task is completed, the application can submit a summary payload to the server for classroom aggregation. In the current implementation, this may include the session code, pseudonymous client ID, task name and version, a summary ID, summary metrics, quality indicators, user-agent information, viewport width and height, the device class and a timestamp.

For some tasks, the summary also contains the answer to a short question at the end of the task (for example, in which part of the screen the student thinks the target appeared most often, whether that was correct, and how sure the student was), display and input measures such as the drawn stimulus size, the screen refresh interval and whether the keyboard or the on-screen buttons were used, and whether the task had already been started or completed earlier on the device (counted only within the same browser tab, for example across a page reload).

The submitted summary is used to compute classroom aggregates and instructor-facing presenter views. Instructors holding the session's instructor key also see the summary values of individual submissions without names and can export them as a CSV file: one row per submission with a sequential pseudonym (P001, P002, …), timestamp, summary metrics, quality indicators and the device class, without client ID, user agent, viewport or demographic answers. The current system does not submit the full local trial dataset as part of this summary route.

If the instructor enabled the optional demographic questions for a session, the summary may additionally contain the participant's voluntary answers (age group, and whether the teaching language is the participant's first language). These questions can always be skipped, and the answers only ever leave the live session as anonymous group counts.

A session can have a completion link set by the instructor (for example for a paid online study). The result page then shows a button to an external site once the student's summary has been accepted by the server. Following the button takes the student to that site, which processes data under its own privacy policy. Classperiment appends nothing to the link and sends nothing about the student to that site; the browser is also instructed not to pass on the address of the result page (no referrer).

Instructors can explicitly publish a session's class-level aggregate to a public comparison page. A published entry contains the task name, country, institution name, an optional session label, the participant count, and aggregated class statistics. It never contains individual results, client IDs, or any other per-student data.

Publishing requires a minimum of 10 participating students per session, so that published aggregates cannot be traced back to individual participants; the participant count is always displayed alongside each published entry. Published entries are stored in a database on the server in Germany and remain publicly visible until the publishing instructor retracts them or the operator removes them.

If the instructor enabled the optional demographic questions, a published entry may additionally include anonymous group counts per age band and per language answer — never individual answers. The counts for a question are only included if at least 10 students actually answered it; “prefer not to say” does not count as an answer and is not published. An age group chosen by fewer than 3 students is merged with the neighbouring age group, and the language question is left out if one of its answers was chosen by fewer than 3 students. Below these thresholds the counts remain inside the live session and are never published.

The instructor dashboard displays session status, participant count, aggregated summary statistics, presentation plots, and diagnostic indicators. In the current implementation, live dashboard refreshes are delivered through a WebSocket connection.

For this purpose, the server processes session metadata and dashboard subscription data and pushes aggregate updates to connected instructor clients.

Class results on the dashboard, including the values of individual participants, are delivered only to a dashboard that holds the session's instructor key: the device that created the session, or one on which the backup code was entered. A device that only knows the session code receives the session status and the counters (joined, started, finished). Once the instructor has revealed the results, such a device additionally receives, for the “You and your class” view on the result page, the number of shared results and, from 5 scored results onwards, the class median and the distribution grouped into value ranges (count per range), but no individual values.

The application offers a voluntary feedback form, reachable from the page footer, the result page and the instructor dashboard, for reporting problems, suggesting improvements or leaving other comments. Nobody has to use it; participation in a classroom session does not depend on it.

When an entry is submitted, the server stores the chosen category (bug, idea, other), the entered text, the optional email address, the path of the page the form was opened from (session codes are replaced by a placeholder before submission and query parameters are not transmitted), the interface language, the app version, the browser (user agent), the size of the browser window and whether the device is a touch device. No IP address and no session code are stored with the entry. To limit misuse, the server counts submissions per client for 10 minutes using a hashed value that is held only in working memory and is neither stored nor logged.

The entries are used to improve the service and, if an email address was given, to answer the person who sent the feedback. The email address is requested only for this purpose and is not used for anything else.

Legal basis: legitimate interest in maintaining and improving the service, Art. 6(1)(f) GDPR. For the optional email address the legal basis is consent (Art. 6(1)(a) GDPR), which is given by entering the address and can be withdrawn at any time with effect for the future via the controller contact details above.

Entries are kept until the operator has processed them and deletes them, at most 24 months after submission. The operator can be notified of a new entry by a push notification (currently via the service ntfy.sh). That notification contains only the category of the entry — never the text and never the email address — so no personal data leave the server through this channel. The form sets no cookies and stores nothing in the browser.

To the extent technically necessary data are processed to provide and secure the website, processing is currently based on Art. 6(1)(f) GDPR or, where a public-institution context applies, potentially Art. 6(1)(e) GDPR.

Storage of technically necessary information on the end device or access to such information is currently intended to rely on the rules for necessary storage/access operations, in particular Section 25(2) No. 2 TDDDG, where applicable.

Where summary sharing is offered as an optional participant choice, the current draft assumes Art. 6(1)(a) GDPR as the legal basis for that optional transmission.

The sharing checkbox is currently presented pre-selected on the consent screen. It is visible directly on that screen and can be unticked with a single tap before continuing; the sharing setting can also be changed again later on the result screen. Participation consent itself is a separate checkbox that is never pre-selected and must always be actively ticked.

Whether a pre-selected sharing checkbox satisfies the consent requirements of Art. 6(1)(a) GDPR (see CJEU C-673/17, Planet49) is currently the subject of an external legal review. This section will be updated once that review is concluded.

Depending on the deployment setup, recipients can include the controller, technical administrators, hosting infrastructure involved in operating the service, and instructors viewing or exporting classroom aggregates and the pseudonymous summaries of their own session.

The service uses no advertising trackers and no external marketing analytics. Usage analytics run self-hosted on the operator's own server (see section 3), so no analytics data leave that server.

Local browser storage remains on the device until it is overwritten, discarded, or deleted by the user or browser settings.

Server-side data for live sessions (session metadata, the instructor key, the client IDs of devices that joined and started, and submitted summaries) is held in the server's working memory and periodically snapshotted to disk on the server so that sessions can survive a server restart. The snapshot contains the same data as the live session state and is subject to the same retention. Sessions are removed automatically: ended sessions approximately 12 hours after they were ended, sessions in the waiting room (never started, or reset and not started again) approximately 12 hours after creation, and running sessions that were never ended approximately 24 hours after their start. Instructors can also reset or delete a session earlier.

Published class aggregates (see section 8) are stored permanently. They are kept in a database on the server, contain no individual-level data, and are covered by daily backups. A retracted entry is no longer displayed or delivered; it stays in the database until the operator deletes it.

Feedback entries (see section 10) are deleted by the operator once they have been processed, at the latest 24 months after submission, and are part of the daily database backup until then.

Web server logs (IP address, time, requested URL, browser information) are rotated daily and deleted after 14 days. Application logs in the system journal are capped at 200 MB; older entries are overwritten automatically.

Usage analytics data (see section 3) are kept without a time limit. They are aggregated, contain no IP addresses and no identifiers, and are included in the daily database backup.

The application runs on netcup infrastructure in Germany. No deliberate transfer to third countries is part of the present application design. If external providers are added later, this section must be updated.

You have the rights provided by the GDPR, subject to the applicable legal conditions. These include the right of access, rectification, erasure, restriction of processing, objection, withdrawal of consent for future processing where consent is relied upon, data portability where applicable, and the right to lodge a complaint with a supervisory authority.

Because the service currently works largely with pseudonymous technical identifiers rather than directly named accounts, additional information may be required to match a request to a specific session or summary.

This privacy policy may be updated if the technical implementation, hosting setup, security architecture, or legal assessment changes. The version published on this page is the version that applies to the current website state.