wip

.mermaid-config.json

@@ -0,0 +1,5 @@
+{
+  "flowchart": {
+    "htmlLabels": false
+  }
+}

bin/render-mmd

@@ -0,0 +1,4 @@
+#!/usr/bin/env bash
+SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
+PROJ_ROOT="$SCRIPT_DIR/../"
+for x in "$PROJ_ROOT"/figures/*.mmd; do mmdc --pdfFit -c "$PROJ_ROOT/.mermaid-config.json" -i "$x" -o "$PROJ_ROOT/figures/$(basename "$x" .mmd).pdf"; done

figures/architecture.mmd

@@ -0,0 +1,48 @@
+flowchart LR
+  %% Clients (Frontends)
+  subgraph Clients["Clients (Frontends)"]
+    SC["Spiel-Client"]
+    DC["Dashboard-Client"]
+  end
+
+  %% Ingestion
+  subgraph Ingestion["Telemetry Ingestion"]
+    CG["Consent-Gate"]
+    COL["Collector<br/>(Auth + Schema-Validation)"]
+  end
+
+  %% Separation
+  subgraph Streams["Trennung der Datenströme"]
+    DID["Didaktik-Stream<br/>(Lern/Verhalten)"]
+    SYS["System-Stream<br/>(Fehler/Performance)"]
+  end
+
+  %% Storage
+  subgraph Storage["Persistenz"]
+    LRS["LRS / Event Store<br/>(Rohdaten)"]
+  end
+
+  %% Analytics
+  subgraph Analytics["Analytics"]
+    AGG["Aggregation<br/>(KPIs/Indikatoren)"]
+    ADB["Analytics DB<br/>(Serving Layer)"]
+  end
+
+  %% Governance
+  subgraph Gov["Governance"]
+    RB["RBAC/ABAC"]
+    RET["Retention/Löschung"]
+    AUD["Audit Logs"]
+  end
+
+  %% Flows
+  SC --> CG --> COL
+  COL --> DID --> LRS
+  COL --> SYS --> LRS
+  LRS --> AGG --> ADB --> DC
+
+  %% Governance as controls
+  RB -. "Zugriff" .-> LRS
+  RB -. "Zugriff" .-> ADB
+  RET -. "Regeln" .-> LRS
+  AUD <-. "Zugriffe/Exporte" .-> DC

figures/dataflow-and-governance.mmd

@@ -0,0 +1,51 @@
+flowchart LR
+  %% High-level dataflow for telemetry in serious games with governance controls
+
+  subgraph C["Client / Spiel"]
+    U["Lernende:r"]
+    CG["Consent-Gate<br/>(Opt-in/Policy-Version)"]
+    EL["Event Logger<br/>(Batching/Offline-Queue)"]
+    U --> CG --> EL
+  end
+
+  subgraph I["Ingestion"]
+    COL["Telemetry Collector<br/>(Auth, Schema-Validation, Rate-Limits)"]
+  end
+
+  subgraph G["Governance & Identitätstrennung"]
+    PID["Pseudonymisierungs-/Mapping-Service<br/>(getrennte Identitätsdomäne)"]
+    RB["RBAC/ABAC Policy Engine"]
+    AUD["Audit Logs<br/>(Zugriffe/Exporte)"]
+  end
+
+  subgraph S["Persistenz"]
+    LRS["LRS / Event Store<br/>(Rohdaten/Lernspur)"]
+  end
+
+  subgraph A["Analytics"]
+    ETL["ETL/ELT & Qualitätschecks<br/>(Dedupe, Missing Data, Drift)"]
+    AGG["Aggregation<br/>(KPIs, Zeitfenster, Kohorten)"]
+    ADB["Analytics DB<br/>(materialisierte Sichten)"]
+  end
+
+  subgraph R["Reporting"]
+    DASH["Dashboard/Reports<br/>(Filter, Drilldown, Exporte)"]
+    ST["Stakeholder<br/>(z. B. Lehrkraft/Trainer:in)"]
+  end
+
+  %% Main flow
+  EL --> COL
+  COL --> PID
+  PID --> LRS
+  LRS --> ETL --> AGG --> ADB --> DASH --> ST
+
+  %% Governance controls
+  RB -. "Zugriffskontrolle" .-> LRS
+  RB -. "Zugriffskontrolle" .-> ADB
+  RB -. "Zugriffskontrolle" .-> DASH
+  DASH --> AUD
+  LRS --> AUD
+  ADB --> AUD
+
+  %% Data separation hint
+  COL -. "Trennung: technisch vs. didaktisch" .- PID

figures/feedback-loop.mmd

@@ -0,0 +1,11 @@
+flowchart LR
+  T["Telemetrie<br/>(Events/Statements)"] --> A["Analytics<br/>(KPIs/Indikatoren)"]
+
+  A --> IG["In-Game Feedback<br/>(Hints/Erklärungen)"]
+  A --> DB["Dashboard<br/>(Übersicht/Drilldown)"]
+
+  DB --> INT["Intervention<br/>(z. B. Unterstützung/Anpassung)"]
+
+  %% Rückkopplung: Feedback/Intervention verändert Verhalten und erzeugt neue Telemetrie
+  IG -. "beeinflusst" .-> T
+  INT -. "beeinflusst" .-> T

figures/metrics-and-indicators.mmd

@@ -0,0 +1,17 @@
+flowchart LR
+  LZ["Lernziel / Kompetenz"]
+  IND["Beobachtbarer Indikator<br/>(Outcome + Prozess)"]
+  EVT["Event / Statement<br/>(z. B. xAPI oder Custom)"]
+  MET["Metrik / KPI<br/>(Formel + Zeitfenster)"]
+  OUT["Dashboard / Feedback / Intervention<br/>(Entscheidungsunterstützung)"]
+
+  LZ --> IND --> EVT --> MET --> OUT
+
+  %% Governance & Qualität als Querschnitt
+  GOV["Governance<br/>(Zweckbindung, Minimierung, RBAC, Retention)"]
+  QUAL["Datenqualität<br/>(Schema, Versionierung, Drift, Missing Data)"]
+
+  GOV -. "steuert" .-> EVT
+  GOV -. "steuert" .-> MET
+  QUAL -. "prüft" .-> EVT
+  QUAL -. "prüft" .-> MET

figures/xapi-schema.mmd

@@ -0,0 +1,17 @@
+flowchart TB
+  subgraph S["xAPI Statement"]
+    A["Actor<br/>(Agent/Group)"]
+    V["Verb<br/>(URI + display)"]
+    O["Object<br/>(Activity/Agent/StatementRef)"]
+    R["Result<br/>(success, score, duration, response*)"]
+    C["Context<br/>(activity context, group, platform, instructor*, contextActivities, registration, extensions)"]
+    T["Timestamp<br/>(event time)"]
+    X["Extensions<br/>(custom fields in allowed locations)"]
+  end
+
+  A --> V --> O
+  O --> R
+  O --> C
+  O --> T
+  R -. "optional" .-> X
+  C -. "optional" .-> X

flake.nix

@@ -49,6 +49,8 @@
                   upquote
                   tocloft
                   makecell
+                  appendix
+                  apa
                 ]))
           ];
         in {
@@ -96,6 +98,7 @@
               shellHook =
                 # bash
                 ''
+                  export PATH="$PATH:bin/"
                 '';
             };
         };

listings/aggregation-job.py

@@ -0,0 +1,27 @@
+import pandas as pd
+from datetime import datetime, timedelta
+
+def calculate_kpis(events_df, date_range):
+    """Berechnet KPIs aus Telemetrie-Events für einen bestimmten Zeitraum."""
+
+    # Filtere Events nach Zeitraum
+    mask = (events_df['timestamp'] >= date_range[0]) & \
+           (events_df['timestamp'] <= date_range[1])
+    period_events = events_df[mask]
+
+    # Berechne Erfolgsquote
+    total_attempts = len(period_events[period_events['verb'] == 'attempted'])
+    successful_attempts = len(period_events[period_events['verb'] == 'passed'])
+
+    success_rate = 0
+    if total_attempts > 0:
+        success_rate = successful_attempts / total_attempts * 100
+
+    # Berechne Durchschnittliche Bearbeitungszeit
+    avg_duration = period_events['duration'].mean()
+
+    return {
+        'success_rate': success_rate,
+        'avg_duration': avg_duration,
+        'total_attempts': total_attempts
+    }

listings/xapi-example.json

@@ -0,0 +1,52 @@
+[
+  {
+    "id": "8c3f8f3e-7b2d-4b0e-9a1a-2f1a0b6b9c01",
+    "actor": {
+      "objectType": "Agent",
+      "account": { "homePage": "https://example.edu", "name": "pseudonym-123" }
+    },
+    "verb": {
+      "id": "http://adlnet.gov/expapi/verbs/attempted",
+      "display": { "de-DE": "versuchte" }
+    },
+    "object": {
+      "id": "https://example.edu/activity/task-42",
+      "definition": { "name": { "de-DE": "Aufgabe 42" } }
+    },
+    "context": {
+      "platform": "serious-game-web",
+      "registration": "2d9a3f49-8a9d-4c54-8f5e-1f3b3b3d8a11",
+      "contextActivities": {
+        "parent": [{ "id": "https://example.edu/module/mod-3" }]
+      },
+      "extensions": {
+        "https://example.edu/xapi/ext/attempt_id": "a-00017",
+        "https://example.edu/xapi/ext/item_id": "task-42"
+      }
+    },
+    "timestamp": "2026-01-24T10:15:30Z"
+  },
+  {
+    "id": "b91e2d3a-4d3f-4f8f-8a0d-7d6c2e6f1b22",
+    "actor": {
+      "objectType": "Agent",
+      "account": { "homePage": "https://example.edu", "name": "pseudonym-123" }
+    },
+    "verb": {
+      "id": "http://adlnet.gov/expapi/verbs/passed",
+      "display": { "de-DE": "bestand" }
+    },
+    "object": { "id": "https://example.edu/activity/task-42" },
+    "result": {
+      "success": true,
+      "score": { "scaled": 0.9 },
+      "duration": "PT45S"
+    },
+    "context": {
+      "platform": "serious-game-web",
+      "registration": "2d9a3f49-8a9d-4c54-8f5e-1f3b3b3d8a11",
+      "extensions": { "https://example.edu/xapi/ext/attempt_id": "a-00017" }
+    },
+    "timestamp": "2026-01-24T10:16:15Z"
+  }
+]

main.tex

@@ -1,356 +1,441 @@
 \documentclass{seriousgames-seminar}
 
+% Literaturverzeichnis-Datei
+\addbibresource{references.bib}
+
 \begin{document}
 
 % Titelblatt
 \begin{titlepage}
     \centering
     \vspace*{2cm}
-    {\Huge\bfseries Serious Games mit Telemetrie, xAPI und Lehrer-Dashboard\par}
+    {\Huge\bfseries Telemetrie in Serious Games\par}
+    \vspace{0.5cm}
+    {\Large Möglichkeiten, Herausforderungen, Architektur- und Evaluationsansätze\par}
     \vspace{1.5cm}
-    {\Large Seminararbeit\par}
+    {\Large Seminararbeit zu Serious Games\par}
     \vspace{2cm}
-    {\Large Autor\par}
-    \vfill
-    {\large \today\par}
+    {\Large \textbf{Autor:} Linus Nagel\par}
+    \vspace{0.5cm}
+    {\Large \textbf{Kurs:} Verteilte Anwendungen\par}
+    \vspace{0.5cm}
+    {\Large \textbf{Dozent:} Prof. Dr. Johannes Ecke-Schüth\par}
+    \vspace{2cm}
+    {\large ITC-Dortmund\par}
 \end{titlepage}
 
 % Inhaltsverzeichnis
 \tableofcontents
+\listoffigures
+\listoftables
+\lstlistoflistings
 \newpage
 
 % Kapitel 1: Einleitung
 \section{Einleitung}
-\subsection{Motivation und Problemstellung}
-Serious Games werden zunehmend als Lernmedien eingesetzt, weil sie Motivation, Interaktivität und die Möglichkeit zur unmittelbaren Rückmeldung kombinieren. Gleichzeitig erzeugen sie eine große Menge an Interaktionsdaten, die über reine Endergebnisse (z. B. Punktzahlen) hinaus Einblicke in Lernprozesse geben können. Für den schulischen Kontext ist dies besonders relevant, da Lehrkräfte in heterogenen Lerngruppen häufig nicht kontinuierlich beobachten können, wie Lernende Aufgaben bearbeiten, an welchen Konzepten sie scheitern oder welche Strategien sie wählen.
+\label{sec:einleitung}
 
-Die zentrale Problemstellung lautet daher: Wie kann ein Serious Game Lernprozesse datengestützt sichtbar machen, ohne die Lernenden zu überfordern oder datenschutzrechtliche Grenzen zu überschreiten? Während klassische Lernplattformen häufig nur Aufgabenergebnisse erfassen, kann ein Serious Game Prozessdaten liefern (z. B. Bearbeitungszeiten, Fehlermuster, Nutzung von Hinweisen). Diese Daten sind jedoch nur dann wertvoll, wenn sie didaktisch interpretierbar, technisch zuverlässig und rechtlich zulässig erhoben werden.
+\subsection{Motivation und Problemstellung}
+\label{subsec:motivation}
+Serious Games werden zunehmend als Lern- und Trainingsmedien eingesetzt, weil sie Interaktivität, Motivation und unmittelbare Rückmeldung kombinieren. Gleichzeitig erzeugen sie eine hohe Dichte an Interaktions- und Prozessdaten, die – im Gegensatz zu reinen Endergebnissen – Hinweise auf Lernverläufe, Strategien und Unterstützungsbedarfe liefern können. Damit entsteht für Stakeholder (z. B. Lehrkräfte, Trainer:innen, Bildungsinstitutionen, Betreiber) die Möglichkeit, Lernprozesse evidenzbasiert zu verstehen und gezielt zu fördern.
+
+Telemetrie ist jedoch kein Selbstzweck: Lernkonstrukte sind nur indirekt messbar, Metriken können Fehlinterpretationen oder Fehlanreize erzeugen, und Datenschutzanforderungen begrenzen Umfang und Granularität der Datenerhebung. Die Kernfrage lautet daher, wie Telemetrie in Serious Games so gestaltet werden kann, dass sie didaktisch interpretierbar, technisch robust und datenschutzkonform ist.
 
 \subsection{Ziel der Arbeit und Forschungsfragen}
-Ziel dieser Arbeit ist es, das Thema Telemetrie, Learning Analytics und datenschutzkonformes Tracking in Serious Games nachvollziehbar darzustellen. Dazu wird ein Referenzkonzept für ein webbasiertes Serious Game (deploybar als Webapp und als mobile App via PWA/Wrapper) entwickelt, das Telemetrie systematisch nutzt, um Lehrkräfte über ein separates Dashboard zu unterstützen. Die Arbeit fokussiert insbesondere auf:
-
-\begin{itemize}
-    \item die Definition relevanter Telemetrie-Ereignisse zur Messung von Lernerfolg, Erfolgsquote/Fehlerrate und Verhalten,
-    \item die Umsetzung über xAPI und LRS als standardisierte Datenerfassungsschicht,
-    \item die Gestaltung eines Lehrer-Dashboards mit verständlichen, didaktisch sinnvollen Analysen,
-    \item die Berücksichtigung von DSGVO-Anforderungen durch Privacy-by-Design.
-\end{itemize}
+\label{subsec:ziel}
+Ziel dieser Arbeit ist es, Telemetrie in Serious Games systematisch aufzubereiten und als technisch-didaktisches Gestaltungsproblem zu analysieren. Dazu werden relevante Telemetrie-Daten zur Messung von Lernerfolg, Erfolgs-/Fehlerraten und Lernverhalten strukturiert, technische Umsetzungsoptionen (Tracking, Analytics, Dashboards, automatisierte Auswertung) beschrieben und Datenschutzanforderungen (DSGVO, Zweckbindung, Datenminimierung, Zugriffskontrolle) als Designkriterien integriert.
 
 Leitende Forschungsfragen:
 
 \begin{enumerate}
-    \item Welche Telemetrie-Daten sind für die Messung von Lernerfolg und Lernerhalten in einem Serious Game geeignet?
-    \item Wie lassen sich Tracking, Learning Analytics und adaptives Feedback technisch (xAPI/LRS) umsetzen?
-    \item Welche Dashboard-Ansichten unterstützen Lehrkräfte bei Diagnose und Intervention, ohne Fehlinterpretationen zu fördern?
-    \item Wie kann das System datenschutzkonform betrieben werden (Zweckbindung, Datenminimierung, Zugriffskontrollen)?
+    \item Welche Telemetrie-Daten eignen sich zur Messung von Lernerfolg, Erfolgs-/Fehlerraten und Lernverhalten in Serious Games?
+    \item Wie lassen sich Tracking, Analytik und Feedbackmechanismen technisch so umsetzen, dass sie skalierbar und wartbar sind?
+    \item Welche Formen der Ergebnisdarstellung (Dashboards/Reports) unterstützen Stakeholder bei Entscheidungen, ohne Fehlinterpretationen zu fördern?
+    \item Wie kann Telemetrie datenschutzkonform (DSGVO) gestaltet werden (Zweckbindung, Minimierung, Transparenz, Rechtekonzept)?
 \end{enumerate}
 
 \subsection{Einordnung im Kontext von Serious Games und Learning Analytics}
-Die Arbeit verortet sich an der Schnittstelle von Serious Games, Learning Analytics (LA) und Game Learning Analytics (GLA). Während LA in Lernplattformen häufig auf Aufgaben- und Nutzungsdaten basiert, erlaubt GLA die feinere Erfassung spieltypischer Prozessdaten (z. B. Entscheidungswege, Retry-Schleifen). Das Konzept zielt darauf ab, diese Daten für schulische Praxis nutzbar zu machen.
+\label{subsec:einordnung}
+Die Arbeit verortet sich an der Schnittstelle von Serious Games, Learning Analytics (LA) und Game Learning Analytics (GLA). LA adressiert die Erhebung und Auswertung von Lerndaten zur Verbesserung von Lernprozessen. GLA erweitert dies um spielspezifische Prozessdaten (z. B. Sequenzen von Entscheidungen, Explorationspfade, Retry-Schleifen), die zusätzliche Diagnostik- und Feedbackmöglichkeiten eröffnen.
+
+% Kapitel 2: Grundlagen und Begriffe
+\section{Grundlagen und Begriffe}
+\label{sec:grundlagen}
+
+\subsection{Serious Games, Learning Analytics und Game Learning Analytics}
+\label{subsec:serious_games}
+\textbf{Serious Games} sind Spiele, deren primäres Ziel ein extrinsischer Nutzen (z. B. Lernen, Training, Verhaltenstraining) ist \cite{Abt1970}. \textbf{Learning Analytics} bezeichnet die Erhebung, Messung, Analyse und Darstellung von Daten über Lernende und Lernkontexte, um Lernen zu verstehen und zu optimieren \cite{Siemens2011}. \textbf{Game Learning Analytics} erweitert dies um spielspezifische Prozess- und Interaktionsdaten \cite{SerranoLaguna2016}.
+
+\subsection{Telemetrie: Definition und Abgrenzung}
+\label{subsec:telemetrie}
+Telemetrie bezeichnet die instrumentierte Erfassung von Ereignissen und Zuständen während der Nutzung eines Systems. Im Serious-Game-Kontext lassen sich typischerweise drei Datenklassen unterscheiden:
 
-\subsection{Aufbau der Arbeit}
 \begin{itemize}
-    \item Kapitel 2: Begriffe und Grundlagen
-    \item Kapitel 3: Stand der Technik und verwandte Arbeiten
-    \item Kapitel 4: Anforderungen und Herausforderungen (Analyse des Kernproblems)
-    \item Kapitel 5: Lösungskonzept (Spielmechanik, Telemetrie, xAPI, Architektur, Dashboard)
-    \item Kapitel 6: Diskussion, Grenzen und Alternativen
-    \item Kapitel 7: Evaluation und Erfolgsmessung
-    \item Kapitel 8: Fazit und Ausblick
+    \item \textbf{Didaktische Daten (Lern-/Leistungsdaten):} z. B. Versuche, Ergebnisse, Bearbeitungsdauer, Fehlklassen, Hint-Nutzung.
+    \item \textbf{Verhaltensdaten (prozessual):} z. B. Abbruch, Wiederholungen, Navigationsmuster, Session-Struktur.
+    \item \textbf{Technische Daten (Betrieb/Qualität):} z. B. Fehler, Abstürze, Performance-Indikatoren (möglichst getrennt und minimiert).
 \end{itemize}
 
-% Kapitel 2: Grundlagen
-\section{Grundlagen und Begriffe}
-\subsection{Serious Games, Learning Analytics und Game Learning Analytics}
-Serious Games sind Spiele, deren primäres Ziel nicht Unterhaltung, sondern ein extrinsischer Nutzen ist, etwa Lernen oder Training. Für die schulische Nutzung ist besonders relevant, dass Serious Games Lernhandlungen in spielerische Interaktionen übersetzen.
-
-Learning Analytics bezeichnet die Erhebung, Messung, Analyse und Darstellung von Daten über Lernende und ihre Kontexte, um Lernen zu verstehen und zu optimieren. Game Learning Analytics erweitert dies um spielspezifische Prozessdaten, z. B. Entscheidungsstrategien oder explorative Pfade.
-
-\subsection{Telemetrie im Lernspiel}
-Telemetrie bezeichnet die instrumentierte Erfassung von Ereignissen und Zuständen während der Nutzung eines Systems. In Games umfasst Telemetrie typischerweise Event-Tracking (Session-Start, Level-Abschluss, Abbruch), Funnel-Analysen, Fehlerraten sowie Crash- und Error-Reporting. Für Lernspiele kommt hinzu, dass Telemetrie didaktische Konstrukte (Kompetenzen, Fehlkonzepte, Lernstrategien) abbilden muss.
-
 \subsection{xAPI und Learning Record Store (LRS)}
-Die Experience API (xAPI) ist ein Standard zur Erfassung von Lernerfahrungen in Form von Statements (Actor-Verb-Object) mit Kontext und Ergebnissen. Ein Learning Record Store speichert diese Statements und stellt sie über APIs für Auswertung bereit. xAPI bietet Interoperabilität und erlaubt, auch Lernaktivitäten außerhalb klassischer LMS zu erfassen.
+\label{subsec:xapi_lrs}
+Die \textbf{Experience API (xAPI)} ist ein Standard zur Erfassung von Lernerfahrungen in Form von Statements (Actor–Verb–Object) mit optionalen Feldern für Kontext und Resultate \cite{ADL2016}. Ein \textbf{Learning Record Store} speichert diese Statements und stellt sie über APIs für Auswertung bereit.
 
-\platzhalter{Abb. 2 - xAPI-Statement-Schema}{Inhalt: Actor, Verb, Object, Result (success, score, duration), Context (course, class, device), Timestamp.}
+\begin{figure}[htbp]
+    \centering
+    \includegraphics[width=0.9\textwidth]{figures/xapi-schema.pdf}
+    \caption{xAPI-Statement-Schema}
+    \label{fig:xapi_schema}
+\end{figure}
 
-\platzhalter{Listing 1 - Beispiel-xAPI-Statement}{Inhalt: JSON für „Schüler A solved Aufgabe X“, inklusive score, success, duration, attempt.}
+\begin{listing}[H]
+\centering
+\inputminted{json}{listings/xapi-example.json}
+\caption{Beispiel-xAPI-Statements (JSON)}
+\label{lst:xapi_example}
+\end{listing}
 
-\subsection{Datenschutzgrundlagen (DSGVO) im Schulkontext}
-Für Telemetrie in Schulen sind insbesondere Zweckbindung, Datenminimierung, Transparenz, Zugriffsbeschränkung und sichere Verarbeitung zentral. Einwilligung (bzw. geeignete Rechtsgrundlagen im Schulrecht), Pseudonymisierung und klare Rollenverteilung (Verantwortliche/Verarbeiter) müssen berücksichtigt werden. Privacy-by-Design fordert, Datenschutz in Architektur und Datenmodell zu integrieren, nicht nachträglich aufzusetzen.
+\subsection{Datenschutzgrundlagen (DSGVO) und Governance}
+\label{subsec:datenschutz}
+Telemetrie in Serious Games erfordert Privacy-by-Design: Zweckbindung, Datenminimierung, Transparenz, Zugriffsbeschränkung, sichere Verarbeitung, Aufbewahrung/Löschung sowie klare Rollen (Verantwortliche/Verarbeiter) \cite{EU2016}. Je nach Kontext sind Einwilligung oder andere Rechtsgrundlagen sowie ggf. eine Datenschutz-Folgenabschätzung zu prüfen.
 
 \subsection{Abgrenzung zu verwandten Ansätzen}
-Das hier vorgeschlagene System unterscheidet sich von klassischen E-Learning-Systemen durch (1) spielerische Interaktionsdichte, (2) Prozessdaten als primäre Datenquelle und (3) adaptive Feedbackschleifen. Es unterscheidet sich von Web-Analytics durch didaktische Zielsetzung (Kompetenzen statt Klickpfade).
+\label{subsec:abgrenzung}
+Im Unterschied zu allgemeiner Web-Analytics steht die didaktische Interpretierbarkeit im Vordergrund. Im Unterschied zu reinem E-Learning-Tracking kann Telemetrie in Serious Games detaillierte Prozessdaten liefern, die jedoch sorgfältig operationalisiert und validiert werden müssen.
 
-\platzhalter{Tab. 1 - Glossar}{Inhalt: Begriff, Definition, Relevanz im System (xAPI, LRS, KPI, Funnel, Kompetenzmodell, Hint, Mastery).}
+\subsection{Begriffe (Verweis)}
+\label{subsec:begriffe}
+Die in dieser Arbeit verwendeten zentralen Begriffe sind im Anhang~\ref{sec:glossar} (Glossar) zusammengefasst.
 
-% Kapitel 3: Stand der Technik
+% Kapitel 3: Stand der Technik / verwandte Arbeiten
 \section{Stand der Technik / verwandte Arbeiten}
+\label{sec:stand_der_technik}
+
 \subsection{Auswertemöglichkeiten in Serious Games}
-Moderne Serious Games nutzen interaktive Dashboards, Kompetenzdiagnose und Trendanalysen, um Lehrkräften Einsicht in Lernfortschritt und Unterstützungsbedarfe zu geben. Fortschrittliche Ansätze ergänzen dies durch Predictive Analytics, um frühzeitig Risiken zu erkennen und Interventionen zu ermöglichen. Zudem sind Feedbackmechanismen für Lernende (Echtzeit-Feedback, Fortschrittsanzeigen) und Analysen kooperativer Prozesse relevant.
+\label{subsec:auswertemöglichkeiten}
+Der Stand der Technik umfasst u. a. Dashboards für Stakeholder, Lernstands- und Kompetenzdiagnose aus Interaktionsdaten, Unterstützung personalisierter Förderung, (optional) prädiktive Verfahren zur Früherkennung von Risiken sowie Feedbackmechanismen für Lernende und Lehrende \cite{SerranoLaguna2012}.
 
-\subsection{Telemetrie als Engineering-Praxis in Games}
-In der Spieleentwicklung ist datengetriebenes Design etabliert: KPIs wie Retention und Session Length, Funnel-Analysen und Fehlertracking unterstützen Produkt- und Qualitätsentscheidungen. Für Lernspiele müssen diese Praktiken auf Lernziele übertragen werden, ohne pädagogische Validität zu verlieren.
+\subsection{Telemetrie als Engineering-Praxis}
+\label{subsec:engineering}
+In der Spieleentwicklung sind Event-Tracking, Funnel-Analysen, Fehler- und Crash-Reporting sowie experimentelles Vorgehen (z. B. A/B-Tests) etabliert. Für Serious Games müssen diese Praktiken auf Lernziele übertragen werden; die zentrale Herausforderung liegt in Validität, Interpretierbarkeit und Governance.
 
-\subsection{Vergleich ausgewählter Technologien}
-Für die Erfassung und Auswertung kommen unterschiedliche Pipelines in Frage: xAPI/LRS als standardisierte Lernspur, proprietäre Event-Systeme, Batch- oder Streaming-Analytik, sowie On-device-Aggregation zur Minimierung personenbezogener Daten. Das Konzept dieser Arbeit wählt xAPI als Kernstandard, ergänzt um eine Analytics-Schicht für aggregierte Metriken.
+\subsection{Vergleich ausgewählter Technologieansätze}
+\label{subsec:technologievergleich}
+Für Tracking und Auswertung kommen u. a. xAPI/LRS, proprietäre Eventmodelle, Batch- oder Streaming-Analytik sowie On-device-Aggregation in Betracht. Entscheidungen betreffen Interoperabilität, Tooling, Betriebskosten, Datenschutz und Flexibilität.
 
-\platzhalter{Tab. 2 - Technologievergleich}{Inhalt: xAPI/LRS vs. Custom Events; Kriterien: Interoperabilität, Aufwand, Datenschutz, Flexibilität, Tooling.}
+\begin{table}[htbp]
+\centering
+\caption{Technologievergleich: xAPI/LRS vs. Custom-Events (Top-5-Kriterien)}
+\label{tab:technologievergleich}
+\begin{tabularx}{\textwidth}{lXX}
+\toprule
+\textbf{Kriterium} & \textbf{xAPI + LRS} & \textbf{Custom-Events (proprietäres Eventmodell)} \\
+\midrule
+\textbf{Interoperabilität / Portabilität} & Hoch: standardisiertes Statement-Format, erleichtert Austausch/Integration. & Gering bis mittel: systemspezifisch; Integration benötigt Mapping und Migration. \\
+\textbf{Semantische Konsistenz (Governance)} & Gut, sofern ein \textbf{xAPI-Profil} (Verben/Objekte/Extensions) definiert und eingehalten wird. & Voll flexibel, aber Konsistenz muss vollständig selbst über Taxonomie, Schemas und Change-Policies gesichert werden. \\
+\textbf{Analyseflexibilität} & Mittel: Standardisierung hilft, komplexe Analysen erfordern jedoch meist zusätzliche Aggregations-/Analytics-Schicht. & Hoch: Events können exakt auf Analyse- und KPI-Bedarf zugeschnitten werden (inkl. domänenspezifischer Felder). \\
+\textbf{Implementierungs- und Wartungsaufwand} & Mittel: Profilierung, LRS-Auswahl/Betrieb und Integration erfordern initiale Konzeption; Änderungen laufen idealerweise über Profil-Versionen. & Niedrig bis mittel beim Start, aber Wartungsaufwand steigt ohne strikte Governance/Schema-Disziplin häufig stark (Event-Drift). \\
+\textbf{Datenschutz / DSGVO-Umsetzung} & Neutral bis gut: Governance möglich (Pseudonyme, Retention), aber Profil/Felder müssen strikt minimiert werden. & Neutral bis gut: Minimierung sehr direkt steuerbar; Risiko unstrukturierter Übererhebung, wenn Standards/Governance fehlen. \\
+\bottomrule
+\end{tabularx}
+\end{table}
 
-\platzhalter{Abb. 3 - Dashboard-Landschaft}{Inhalt: Übersicht (Klasse), Detail (Schüler), Warnindikatoren, Export/Report.}
+\textbf{Interpretation (kurz):}
+
+- \textbf{xAPI/LRS} ist vorteilhaft, wenn \textbf{Interoperabilität} und eine \textbf{standardisierte Lernspur} priorisiert werden.
+- \textbf{Custom-Events} sind vorteilhaft, wenn \textbf{maximale Analyseflexibilität} und \textbf{schnelle Anpassbarkeit} an sehr spezifische KPIs im Vordergrund stehen.
+
+\textbf{Empfehlung für Serious Games (pragmatisch):} Häufig ist ein \textbf{Hybrid} sinnvoll: xAPI/LRS als standardisierte Lernspur (Kernereignisse) plus ergänzende Custom-Events für technische Metriken oder hochspezifische Produkt-KPIs – jeweils mit klarer Zweckbindung, Minimierung und Versionierung.
 
 % Kapitel 4: Analyse des Kernproblems
 \section{Analyse des Kernproblems}
+\label{sec:analyse}
+
 \subsection{Messbarkeit von Lernen im Spielkontext}
-Lernen ist nicht direkt beobachtbar, sondern wird über Indikatoren approximiert. Eine Aufgabe korrekt zu lösen kann auf Verständnis hindeuten, aber auch auf Raten, externe Hilfe oder bloße Wiederholung. Daher müssen Metriken trianguliert werden: Erfolgsquote allein ist unzureichend; Prozessmerkmale (Zeit, Fehlmuster, Hint-Nutzung) erhöhen Interpretierbarkeit.
+\label{subsec:messbarkeit}
+Lernen ist latent und wird über Indikatoren approximiert. Ein korrektes Ergebnis kann auf Verständnis hindeuten, aber auch auf Raten oder externe Hilfe. Daher ist eine Triangulation aus Ergebnis- und Prozessindikatoren erforderlich. Zusätzlich müssen Indikatoren so definiert werden, dass sie mit Lernzielen verknüpft und in Dashboards verständlich kommuniziert werden können.
 
 \subsection{Anforderungen}
-Die wesentlichen Anforderungen sind:
+\label{subsec:anforderungen}
+Zentrale Anforderungen sind:
 
 \begin{itemize}
-    \item Messung des Lernerfolgs (Kompetenzzuwachs/Beherrschung),
-    \item Erfolgsquote vs. Fehlerrate (pro Aufgabe, Thema, Zeit),
-    \item Verhaltensanalysen (Strategien, Abbruch, Retry-Schleifen),
-    \item Stakeholder-Klärung: Für wen wird geloggt (Lehrkraft/Schule/Lernende/Entwicklung)?
-    \item Zweckbindung: Wozu wird geloggt (Diagnose, Intervention, Produktverbesserung)?
-    \item Detaillierung: Was wird wie granular geloggt?
-    \item Datenschutzkonformität: Minimierung, Pseudonymisierung, Zugriffskontrolle, Transparenz.
+    \item \textbf{Messung des Lernerfolgs:} nachvollziehbare Indikatoren und ggf. Kompetenzmodelle.
+    \item \textbf{Erfolgsquote vs. Fehlerrate:} zeitliche Verläufe, Segmentierung, Fehlklassen.
+    \item \textbf{Verhaltensanalysen:} Strategien, Abbruch, Wiederholungen, Hint-Abhängigkeit.
+    \item \textbf{Stakeholder und Zweck:} Für wen wird geloggt, und mit welchem Ziel?
+    \item \textbf{Granularität:} Was wird wie detailliert erfasst, was wird aggregiert?
+    \item \textbf{Datenschutz:} Zweckbindung, Minimierung, Pseudonymisierung, Zugriffskontrolle, Retention.
 \end{itemize}
 
 \subsection{Relevante Perspektiven}
-\textbf{Technisch:} Event-Design, robuste Datenerfassung (Offline/Online), Skalierbarkeit, Datenqualität.\\
-\textbf{UX:} Telemetrie darf Lernfluss nicht stören; Feedback muss erklärbar sein.\\
-\textbf{Didaktisch:} Kompetenzmodell, Fehlkonzepte, sinnvolle Schwellenwerte für Warnindikatoren.\\
-\textbf{Rechtlich:} DSGVO-Konformität, Einwilligung und Datenverarbeitung im Schulbetrieb.
+\label{subsec:perspektiven}
+\begin{itemize}
+    \item \textbf{Technisch:} Event-Design, Datenqualität, Offline-Resilienz, Versionierung, Skalierung.
+    \item \textbf{UX:} Nicht-invasives Tracking, verständliche Rückmeldungen.
+    \item \textbf{Didaktisch:} Operationalisierung von Lernzielen, Interpretationssicherheit.
+    \item \textbf{Rechtlich/Ethisch:} DSGVO-Konformität, Transparenz, Akzeptanz, Bias.
+\end{itemize}
 
 \subsection{Risiken und Fehlinterpretationen}
-Zentrale Risiken sind Metric Gaming (Optimierung auf Kennzahlen), Bias (z. B. Geräte-/Sprachunterschiede), sowie Fehlalarme im Dashboard. Daher sind Transparenz, Erklärbarkeit und konservative Schwellenwert-Logiken notwendig.
+\label{subsec:risiken}
+Risiken sind u. a. Goodhart-Effekte (Optimierung auf Kennzahlen), Bias (z. B. durch Geräte/Barrieren), Fehlalarme und Kontextverlust. Gegenmaßnahmen umfassen konservative Schwellenwerte, erklärbare Indikatoren, Unsicherheitskommunikation und regelmäßige Validierung.
 
-\platzhalter{Tab. 3 - Stakeholder-Ziel-Daten-Rechtsgrundlage}{Inhalt: Stakeholder (Lehrkraft, Schule, Lernende, Entwickler), Zweck, Datenkategorien, Zugriff, Aufbewahrung.}
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.9\textwidth]{figures/dataflow-and-governance.pdf}
+    \caption{Datenfluss und Governance-Punkte}
+    \label{fig:datenfluss_governance}
+\end{figure}
 
-\platzhalter{Tab. 4 - Anforderungskatalog}{Inhalt: Must/Should/Could; Messziel; Datenquelle; Datenschutzmaßnahme; Akzeptanzkriterium.}
-
-\platzhalter{Abb. 4 - Datenfluss und Rollen}{Inhalt: Client $\rightarrow$ Collector $\rightarrow$ LRS $\rightarrow$ Analytics $\rightarrow$ Dashboard; RBAC; Pseudonymisierungspunkt.}
-
-% Kapitel 5: Lösungsansätze
+% Kapitel 5: Lösungsansätze / Konzepte / Modelle
 \section{Lösungsansätze / Konzepte / Modelle}
-\subsection{Serious-Game-Referenzkonzept (lernorientiertes Microlearning-Spiel)}
-\subsubsection{Zielgruppe und Einsatzszenario}
-Die Zielgruppe sind Schüler:innen (Sekundarstufe), eingesetzt im Unterricht oder als begleitende Lernphase (Hausaufgaben/Übung). Lehrkräfte nutzen ein separates Dashboard, um Lernstände zu monitoren, gezielt zu intervenieren und Fortschritte zu dokumentieren.
+\label{sec:loesungsansaetze}
 
-\subsubsection{Lernmechanik und Content-Struktur}
-Das Spiel besteht aus Mikro-Lektionen (2-5 Minuten) mit interaktiven Visualisierungen, gefolgt von Aufgaben mit steigender Komplexität. Inhalte sind in Themenpfade gegliedert (z. B. Algebra, Mechanik, Algorithmen). Jede Aufgabe ist einem oder mehreren Kompetenzindikatoren zugeordnet.
+\subsection{Telemetrie als Designprinzip}
+\label{subsec:designprinzip}
+Telemetrie sollte als Bestandteil des didaktischen Designs verstanden werden: Lernziele werden in beobachtbare Indikatoren überführt, daraus Events/Statements abgeleitet, und diese werden zu Metriken aggregiert. Für eine hohe Interpretierbarkeit ist jedes Event mit einem Zweck und einer Analyse-/Dashboard-Verwendung zu verknüpfen.
 
-\textbf{Mechaniken:}
-\begin{itemize}
-    \item Concept Intro: Visualisierung/Simulation (z. B. Kräftevectoren, Graphen, Logikgatter).
-    \item Guided Practice: Schrittweise Aufgaben (Scaffolding), adaptive Hinweise.
-    \item Challenge Mode: Transferaufgaben, weniger Hinweise, höhere Belohnung.
-    \item Mastery Check: Periodische Tests zur Stabilisierung und Messung.
-\end{itemize}
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.9\textwidth]{figures/metrics-and-indicators.pdf}
+    \caption{Messmodell / Indikatoren-Mapping}
+    \label{fig:messmodell}
+\end{figure}
 
-\subsubsection{Motivations- und Progressionssystem}
-Progression erfolgt über Skilltree-Knoten und Mastery-Level. Belohnungen sind primär lernunterstützend (Freischalten neuer Visualisierungen, Aufgabenpfade), um Überfokussierung auf extrinsische Punkte zu vermeiden.
+\subsection{Telemetrie- und Analytics-Konzept}
+\label{subsec:analytics_konzept}
 
-\platzhalter{Abb.5 - Kompetenzmodell/Skilltree}{Inhalt: Themenknoten, Abhängigkeiten, Mastery-Level, Mapping zu Lehrplan.}
-
-\platzhalter{Tab.5 - Aufgaben-Typen $\rightarrow$ Kompetenzindikatoren}{Inhalt: Aufgabenklasse (Multiple Choice, Konstruktion, Simulation, Code-Puzzle), Kompetenz, Messsignale.}
-
-\platzhalter{Mock-up1 - Schüler-UI}{Inhalt: Visualisierung, Aufgabe, Hint-Button, Fortschritt, Reflexionsfrage.}
-
-\subsection{Telemetrie-und Analytics-Konzept (Kernbeitrag)}
 \subsubsection{Telemetrie-Ziele und Datenprinzipien}
-Telemetrie wird für drei Hauptziele eingesetzt:
+\label{subsubsec:telemetrie_ziele}
+Telemetrie adressiert typischerweise (1) Diagnose/Monitoring, (2) Feedback/Adaptation und (3) Betrieb/Qualität. Designprinzipien: Zweckbindung, Minimierung, Pseudonymisierung, Transparenz, Versionierung der Events und klare Retention-Regeln.
 
-\begin{enumerate}
-    \item Pädagogische Diagnose: Erkennen von Lernständen, Fehlkonzepten, Unterstützungsbedarfen.
-    \item Adaptives Feedback: Dynamische Anpassung von Hinweisen und Aufgaben.
-    \item System-/Qualitätssicherung: Stabilität, Performance, Fehlermeldungen (minimiert und getrennt von Lerndaten).
-\end{enumerate}
-
-\textbf{Designprinzipien:}
-\begin{itemize}
-    \item Zweckbindung: Keine „Alles loggen“-Strategie; jedes Event hat einen didaktischen oder technischen Zweck.
-    \item Datenminimierung: Nur erforderliche Attribute; Aggregation wo möglich.
-    \item Pseudonymisierung: Schüler-IDs als Pseudonyme; Zuordnung nur in schulischer Domäne.
-    \item Transparenz: Klare Information, welche Daten wozu erfasst werden.
-\end{itemize}
-
-\subsubsection{Event-und Statement-Taxonomie}
-Ereignisse werden in Kategorien gegliedert:
+\subsubsection{Event- und Statement-Taxonomie}
+\label{subsubsec:event_taxonomie}
+Empfohlen ist eine Taxonomie, die didaktische, verhaltensbezogene und technische Ereignisse trennt. Kernkategorien:
 
 \begin{itemize}
-    \item Learning Events: attempt\_started, attempt\_submitted, solved, failed, mastery\_achieved
-    \item Support Events: hint\_requested, hint\_consumed, solution\_viewed
-    \item Behavior Events: session\_start/end, idle, navigation, dropout
-    \item Collaboration Events (optional): peer\_help, group\_decision
-    \item System Events: error, crash, latency\_bucket
+    \item \textbf{Learning/Performance Events:} attempted, completed, passed/failed, mastery\_update
+    \item \textbf{Support Events:} hint\_requested/used, explanation\_opened
+    \item \textbf{Behavior Events:} session\_start/end, dropout, retry\_loop
+    \item \textbf{System Events:} error/crash/performance\_bucket (separat)
 \end{itemize}
 
-\subsubsection{xAPI-Profil und LRS-Integration}
-Für Interoperabilität werden Events als xAPI-Statements modelliert. Ein projektspezifisches xAPI-Profil definiert:
+\subsubsection{xAPI-Profil und LRS-Integration (optional/empfohlen)}
+\label{subsubsec:xapi_profil}
+Ein xAPI-Profil (Verben, Objekte, Context, Extensions) stellt Konsistenz sicher und erleichtert Integration. Statements werden clientseitig erzeugt, serverseitig validiert, im LRS gespeichert und für Analytics in Aggregationen überführt. Ein vollständiger Event-/Statement-Katalog kann bei Bedarf im \textbf{Anhang} als Referenzartefakt gepflegt werden.
+
+\begin{listing}[H]
+\centering
+\begin{minted}{python}
+function TRACK(event):
+  if not CONSENT_GRANTED(event.purpose): return
+  event.actor = PSEUDONYM_ID()
+  event.ts = NOW()
+  event = MINIMIZE_FIELDS(event)        # remove PII/free-text
+  QUEUE_PUSH(event)
+  if QUEUE_SIZE() >= BATCH_SIZE: FLUSH()
+
+function FLUSH():
+  if OFFLINE or QUEUE_EMPTY: return
+  batch = QUEUE_POP(BATCH_SIZE)
+  payload = { policyVersion: POLICY_VERSION(), events: batch }
+  ok = SEND(payload)
+  if not ok: QUEUE_PREPEND(batch)       # retry/backoff
+\end{minted}
+\caption{Client Logging (Pseudocode)}
+\label{lst:client_logging}
+\end{listing}
+
+\begin{listing}[H]
+\centering
+\begin{minted}{python}
+POST /telemetry/collect(payload):
+  auth = AUTHENTICATE(request)
+  RATE_LIMIT(auth.tenant, auth.client)
+  ASSERT_SCHEMA(payload)                # required fields, sizes, versions
+
+  for each event in payload.events:
+    ASSERT_PURPOSE_BOUND(event)
+    event.actor = HMAC_PSEUDONYM(auth.tenantSecret, event.actor)
+    event = STRIP_PII(event)
+    event.receivedAt = NOW()
+
+  STORE_RAW(payload.events)             # LRS or Event Store
+  ENQUEUE_AGGREGATION(payload.events)   # analytics pipeline
+  return 202 Accepted
+\end{minted}
+\caption{Server Collector + Validation (Pseudocode)}
+\label{lst:server_collector}
+\end{listing}
+
+\subsubsection{Analytics, Dashboards und Feedbackmechanismen}
+\label{subsubsec:dashboards_feedback}
+Aus Rohdaten werden Metriken abgeleitet:
 
 \begin{itemize}
-    \item standardisierte Verben (attempted, completed, passed, failed, experienced, requested),
-    \item Objekt-Typen (Task, Concept, Lesson, Simulation),
-    \item Kontextfelder (course, class, skillnode, difficulty),
-    \item Result-Felder (success, score, response, duration, attempts).
+    \item \textbf{Lernerfolg/Kompetenzindikatoren:} Fortschritt, Stabilität, Wiederauftreten von Fehlern.
+    \item \textbf{Erfolgsquote/Fehlerrate:} pro Einheit und Zeitraum, Fehlklassen.
+    \item \textbf{Verhaltensmetriken:} Abbruchrate, Session-Struktur, Hint-Abhängigkeit.
 \end{itemize}
 
-Statements werden clientseitig erzeugt, serverseitig validiert und in einem LRS gespeichert. Ergänzend werden Aggregationen in einer Analytics-Datenbank gehalten, um Dashboard-Queries performant zu ermöglichen.
+Feedbackmechanismen sollten erklärbar sein (zunächst regelbasiert) und Unsicherheit kommunizieren. Dashboards dienen als Entscheidungsunterstützung („Human-in-the-Loop“).
 
-\platzhalter{Tab. 6 - Event-/xAPI-Statement-Katalog}{Inhalt: Eventname; Trigger; xAPI-Verb; Attribute; Zweck; personenbezogener Bezug; Aufbewahrung; Aggregationsregel.}
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.9\textwidth]{figures/feedback-loop.pdf}
+    \caption{Feedback-Loop}
+    \label{fig:feedback_loop}
+\end{figure}
 
-\platzhalter{Listing 2 - Client Logging (TypeScript/Pseudocode)}{Inhalt: Logger-Interface, Event-Batching, Offline-Queue, Consent-Check.}
+\subsection{Referenzarchitektur und Governance}
+\label{subsec:referenzarchitektur}
 
-\platzhalter{Listing 3 - Server Collector + Validation}{Inhalt: Endpoint, Schema-Validation, Rate-Limits, Pseudonymisierung, Weiterleitung ans LRS.}
+\subsubsection{Gesamtarchitektur (Referenzmodell)}
+\label{subsubsec:gesamtarchitektur}
+Typische Bausteine sind: instrumentierter Client, Telemetry Ingestion (Collector), Persistenz (LRS/Event Store), Analytics (Aggregation/Modelle), Reporting (Dashboard/Exports), Governance (Consent, RBAC, Audit, Löschung).
 
-\subsubsection{Analytics, Dashboards und adaptive Feedbackmechanismen}
-Aus xAPI-Statements werden Metriken abgeleitet:
-
-\begin{itemize}
-    \item Lernerfolg: Mastery-Level pro Kompetenz; Pre-/Post-Delta (wenn vorhanden)
-    \item Erfolgsquote/Fehlerrate: pro Aufgabe/Thema/Zeitraum; Fehlertypen
-    \item Verhalten: Session-Länge, Abbruchraten, Retry-Schleifen, Hint-Abhängigkeit
-\end{itemize}
-
-Adaptives Feedback basiert auf einfachen, erklärbaren Regeln (Rule-based Adaptation):
-
-\begin{itemize}
-    \item Wenn Fehlerrate hoch und Hint-Nutzung niedrig $\rightarrow$ Hinweis anbieten.
-    \item Wenn Zeit pro Aufgabe stark steigt $\rightarrow$ alternative Erklärung/Visualisierung.
-    \item Wenn wiederholtes Scheitern im selben Fehlkonzept $\rightarrow$ Remedial-Lektion.
-\end{itemize}
-
-\platzhalter{Abb. 7 - Feedback-Loop}{Inhalt: Telemetrie $\rightarrow$ Analytics $\rightarrow$ Adaptionsentscheidung $\rightarrow$ Feedback im Spiel / Intervention durch Lehrkraft.}
-
-\subsection{Architektur und Implementierungsmodell (Web + Mobile)}
-\subsubsection{Gesamtarchitektur}
-Das System besteht aus:
-
-\begin{itemize}
-    \item Student App (Web/PWA): Lernspiel-Frontend
-    \item Teacher Dashboard (Web): Klassen- und Individualansichten
-    \item Backend Services: Auth/RBAC, Telemetry Collector, LRS, Analytics Service, Content Service
-\end{itemize}
-
-Die Webapp wird als Progressive Web App (PWA) realisiert, sodass sie auf mobilen Geräten installierbar ist. Für App-Store-Distribution kann optional ein Wrapper (z. B. Capacitor) genutzt werden.
-
-\platzhalter{Abb. 6 - Referenzarchitektur Telemetrie}{Inhalt: Client $\rightarrow$ Collector $\rightarrow$ LRS $\rightarrow$ ETL/Streaming $\rightarrow$ Analytics DB $\rightarrow$ Dashboard.}
-
-\platzhalter{Abb. 8 - Deployment/Komponenten-Diagramm}{Inhalt: Browser/PWA, API-Gateway, Collector, LRS, DBs, Analytics Jobs, Dashboard.}
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.9\textwidth]{figures/architecture.pdf}
+    \caption{Referenzarchitektur der Telemetrie}
+    \label{fig:referenzarchitektur}
+\end{figure}
 
 \subsubsection{Datenhaltung und Aggregation}
-Es werden zwei Datenehenen unterschieden:
-
-\begin{itemize}
-    \item Lernspur (xAPI Statements) im LRS: unveränderte, auditierbare Ereignislogik.
-    \item Aggregationen (Analytics DB): materialisierte Sichten für Dashboards (pro Tag, pro Kompetenz, pro Klasse).
-\end{itemize}
-
-Aggregationen werden regelmäßig berechnet (Batch) oder near-real-time aktualisiert (Streaming), abhängig vom gewünschten Feedback-Tempo.
+\label{subsubsec:datenhaltung}
+Zwei Ebenen: Rohdaten/Lernspur (auditierbar) und Aggregationen (dashboardtauglich, datenschutzfreundlicher). Aggregationen werden in definierten Intervallen und mit klaren Zeitfenstern berechnet.
 
 \subsubsection{Rollen- und Rechtekonzept (RBAC)}
-Lehrkräfte dürfen nur Daten der eigenen Klassen sehen; Administratoren nur Systemmetriken. Lernende erhalten nur eigene Fortschrittsansichten. Für Forschung/Produktverbesserung werden ausschließlich anonymisierte Aggregate verwendet.
+\label{subsubsec:rbac}
+Zugriffe sind rollen- und kontextgebunden. Individuelle Daten sind restriktiver als Aggregationen; Exportrechte sind begrenzt und auditierbar.
 
-\platzhalter{Tab. 7 - RBAC-Matrix}{Inhalt: Rolle (Schüler, Lehrkraft, Admin, Entwickler); Datenzugriff; Exportrechte; Audit.}
+\subsubsection{Datenschutz- und Security-Maßnahmen}
+\label{subsubsec:security}
+Consent-Management, Pseudonymisierung, Trennung von Identitätsdaten, TLS/At-Rest-Verschlüsselung, Retention-/Löschkonzept, Audit Logs, sowie technische und organisatorische Maßnahmen (TOM).
 
-\subsubsection{Datenschutz-und Security-Maßnahmen}
-\begin{itemize}
-    \item Consent-Management mit granularen Optionen (Lernanalyse vs. Systemdiagnose)
-    \item Pseudonymisierte IDs; getrennte Zuordnungstabelle in schulischer Domäne
-    \item Verschlüsselte Übertragung (TLS), at-rest Verschlüsselung
-    \item Datenaufbewahrung: Löschkonzepte, Zweckablauf, Klassenwechsel
-    \item Audit Logging für Dashboard-Zugriffe
-\end{itemize}
-
-% Kapitel 6: Diskussion
+% Kapitel 6: Diskussion und Bewertung
 \section{Diskussion und Bewertung}
+\label{sec:diskussion}
+
 \subsection{Vorteile}
-\begin{itemize}
-    \item Didaktische Transparenz: Lehrkräfte erhalten Einblicke in Lernprozesse statt nur Endstände.
-    \item Gezielte Intervention: Frühwarnindikatoren ermöglichen Unterstützung vor dem Scheitern.
-    \item Motivation und Selbststeuerung: Lernende profitieren von Feedback und Visualisierung des Fortschritts.
-    \item Interoperabilität: xAPI erleichtert Integration und zukünftigen Austausch.
-\end{itemize}
+\label{subsec:vorteile}
+Telemetrie ermöglicht Prozesssicht (nicht nur Endstände), frühzeitige Risikoerkennung, gezielte Interventionen sowie datenbasierte Weiterentwicklung von Lerninhalten und Feedback.
 
 \subsection{Nachteile und Grenzen}
-\begin{itemize}
-    \item Messvalidität: Prozessdaten sind Indikatoren, keine direkten Lernbeweise.
-    \item Komplexität: Telemetrie-Pipeline, Datenschutz und Dashboard erhöhen Implementierungsaufwand.
-    \item Fehlinterpretation: Ohne didaktische Schulung können Lehrkräfte Metriken überbewerten.
-\end{itemize}
+\label{subsec:nachteile}
+Grenzen liegen in Messvalidität, Komplexität von Pipeline und Governance, Interpretationsrisiken sowie Akzeptanz- und Fairnessfragen.
 
 \subsection{Alternativen}
-Alternativen umfassen Minimal-Tracking (nur Ergebnisse), proprietäre Analytics ohne xAPI, oder ausschließlich lokale Auswertung auf dem Gerät. Diese reduzieren Aufwand, verlieren jedoch Diagnostik- und Interoperabilitätsvorteile.
+\label{subsec:alternativen}
+Minimal-Tracking (nur Ergebnisse), rein lokale Auswertung, proprietäre Events ohne Standardisierung oder ausschließlich aggregierte Telemetrie. Diese reduzieren Aufwand, verlieren aber Diagnose- und Integrationsvorteile.
 
 \subsection{Kritische Reflexion}
-Eine datengetriebene Lernumgebung muss Überwachungsempfinden vermeiden. Daher sollten Transparenz, pädagogische Einbettung und Opt-out-Möglichkeiten vorgesehen werden. Zudem sind Erklärbarkeit und konservative Schwellenwerte für Warnindikatoren zentral.
+\label{subsec:reflexion}
+Telemetrie muss zweckgebunden, transparent und minimalinvasiv sein. Dashboards sollten Unsicherheit sichtbar machen und konservative Warnlogiken verwenden.
 
-\platzhalter{Tab. 8 - Pro/Contra-Matrix}{Inhalt: Kriterien (Validität, Aufwand, Datenschutz, Akzeptanz); Vergleich xAPI-Ansatz vs. Alternativen.}
-
-% Kapitel 7: Evaluation
+% Kapitel 7: Evaluation und Erfolgsmessung
 \section{Evaluation und Erfolgsmessung}
-\subsection{Evaluationsdesign}
-Zur Evaluation werden drei Ebenen unterschieden:
-
-\begin{enumerate}
-    \item Lernwirksamkeit: Pre-/Post-Tests oder Mastery-Checks; Vergleich zu Kontrollgruppe (optional).
-    \item Metrikvalidität: Korrelation von Telemetrie-Indikatoren mit externen Leistungskriterien.
-    \item Dashboard-Usability: Nutzertests mit Lehrkräften; Verständlichkeit und Handlungssicherheit.
-\end{enumerate}
-
-\subsection{Automatisierte Auswertung}
-Automatisierte Auswertung berechnet KPIs wie Erfolgsquote/Fehlerrate, Zeit pro Aufgabe, Hint-Abhängigkeit und Kompetenzstände. Zusätzlich können „Warnsignale“ definiert werden (z. B. persistentes Scheitern in einem Kompetenzknoten).
-
-\platzhalter{Tab. 9 - KPI-Definitionen}{Inhalt: KPI, Formel, Datengrundlage (Events), Interpretation, Schwellenwertvorschlag, Risiken.}
-
-\subsection{Validierung des Dashboards}
-Lehrkräfte erhalten prototypische Dashboards; Evaluation prüft:
+\label{sec:evaluation}
 
+\subsection{Evaluationsdesign (kompakt)}
+\label{subsec:evaluationsdesign}
 \begin{itemize}
-    \item ob die Visualisierungen verständlich sind,
-    \item ob Warnindikatoren angemessen (Precision/Recall) sind,
-    \item ob Interventionsempfehlungen als hilfreich und nicht bevormundend wahrgenommen werden.
+    \item \textbf{Outcome:} Pre-/Post-Messung oder kriteriumsorientierte Tests.
+    \item \textbf{Validität:} Abgleich zentraler Telemetrie-Indikatoren mit externen Kriterien (z. B. Test, Beobachtung).
+    \item \textbf{Dashboard-Qualität:} Verständlichkeit, Handlungsrelevanz, Fehlalarmrate.
+    \item \textbf{Akzeptanz/Datenschutz:} Transparenz, Vertrauen, Zweckbindung und Zugriffskontrolle.
 \end{itemize}
 
-\platzhalter{Abb. 9 - Beispiel-Auswertungsgrafiken}{Inhalt: Lernverlauf pro Klasse; Fehler-Hotspots; Funnel „Lesson → Practice → Mastery“.}
+\subsection{KPIs im Kontext dieser Arbeit}
+\label{subsec:kpis}
+\textbf{KPIs} sind hier \textbf{formal definierte Learning-/Process-Kennzahlen}, die aus Telemetrie-Events berechnet werden (Formel + Zeitfenster + Segment). Sie dienen der Verdichtung für Dashboards und Warnhinweise.
 
-% Kapitel 8: Fazit
+Beispiele (domänenneutral): \textbf{Erfolgsquote}, \textbf{Fehlerrate}, \textbf{Median-Zeit pro Versuch}, \textbf{Abbruchrate}, \textbf{Event-Completeness} (Datenqualität).
+
+Wichtig: KPIs müssen \textbf{dokumentiert und versioniert} werden (verwendete Events, Formel/Nenner, Zeitfenster, Umgang mit Missing Data/Ausreißern), damit Zeitreihen vergleichbar bleiben.
+
+\subsection{Warnindikatoren}
+\label{subsec:warnindikatoren}
+Warnindikatoren leiten sich aus KPIs ab (Trend/Schwelle/Anomalie) und werden anhand von \textbf{Precision/Recall} bzw. Fehlalarmkosten bewertet. Empfehlung: konservative Regeln und \textbf{Human-in-the-Loop} (Hinweis liefern, Entscheidung bleibt beim Menschen).
+
+% Kapitel 8: Fazit und Ausblick
 \section{Fazit und Ausblick}
-\subsection{Zusammenfassung}
-Die Arbeit hat ein Serious-Game-Referenzkonzept entwickelt, das Telemetrie und Learning Analytics als zentralen Mehrwert für Lehrkräfte nutzt. Kernbestandteile sind eine xAPI-basierte Ereigniserfassung, ein LRS als Lernspur-Speicher, eine Analytics-Schicht für performante Aggregationen und ein Lehrer-Dashboard zur Diagnose und Intervention. Datenschutzkonformität wird durch Zweckbindung, Datenminimierung, Pseudonymisierung und RBAC adressiert.
+\label{sec:fazit}
 
-\subsection{Beantwortung der Forschungsfragen}
-\begin{enumerate}
-    \item Geeignete Telemetrie kombiniert Ergebnis- und Prozessdaten (Versuche, Dauer, Fehlmuster, Hint-Nutzung).
-    \item Tracking und Analytik lassen sich interoperabel über xAPI/LRS und ergänzende Aggregationen umsetzen.
-    \item Dashboards müssen didaktisch interpretierbare Metriken und transparente Schwellenwerte bieten.
-    \item DSGVO-Konformität erfordert Privacy-by-Design, Consent-Management und strikte Zugriffskontrolle.
-\end{enumerate}
+\subsection{Zusammenfassung}
+\label{subsec:zusammenfassung}
+Die Arbeit zeigt Telemetrie als integrales Zusammenspiel aus Messkonzept, technischer Pipeline, Governance/Datenschutz und verständlicher Ergebnisdarstellung. Nutzen entsteht insbesondere durch Prozesssicht, Frühwarnindikatoren und gezielte Interventionen, sofern Metriken valide, interpretierbar und zweckgebunden sind.
 
 \subsection{Ausblick}
-Zukünftige Arbeiten können (a) erklärbare prädiktive Modelle integrieren, (b) differenzierte Kompetenzmodelle mit Fehlkonzept-Diagnostik ausbauen, (c) datenschutzfördernde Techniken wie Differential Privacy für Aggregate prüfen und (d) die mobile Nutzung mit Offline-first-Analytik weiterentwickeln.
+\label{subsec:ausblick}
+Weiterführend sind erklärbare prädiktive Modelle, datenschutzfördernde Aggregationsverfahren (z. B. Differential Privacy für Kohortenwerte), standardisierte Metrik-Kataloge und Feldstudien zur Wirksamkeit telemetriegestützter Interventionen.
 
 % Literaturverzeichnis
-\section*{Literaturverzeichnis}
-\begin{thebibliography}{9}
-\bibitem{lit1} Autor, A. (2023). \emph{Titel der Quelle}. Verlag.
-% Weitere Einträge hier einfügen
-\end{thebibliography}
+\printbibliography[title=Literaturverzeichnis]
 
 % Anhang
 \appendix
 \section{Vollständiger Event-/Statement-Katalog}
-\platzhalter{Anhang-Tabellen}{Vollständige Liste aller Events, Attribute, Datenklassifikation, Aufbewahrung.}
+\label{sec:event_katalog}
 
-\section{xAPI-Profil (Verben/Objekte/Context)}
-\platzhalter{Profil-JSON / Dokumentation}{Definierte Verben, Objekttypen, Extension-Felder.}
+\begin{table}[htbp]
+\centering
+\caption{Beispiel-Event-Katalog (Auszug)}
+\label{tab:event_katalog}
+\begin{tabularx}{\textwidth}{lllX}
+\toprule
+\textbf{Event-Name} & \textbf{Kategorie} & \textbf{xAPI-Verb} & \textbf{Beschreibung} \\
+\midrule
+attempt\_started & Learning & attempted & Start eines Versuchs zur Lösung einer Aufgabe \\
+attempt\_completed & Learning & completed & Abschluss eines Versuchs (erfolgreich oder fehlgeschlagen) \\
+hint\_requested & Support & requested & Anforderung eines Hinweises \\
+session\_started & Behavior & initialized & Beginn einer Spielsession \\
+error\_occurred & System & experienced & Auftreten eines technischen Fehlers \\
+\bottomrule
+\end{tabularx}
+\end{table}
 
 \section{Codeauszüge}
-\platzhalter{Listings}{Logger-Bibliothek, Collector-Service, Aggregation-Jobs.}
+\label{sec:code_auszuege}
 
-\section{Zusätzliche Diagramme und Mock-ups}
-\platzhalter{Mock-ups/Diagramme}{Schüler-UI Varianten, Dashboard Drilldowns, RBAC-Flows, Consent-Screens.}
+\begin{listing}[H]
+\centering
+\inputminted{python}{listings/aggregation-job.py}
+\caption{Beispiel-Aggregationsjob (Python)}
+\label{lst:aggregation_job}
+\end{listing}
+
+\section{Mock-ups}
+\label{sec:diagramme}
+
+\begin{figure}[htbp]
+    \centering
+    \includegraphics[width=0.9\textwidth]{figures/example-dashboard.png}
+    \caption{Dashboard-Mock-up für Lehrkräfte}
+    \label{fig:dashboard_mockup}
+\end{figure}
+
+\section{Glossar}
+\label{sec:glossar}
+
+\begin{table}[htbp]
+\centering
+\caption{Glossar zentraler Begriffe}
+\label{tab:glossar}
+\begin{tabularx}{\textwidth}{lX}
+\toprule
+\textbf{Begriff} & \textbf{Definition} \\
+\midrule
+\textbf{Telemetrie} & Instrumentierte Erfassung von Ereignissen/Zuständen während der Nutzung eines Systems. \\
+\textbf{Learning Analytics (LA)} & Analyse von Lerndaten zur Optimierung von Lernprozessen und -umgebungen. \\
+\textbf{Game Learning Analytics (GLA)} & LA erweitert um spielspezifische Prozessdaten (Entscheidungswege, Sequenzen). \\
+\textbf{xAPI (Experience API)} & Standard für Lern-Statements (Actor–Verb–Object + Context/Result). \\
+\textbf{LRS (Learning Record Store)} & Speichersystem für xAPI-Statements mit API-Zugriff. \\
+\textbf{Dashboard} & Visualisierte Darstellung relevanter Metriken mit Filtern/Drilldowns. \\
+\textbf{RBAC (Role-Based Access Control)} & Zugriffskontrolle anhand von Rollen und Berechtigungen. \\
+\textbf{DSGVO} & Datenschutz-Grundverordnung der Europäischen Union. \\
+\bottomrule
+\end{tabularx}
+\end{table}
 
 \end{document}

seriousgames-seminar.cls

@@ -6,18 +6,22 @@
 
 % Pakete
 \RequirePackage[ngerman]{babel}
-\RequirePackage{fontspec}  % Für benutzerdefinierte Schriftarten
+\RequirePackage{fontspec}
 \RequirePackage{geometry}
 \RequirePackage{fancyhdr}
 \RequirePackage{titlesec}
 \RequirePackage{graphicx}
 \RequirePackage{xcolor}
+\RequirePackage{minted}
 \RequirePackage{listings}
 \RequirePackage{hyperref}
 \RequirePackage{amsmath}
 \RequirePackage{booktabs}
 \RequirePackage{tabularx}
 \RequirePackage{enumitem}
+\RequirePackage{makecell}
+\RequirePackage{appendix}
+\RequirePackage[backend=biber]{biblatex}
 
 % Schriftarten einstellen (nur mit LuaLaTeX oder XeLaTeX kompilieren!)
 \setmainfont{IBM Plex Serif}
@@ -25,7 +29,7 @@
 \setmonofont{Cartograph CF Nerd Font}
 
 % Seitenränder
-\geometry{left=3cm, right=3cm, top=2.5cm, bottom=2.5cm}
+\geometry{left=2cm, right=2cm, top=2cm, bottom=2cm}
 
 % Kopf- und Fußzeile
 \pagestyle{fancy}
@@ -42,17 +46,52 @@
 \titleformat{\subsubsection}
   {\normalfont\normalsize\bfseries}{\thesubsubsection}{1em}{}
 
-% Listing-Formatierung
-\lstset{
-  basicstyle=\ttfamily\small,
+% Minted-Einstellungen
+\setminted{
+    fontsize=\small,
     breaklines=true,
     frame=single,
     numbers=left,
-  numberstyle=\tiny,
-  backgroundcolor=\color{gray!10},
-  captionpos=b
+    numbersep=5pt,
+    baselinestretch=1.2,
+    bgcolor=gray!10
 }
 
+\setminted[json]{
+    fontsize=\small
+}
+
+\setminted[python]{
+    fontsize=\small
+}
+
+% Listing-Formatierung
+\definecolor{codegreen}{rgb}{0,0.6,0}
+\definecolor{codegray}{rgb}{0.5,0.5,0.5}
+\definecolor{codepurple}{rgb}{0.58,0,0.82}
+\definecolor{backcolour}{rgb}{0.95,0.95,0.92}
+
+\lstdefinestyle{mystyle}{
+    backgroundcolor=\color{backcolour},
+    commentstyle=\color{codegreen},
+    keywordstyle=\color{magenta},
+    numberstyle=\tiny\color{codegray},
+    stringstyle=\color{codepurple},
+    basicstyle=\ttfamily\footnotesize,
+    breakatwhitespace=false,
+    breaklines=true,
+    captionpos=b,
+    keepspaces=true,
+    numbers=left,
+    numbersep=5pt,
+    showspaces=false,
+    showstringspaces=false,
+    showtabs=false,
+    tabsize=2
+}
+
+\lstset{style=mystyle}
+
 % Platzhalter für Abbildungen und Tabellen
 \newcommand{\platzhalter}[2]{
   \begin{center}
@@ -64,17 +103,14 @@
   \end{center}
 }
 
-% Literaturverzeichnis Stil
-\bibliographystyle{plain}
-
 % Hyperlink-Einstellungen
 \hypersetup{
     colorlinks=true,
     linkcolor=blue,
     filecolor=magenta,
     urlcolor=cyan,
-    pdftitle={Seminararbeit - Serious Game Mit Telemetrie},
-    pdfauthor={Autor},
-    pdfsubject={Serious Games, Learning Analytics},
-    pdfkeywords={Serious Games, Telemetrie, xAPI, Learning Analytics}
+    pdftitle={Telemetrie in Serious Games: Möglichkeiten, Herausforderungen, Architektur- und Evaluationsansätze},
+    pdfauthor={Max Mustermann},
+    pdfsubject={Serious Games, Telemetrie, Learning Analytics},
+    pdfkeywords={Serious Games, Telemetrie, xAPI, Learning Analytics, Datenschutz, Dashboard}
 }