\documentclass{seriousgames-seminar}

% Literaturverzeichnis-Datei
\addbibresource{references.bib}

\begin{document}

% Titelblatt
\begin{titlepage}
    \centering
    \vspace*{2cm}
    {\Huge\bfseries Telemetrie in Serious Games\par}
    \vspace{0.5cm}
    {\Large Möglichkeiten, Herausforderungen, Architektur- und Evaluationsansätze\par}
    \vspace{1.5cm}
    {\Large Seminararbeit zu Serious Games\par}
    \vspace{2cm}
    {\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}
\label{sec:einleitung}

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

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

\subsection{xAPI und Learning Record Store (LRS)}
\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.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=0.9\textwidth]{figures/xapi-schema.pdf}
    \caption{xAPI-Statement-Schema}
    \label{fig:xapi_schema}
\end{figure}

\begin{listing}[H]
\centering
\inputminted{json}{listings/xapi-example.json}
\caption{Beispiel-xAPI-Statements (JSON)}
\label{lst:xapi_example}
\end{listing}

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

\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 / verwandte Arbeiten
\section{Stand der Technik / verwandte Arbeiten}
\label{sec:stand_der_technik}

\subsection{Auswertemöglichkeiten in Serious Games}
\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}
\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 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.

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

\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}
\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}
\label{subsec:anforderungen}
Zentrale Anforderungen sind:

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

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

% Kapitel 5: Lösungsansätze / Konzepte / Modelle
\section{Lösungsansätze / Konzepte / Modelle}
\label{sec:loesungsansaetze}

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

\begin{figure}[H]
    \centering
    \includegraphics[width=0.9\textwidth]{figures/metrics-and-indicators.pdf}
    \caption{Messmodell / Indikatoren-Mapping}
    \label{fig:messmodell}
\end{figure}

\subsection{Telemetrie- und Analytics-Konzept}
\label{subsec:analytics_konzept}

\subsubsection{Telemetrie-Ziele und Datenprinzipien}
\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.

\subsubsection{Event- und Statement-Taxonomie}
\label{subsubsec:event_taxonomie}
Empfohlen ist eine Taxonomie, die didaktische, verhaltensbezogene und technische Ereignisse trennt. Kernkategorien:

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

Feedbackmechanismen sollten erklärbar sein (zunächst regelbasiert) und Unsicherheit kommunizieren. Dashboards dienen als Entscheidungsunterstützung („Human-in-the-Loop“).

\begin{figure}[H]
    \centering
    \includegraphics[width=0.9\textwidth]{figures/feedback-loop.pdf}
    \caption{Feedback-Loop}
    \label{fig:feedback_loop}
\end{figure}

\subsection{Referenzarchitektur und Governance}
\label{subsec:referenzarchitektur}

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

\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}
\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)}
\label{subsubsec:rbac}
Zugriffe sind rollen- und kontextgebunden. Individuelle Daten sind restriktiver als Aggregationen; Exportrechte sind begrenzt und auditierbar.

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

% Kapitel 6: Diskussion und Bewertung
\section{Diskussion und Bewertung}
\label{sec:diskussion}

\subsection{Vorteile}
\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}
\label{subsec:nachteile}
Grenzen liegen in Messvalidität, Komplexität von Pipeline und Governance, Interpretationsrisiken sowie Akzeptanz- und Fairnessfragen.

\subsection{Alternativen}
\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}
\label{subsec:reflexion}
Telemetrie muss zweckgebunden, transparent und minimalinvasiv sein. Dashboards sollten Unsicherheit sichtbar machen und konservative Warnlogiken verwenden.

% Kapitel 7: Evaluation und Erfolgsmessung
\section{Evaluation und Erfolgsmessung}
\label{sec:evaluation}

\subsection{Evaluationsdesign (kompakt)}
\label{subsec:evaluationsdesign}
\begin{itemize}
    \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}

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

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}
\label{sec:fazit}

\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}
\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
\printbibliography[title=Literaturverzeichnis]

% Anhang
\appendix
\section{Vollständiger Event-/Statement-Katalog}
\label{sec:event_katalog}

\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}
\label{sec:code_auszuege}

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