Dla studia gier dane przestały być raportem na koniec miesiąca. To, czy gracz zostanie, ile wyda i gdzie utknie na poziomie, rozstrzyga się w zdarzeniach, które gra wysyła co sekundę. Problem w tym, że analityka gracza rzadko zawodzi na poziomie pomysłu, a niemal zawsze na poziomie inżynierii: skali, jakości danych i tego, czy zespół nadąża za produkcją.
Z naszego doświadczenia najtrudniej nie jest wymyślić, co mierzyć, tylko dostarczyć pipeline, który uniesie ruch z całej bazy graczy i poda zespołowi wiarygodne liczby na czas. Nawet jeśli nie pokażemy tu case study z gotowym dashboardem retencji, mamy ludzi, którzy to robią, oraz realne kompetencje w przetwarzaniu strumieni danych, w tym w projekcie gamingowym opartym o Apache Kafka.
Dlaczego dane w grze są tak trudne do okiełznania?
Gra to jedno z najbardziej wymagających źródeł danych, z jakimi mierzy się zespół analityczny. Skala bywa ekstremalna: popularny tytuł mobilny potrafi emitować miliardy zdarzeń dziennie, a każda sesja to dziesiątki zdarzeń od startu poziomu po mikrotransakcję. Dochodzi różnorodność: zdarzenie zakupu wygląda inaczej niż zdarzenie walki, a schemat zmienia się z każdym patchem.
Dane w grze są też gęste czasowo i kontekstowe. Pojedyncze kliknięcie znaczy niewiele, dopiero ciąg zdarzeń w sesji opowiada historię gracza. Dlatego surowa telemetria wymaga modelu, który porządkuje zdarzenia w sesje, poziomy i kohorty, zanim ktokolwiek zobaczy wykres.
Jak zbudować pipeline zdarzeń i telemetrię gracza?
Fundamentem jest telemetria w grach, czyli kontrakt zdarzeń między klientem gry a backendem. Projektujemy go tak, żeby był wersjonowany i odporny na zmiany, bo schemat level_completed z dzisiaj musi współżyć z wersją sprzed trzech patchy. Zdarzenia spływają z klienta i serwera gry do warstwy przyjęcia, a stamtąd do przetwarzania strumieniowego.
Sercem tej warstwy jest zwykle streaming oparty o Apache Kafka. Kafka buforuje napływ zdarzeń, rozdziela go na tematy (zakupy, progresja, sesje) i pozwala kilku konsumentom czytać ten sam strumień niezależnie. Na tej bazie budujemy:
- warstwę przyjęcia zdarzeń (SDK w kliencie, API zbierające, walidacja schematu),
- przetwarzanie strumieniowe (Kafka, agregacje w locie, wzbogacanie zdarzeń),
- magazyn analityczny (hurtownia lub jezioro danych pod zapytania ad hoc),
- warstwę serwowania zasilającą dashboardy i modele.
Dzięki rozdzieleniu strumienia od magazynu te same zdarzenia zasilają równolegle raport na żywo i trening modelu, bez wzajemnego blokowania.
Jakie dashboardy lejka i retencji dają zespołowi realny obraz?
Kiedy dane płyną, zespół potrzebuje ich w formie, która prowadzi do decyzji. Budujemy dashboardy wokół dwóch pytań, które nie dają spać dyrektorowi produktu: gdzie tracimy graczy i czy wracają. Lejek onboardingu pokazuje, na którym kroku pierwszej sesji gracze odpadają, często to jeden ekran samouczka przesądza o instalacji wartej kampanii marketingowej.
Druga oś to retencja w kohortach. Wskaźniki D1, D7 i D30 zestawiamy względem daty instalacji, kanału pozyskania i wersji gry, żeby odróżnić efekt patcha od efektu kampanii. Taki widok zamienia ogólne „retencja spadła” w konkretne „kohorta z ostatniej aktualizacji odpada w D7 na nowym bossie”.
Jak postawić infrastrukturę A/B testów?
Decyzje w grze warto rozstrzygać danymi, a nie przeczuciem, dlatego infrastruktura A/B testów to osobny, inżynierski temat. Potrzebna jest warstwa przypisywania graczy do wariantów (deterministyczna, stabilna między sesjami), mechanizm flag funkcyjnych, który włącza wariant bez wydawania nowego builda, oraz rygor statystyczny po stronie analizy. Spinamy to z pipeline’em tak, żeby ekspozycja na wariant była sama w sobie zdarzeniem, co pozwala uczciwie policzyć wpływ zmiany na konwersję czy czas sesji.
Jak raportować balans i ekonomię gry?
Gra free-to-play to żywa gospodarka, a jej raporty balansu ekonomii są tyle samo analityką, co narzędziem projektanta. Monitorujemy przepływy waluty wewnętrznej, tempo zdobywania i wydawania zasobów, inflację nagród oraz punkty, w których gracze napotykają ścianę. Źródła i ujścia waluty zestawiamy per segment, bo inaczej gra się „dla płacącego wieloryba”, a inaczej dla gracza niepłacącego. Dzięki temu projektant dostroi drop rate czy cenę przedmiotu, zanim zepsuty balans odbije się na retencji i przychodach.
Jak działają modele predykcji churn?
Najciekawsze zaczyna się, gdy od opisu przechodzimy do predykcji. Predykcja churn to model uczenia maszynowego, który na podstawie zachowania gracza szacuje prawdopodobieństwo, że przestanie grać. Cechy budujemy ze strumienia telemetrii: częstotliwość sesji, trend czasu gry, postęp w progresji, reakcja na porażki, historia zakupów. Model (od regresji i gradient boostingu po sieci dla sekwencji zdarzeń) zwraca wynik, który zespół CRM zamienia w akcję: ofertę, powiadomienie, wyzwanie dopasowane do momentu.
Taki model ma wartość tylko wtedy, gdy jest operacyjny, a nie slajdem w prezentacji. Dlatego od początku projektujemy go pod wdrożenie: regularny retrening, monitoring dryfu danych i pętlę, w której skuteczność akcji retencyjnej wraca do modelu jako kolejna cecha.
Dlaczego jakość danych przesądza o wszystkim?
Każdy dashboard i każdy model są warte tyle, ile zdarzenia, które je zasilają. Dlatego jakość danych traktujemy jako osobną warstwę, a nie dodatek. Pilnujemy kilku rzeczy:
- walidacji schematu na wejściu, żeby zepsuty event z nowego builda nie skaził raportów,
- obsługi duplikatów i zdarzeń spóźnionych, typowych przy niestabilnym połączeniu mobilnym,
- spójności definicji metryk, żeby „aktywny gracz” znaczył to samo w każdym zespole,
- monitoringu wolumenów, który alarmuje, gdy strumień zdarzeń nagle milknie lub puchnie.
To niewdzięczna, mało efektowna praca, która decyduje o tym, czy zarząd zaufa liczbom.
Jakie kompetencje dostarczamy do analityki gracza?
Dobieramy skład pod konkretny etap, a nie „na zapas”. W projektach danych i streamingu najczęściej obsadzamy role:
- data engineer budujący pipeline zdarzeń i streaming (Kafka, przetwarzanie strumieniowe),
- inżynier hurtowni / analytics engineer modelujący dane pod raporty,
- data scientist / inżynier ML odpowiadający za modele predykcji churn,
- analityk produktu łączący dane z pytaniami biznesowymi studia.
Siłę tej układanki daje Grupa RITS: kompetencje Big Data i strumieniowego przetwarzania danych oraz nasze zespoły AI/LLM/Data, realizujące projekty AI, LLM i uczenia maszynowego. To zaplecze pozwala obsadzić i inżynierię danych, i warstwę modeli.
Jak robimy to w RITS?
Działamy jako partner nearshore z Polski, który dokłada kompetencje tam, gdzie zespół studia ich nie ma albo nie nadąża. W praktyce nasi inżynierowie wpinają się w istniejący pipeline i rozwijają go dalej, a nie przepisują wszystko od zera. Mamy realne doświadczenie w budowie streamingu zdarzeń na Apache Kafka, w tym w projekcie z obszaru gamingu, oraz w projektach Big Data i ML w ramach Grupy. Kompetencje weryfikujemy przed startem, a skład dobieramy pod konkretny etap: inną obsadę ma postawienie pipeline’u od podstaw, a inną dołożenie modelu churn do działającej analityki. Jako partner z Polski pracujemy w zbliżonej strefie czasowej, więc zespół wchodzi w rytm przeglądów kodu bez długiego rozruchu.
Od czego zacząć budowę analityki i telemetrii gracza?
Zacznij od jednego pytania biznesowego, które najbardziej boli, na przykład „dlaczego tracimy graczy w pierwszym tygodniu”, i od zdarzeń, które są potrzebne, żeby na nie odpowiedzieć. To wyznacza kształt telemetrii, architekturę pipeline’u i role, których potrzebujesz, zanim zainwestujesz w modele. Różnice między modelami współpracy opisaliśmy w artykule o modelach współpracy IT.
Budujesz analitykę gracza albo telemetrię w swojej grze? Porozmawiajmy, dobierzemy zespół i architekturę pod Twoją skalę danych.