itc.verteilte-anwendungen/main.tex

\documentclass{seriousgames-seminar}

\begin{document}

% Titelblatt
\begin{titlepage}
    \centering
    \vspace*{2cm}
    {\Huge\bfseries Serious Games mit Telemetrie, xAPI und Lehrer-Dashboard\par}
    \vspace{1.5cm}
    {\Large Seminararbeit\par}
    \vspace{2cm}
    {\Large Autor\par}
    \vfill
    {\large \today\par}
\end{titlepage}

% Inhaltsverzeichnis
\tableofcontents
\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.

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{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}

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)?
\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.

\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
\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.

\platzhalter{Abb. 2 - xAPI-Statement-Schema}{Inhalt: Actor, Verb, Object, Result (success, score, duration), Context (course, class, device), Timestamp.}

\platzhalter{Listing 1 - Beispiel-xAPI-Statement}{Inhalt: JSON für „Schüler A solved Aufgabe X“, inklusive score, success, duration, attempt.}

\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{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).

\platzhalter{Tab. 1 - Glossar}{Inhalt: Begriff, Definition, Relevanz im System (xAPI, LRS, KPI, Funnel, Kompetenzmodell, Hint, Mastery).}

% Kapitel 3: Stand der Technik
\section{Stand der Technik / verwandte Arbeiten}
\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.

\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{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.

\platzhalter{Tab. 2 - Technologievergleich}{Inhalt: xAPI/LRS vs. Custom Events; Kriterien: Interoperabilität, Aufwand, Datenschutz, Flexibilität, Tooling.}

\platzhalter{Abb. 3 - Dashboard-Landschaft}{Inhalt: Übersicht (Klasse), Detail (Schüler), Warnindikatoren, Export/Report.}

% Kapitel 4: Analyse des Kernproblems
\section{Analyse des Kernproblems}
\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.

\subsection{Anforderungen}
Die wesentlichen 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.
\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.

\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.

\platzhalter{Tab. 3 - Stakeholder-Ziel-Daten-Rechtsgrundlage}{Inhalt: Stakeholder (Lehrkraft, Schule, Lernende, Entwickler), Zweck, Datenkategorien, Zugriff, Aufbewahrung.}

\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
\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.

\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.

\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}

\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.

\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:

\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:

\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
\end{itemize}

\subsubsection{xAPI-Profil und LRS-Integration}
Für Interoperabilität werden Events als xAPI-Statements modelliert. Ein projektspezifisches xAPI-Profil definiert:

\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).
\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.

\platzhalter{Tab. 6 - Event-/xAPI-Statement-Katalog}{Inhalt: Eventname; Trigger; xAPI-Verb; Attribute; Zweck; personenbezogener Bezug; Aufbewahrung; Aggregationsregel.}

\platzhalter{Listing 2 - Client Logging (TypeScript/Pseudocode)}{Inhalt: Logger-Interface, Event-Batching, Offline-Queue, Consent-Check.}

\platzhalter{Listing 3 - Server Collector + Validation}{Inhalt: Endpoint, Schema-Validation, Rate-Limits, Pseudonymisierung, Weiterleitung ans LRS.}

\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.}

\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.

\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.

\platzhalter{Tab. 7 - RBAC-Matrix}{Inhalt: Rolle (Schüler, Lehrkraft, Admin, Entwickler); Datenzugriff; Exportrechte; Audit.}

\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
\section{Diskussion und Bewertung}
\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}

\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}

\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.

\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.

\platzhalter{Tab. 8 - Pro/Contra-Matrix}{Inhalt: Kriterien (Validität, Aufwand, Datenschutz, Akzeptanz); Vergleich xAPI-Ansatz vs. Alternativen.}

% Kapitel 7: Evaluation
\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:

\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.
\end{itemize}

\platzhalter{Abb. 9 - Beispiel-Auswertungsgrafiken}{Inhalt: Lernverlauf pro Klasse; Fehler-Hotspots; Funnel „Lesson → Practice → Mastery“.}

% Kapitel 8: Fazit
\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.

\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{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.

% Literaturverzeichnis
\section*{Literaturverzeichnis}
\begin{thebibliography}{9}
\bibitem{lit1} Autor, A. (2023). \emph{Titel der Quelle}. Verlag.
% Weitere Einträge hier einfügen
\end{thebibliography}

% Anhang
\appendix
\section{Vollständiger Event-/Statement-Katalog}
\platzhalter{Anhang-Tabellen}{Vollständige Liste aller Events, Attribute, Datenklassifikation, Aufbewahrung.}

\section{xAPI-Profil (Verben/Objekte/Context)}
\platzhalter{Profil-JSON / Dokumentation}{Definierte Verben, Objekttypen, Extension-Felder.}

\section{Codeauszüge}
\platzhalter{Listings}{Logger-Bibliothek, Collector-Service, Aggregation-Jobs.}

\section{Zusätzliche Diagramme und Mock-ups}
\platzhalter{Mock-ups/Diagramme}{Schüler-UI Varianten, Dashboard Drilldowns, RBAC-Flows, Consent-Screens.}

\end{document}