Quick answer: Crash-free sessions measures the share of individual play sessions that had no crash, while crash-free users measures the share of distinct players who never experienced a crash. The same crash data produces different numbers for each, and the gap between them tells you whether crashes are spread across many players or concentrated among a few.
Crash-free rate is a key stability metric, but 'crash-free' can be measured two ways, by session or by user, and the two tell different stories. Quoting one without knowing which is misleading, because they can diverge significantly. Understanding the difference between crash-free sessions and crash-free users, and what their gap reveals, lets you read your stability metrics accurately rather than being lulled or alarmed by whichever number you happened to look at.
Two Ways to Count 'Crash-Free'
Crash-free sessions counts at the level of play sessions: of all sessions in a period, what percentage had no crash? If there were 1,000 sessions and 10 crashed, that is 99% crash-free sessions. Crash-free users counts at the level of distinct players: of all players in a period, what percentage never experienced a crash? If 500 players played and 5 of them hit at least one crash, that is 99% crash-free users.
The two answer different questions. Crash-free sessions asks 'how often does a session go wrong?' Crash-free users asks 'what fraction of players are affected by crashes at all?' Because a single player has many sessions, and a single crashing player can ruin multiple sessions, the same underlying crashes produce different percentages depending on which unit you count.
Why They Diverge, and What the Gap Means
The two metrics diverge based on how crashes are distributed. If a small number of players crash repeatedly, many sessions each, crash-free users drops noticeably (those players are 'affected') while crash-free sessions may stay high (most sessions, including from non-crashing players, are fine). Conversely, crashes spread thinly across many players, one each, push crash-free users down faster than crash-free sessions.
The gap is itself informative. A large gap, crash-free sessions much higher than crash-free users, suggests crashes are concentrated: a subset of players (perhaps on specific hardware) crash a lot, while most players never do. That pattern points toward a compatibility or device-specific issue affecting a particular group. A small gap suggests crashes are evenly spread. Reading both metrics together, and their gap, tells you not just how stable the game is but how the instability is distributed.
Using Both Metrics Well
Neither metric is 'correct'; they are complementary, and you should know which you are looking at and ideally watch both. Crash-free sessions is a good general stability pulse; crash-free users tells you the breadth of player impact. For prioritization, you also want to go below the aggregate to which specific crashes are driving the numbers, since fixing the top crashes is what moves both metrics.
Bugnet's crash grouping and occurrence data connect these aggregate metrics to actionable issues: rather than just knowing your crash-free rate, you see which grouped crashes account for it and how many players and sessions each affects. If crash-free users is dragged down by crashes concentrated on certain hardware, the device context on grouped crashes reveals it. Understanding the session-versus-user distinction keeps you from misreading your stability, and tying it to grouped, occurrence-counted crashes turns the metric into a clear target: fix the crashes affecting the most users (or sessions, depending on which you are optimizing), and watch the corresponding rate climb.
Crash-free sessions counts sessions; crash-free users counts players. The gap between them tells you whether crashes are concentrated on a few players or spread across many.