Für ein Spielestudio haben Daten aufgehört, ein Bericht zum Monatsende zu sein. Ob ein Spieler bleibt, wie viel er ausgibt und wo er in einem Level hängen bleibt, entscheidet sich in den Events, die das Spiel jede Sekunde sendet. Der Haken ist, dass Spieleranalytik selten an der Idee scheitert und fast immer am Engineering: an Maßstab, Datenqualität und daran, ob das Team mit der Produktion Schritt hält.
Aus unserer Erfahrung liegt das Schwierige nicht darin zu entscheiden, was man misst, sondern darin, eine Pipeline zu liefern, die den Verkehr der gesamten Spielerbasis trägt und dem Team rechtzeitig verlässliche Zahlen gibt. Auch wenn wir hier keine Referenz mit fertigem Retention-Dashboard zeigen, haben wir die Menschen, die das machen, und echte Kompetenz in Stream Processing, darunter ein Gaming-Projekt auf Apache Kafka. Dieser Artikel zeigt, wie wir das Problem angehen.
Warum sind Spieldaten so schwer zu bändigen?
Ein Spiel ist eine der anspruchsvollsten Datenquellen, denen ein Analytikteam begegnet. Der Maßstab kann extrem sein: Ein beliebter Mobile-Titel kann Milliarden Events pro Tag aussenden, und jede Spielersession besteht aus Dutzenden Events, vom Levelstart bis zur Mikrotransaktion. Dazu kommt die Vielfalt: Ein Kaufereignis sieht ganz anders aus als ein Kampfereignis, und das Schema verschiebt sich mit jedem Patch.
Spieldaten sind außerdem dicht in Zeit und Kontext. Ein einzelner Tipp bedeutet wenig, erst eine Folge von Events in einer Session erzählt die Geschichte des Spielers. Deshalb braucht rohe Telemetrie ein Modell, das Events in Sessions, Level und Kohorten ordnet, bevor irgendwer ein Diagramm sieht. Ohne das ertrinkt das Team in Daten, die sich mit nichts vergleichen lassen.
Wie bauen Sie Event-Pipeline und Spielertelemetrie?
Das Fundament ist die Spielertelemetrie, der Event-Vertrag zwischen Spielclient und Backend. Wir entwerfen ihn versioniert und änderungstolerant, denn das heutige Schema von level_completed muss mit einer Fassung von vor drei Patches koexistieren. Events fließen vom Client und vom Game Server in eine Ingestion-Schicht und von dort in die Stream-Verarbeitung.
Das Herz dieser Schicht ist meist Streaming auf Apache Kafka. Kafka puffert die eingehenden Events, teilt sie in Topics (Käufe, Fortschritt, Sessions) und lässt mehrere Konsumenten denselben Strom unabhängig lesen. Darauf bauen wir:
- die Event-Ingestion-Schicht (Client-SDK, Sammel-API, Schemavalidierung),
- Stream Processing (Kafka, Aggregationen im Fluss, Anreicherung der Events),
- einen analytischen Speicher (Warehouse oder Data Lake für Ad-hoc-Abfragen),
- eine Serving-Schicht, die Dashboards und Modelle versorgt.
Durch die Trennung von Strom und Speicher speisen dieselben Events parallel einen laufenden Bericht und ein Modelltraining, ohne sich gegenseitig zu blockieren.
Welche Funnel- und Retention-Dashboards geben dem Team ein echtes Bild?
Sobald Daten fließen, braucht das Team sie in einer Form, die zu Entscheidungen führt. Wir bauen Dashboards um die zwei Fragen herum, die eine Produktleitung nachts wach halten: wo wir Spieler verlieren und ob sie zurückkommen. Der Onboarding-Funnel zeigt, an welchem Schritt der ersten Session Spieler abspringen - oft entscheidet eine einzige Tutorial-Maske über das Schicksal einer Installation im Wert einer Marketingkampagne.
Die zweite Achse ist die Kohorten-Retention. Wir schneiden die üblichen D1-, D7- und D30-Werte nach Installationsdatum, Akquisekanal und Spielversion, um die Wirkung eines Patches von der einer Kampagne zu trennen. Diese Sicht verwandelt ein vages „die Retention ist gefallen” in ein konkretes „die Kohorte aus dem letzten Update fällt bei D7 am neuen Boss ab”.
Wie ziehen Sie eine Infrastruktur für A/B-Tests hoch?
Entscheidungen im Spiel verdienen es, von Daten statt von Instinkt entschieden zu werden, was eine Infrastruktur für A/B-Tests zu einem eigenen Engineering-Thema macht. Sie brauchen eine Schicht, die Spieler Varianten zuweist (deterministisch und über Sessions hinweg stabil), einen Feature-Flag-Mechanismus, der eine Variante ohne neuen Build umschaltet, und statistische Strenge auf der Auswertungsseite. Wir binden das in die Event-Pipeline ein, sodass die Zuweisung zu einer Variante selbst ein Event ist - das erlaubt es, die Wirkung der Änderung auf Konversion oder Sessionlänge ehrlich zu messen. Ohne diese Disziplin liefern Tests Zahlen, denen Sie nicht trauen können.
Wie berichten Sie Balancing und Ökonomie des Spiels?
Ein Free-to-play-Spiel ist eine lebende Ökonomie, und seine Berichte zum Ökonomie-Balancing sind ebenso Analytik wie Werkzeug der Designer. Wir verfolgen die Flüsse der Spielwährung, das Tempo des Verdienens und Ausgebens von Ressourcen, die Inflation der Belohnungen und die Punkte, an denen Spieler gegen eine Wand laufen. Wir schlüsseln Quellen und Senken der Währung nach Segment auf, denn das Spiel spielt sich für einen zahlenden Wal anders als für einen Nichtzahler. Ein guter Ökonomiebericht erlaubt es einer Designerin, eine Droprate oder einen Gegenstandspreis zu justieren, bevor ein kaputtes Balancing Retention und Umsatz nach unten zieht.
Wie funktionieren Modelle zur Churn-Prognose?
Der interessanteste Teil beginnt beim Übergang von der Beschreibung zur Prognose. Churn-Prognose ist ein Machine-Learning-Modell, das aus dem Verhalten eines Spielers die Wahrscheinlichkeit schätzt, dass er aufhört zu spielen. Wir bilden Merkmale aus dem Telemetriestrom: Sessionhäufigkeit, Trend der Spielzeit, Fortschrittstempo, Reaktion auf Niederlagen, Kaufhistorie. Das Modell (von Regression und Gradient Boosting bis zu Netzen über Eventfolgen) liefert einen Score, den das CRM-Team in Handlung übersetzt: ein Angebot, eine Benachrichtigung, eine zum Moment passende Herausforderung.
Ein solches Modell ist nur dann etwas wert, wenn es operativ ist und nicht eine Folie in einem Deck. Deshalb entwerfen wir es von Anfang an für den Betrieb: regelmäßiges Nachtrainieren, Monitoring der Datendrift und eine Schleife, in der der Erfolg einer Retention-Maßnahme als weiteres Merkmal ins Modell zurückfließt.
Warum entscheidet Datenqualität über alles?
Jedes Dashboard und jedes Modell ist nur so viel wert wie die Events, die es speisen. Deshalb behandeln wir Datenqualität als eigene Schicht und nicht als Nachgedanken. Wir achten auf einiges:
- Schemavalidierung bei der Aufnahme, damit ein kaputtes Event aus einem neuen Build die Berichte nicht vergiftet,
- Umgang mit Duplikaten und verspäteten Events, häufig bei instabiler Mobilverbindung,
- konsistente Kennzahlendefinitionen, damit „aktiver Spieler” in jedem Team dasselbe bedeutet,
- Volumen-Monitoring, das Alarm schlägt, wenn der Eventstrom plötzlich verstummt oder aufbläht.
Das ist undankbare, unglamouröse Arbeit, und sie entscheidet darüber, ob die Führung den Zahlen traut.
Welche Kompetenzen stellen wir für die Spieleranalytik?
Wir schneiden das Team auf die konkrete Phase zu, nicht „für alle Fälle”. In Daten- und Streaming-Projekten besetzen wir am häufigsten:
- einen Data Engineer, der Event-Pipeline und Streaming baut (Kafka, Stream Processing),
- einen Warehouse-/Analytics-Engineer, der Daten für das Reporting modelliert,
- einen Data Scientist / ML Engineer, der die Modelle zur Churn-Prognose verantwortet,
- einen Produktanalysten, der die Daten mit den Geschäftsfragen des Studios verbindet.
Die Stärke hinter dieser Aufstellung ist die RITS Group: Kompetenz in Big Data und Stream Processing sowie unsere AI-/LLM-/Datenteams, die AI-, LLM- und Machine-Learning-Projekte liefern. Dieser Rückhalt erlaubt es uns, sowohl die Data-Engineering- als auch die Modellschicht zu besetzen.
Wie machen wir das bei RITS?
Wir arbeiten als Nearshore-Partner aus Polen, der Kompetenz dort ergänzt, wo sie dem Team des Studios fehlt oder nicht mitkommt. In der Praxis klinken sich unsere Engineers in die bestehende Pipeline ein und entwickeln sie weiter, statt alles von null neu zu schreiben. Wir haben echte Erfahrung im Bau von Event-Streaming auf Apache Kafka, darunter ein Gaming-Projekt, sowie in Big-Data- und ML-Projekten in der Gruppe. Wir prüfen die Kompetenzen vor dem Start und schneiden das Team auf die konkrete Phase zu: Eine Pipeline von Grund auf hochzuziehen verlangt eine andere Aufstellung, als ein Churn-Modell an eine funktionierende Analytik anzubauen. Wir arbeiten in einer nahen Zeitzone, sodass das Team ohne lange Anlaufzeit in Ihre Code Reviews und Meetings einsteigt.
Wo beginnen Sie mit Spieleranalytik und Spielertelemetrie?
Beginnen Sie bei der einen Geschäftsfrage, die am meisten schmerzt, zum Beispiel „warum verlieren wir Spieler in der ersten Woche”, und bei den Events, die Sie zu ihrer Beantwortung brauchen. Das definiert die Form Ihrer Telemetrie, die Architektur der Pipeline und die Rollen, die Sie brauchen, bevor Sie in Modelle investieren. Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie bauen Spieleranalytik oder Spielertelemetrie in Ihrem Spiel? Sprechen wir darüber, wir stellen Team und Architektur passend zu Ihrem Datenmaßstab zusammen.