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.
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.
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.
\textbf{Serious Games} sind Spiele, deren primäres Ziel ein extrinsischer Nutzen (z. B. Lernen, Training, Verhaltenstraining) ist. \textbf{Learning Analytics} bezeichnet die Erhebung, Messung, Analyse und Darstellung von Daten über Lernende und Lernkontexte, um Lernen zu verstehen und zu optimieren. \textbf{Game Learning Analytics} erweitert dies um spielspezifische Prozess- und Interaktionsdaten.
\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:
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. Ein \textbf{Learning Record Store} speichert diese Statements und stellt sie über APIs für Auswertung bereit.
Telemetrie in Serious Games erfordert Privacy-by-Design: Zweckbindung, Datenminimierung, Transparenz, Zugriffsbeschränkung, sichere Verarbeitung, Aufbewahrung/Löschung sowie klare Rollen (Verantwortliche/Verarbeiter) \. Je nach Kontext sind Einwilligung oder andere Rechtsgrundlagen sowie ggf. eine Datenschutz-Folgenabschätzung zu prüfen.
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.
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.
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.
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)}
\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.
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.
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.
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.
\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.
Feedbackmechanismen sollten erklärbar sein (zunächst regelbasiert) und Unsicherheit kommunizieren. Dashboards dienen als Entscheidungsunterstützung („Human-in-the-Loop“).
Zwei Ebenen: Rohdaten/Lernspur (auditierbar) und Aggregationen (dashboardtauglich, datenschutzfreundlicher). Aggregationen werden in definierten Intervallen und mit klaren Zeitfenstern berechnet.
\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).
Telemetrie ermöglicht Prozesssicht (nicht nur Endstände), frühzeitige Risikoerkennung, gezielte Interventionen sowie datenbasierte Weiterentwicklung von Lerninhalten und Feedback.
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.
Telemetrie muss zweckgebunden, transparent und minimalinvasiv sein. Dashboards sollten Unsicherheit sichtbar machen und konservative Warnlogiken verwenden.
\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.
Wichtig: KPIs müssen \textbf{dokumentiert und versioniert} werden (verwendete Events, Formel/Nenner, Zeitfenster, Umgang mit Missing Data/Ausreißern), damit Zeitreihen vergleichbar bleiben.
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).
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.
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.
