Summary
Game analytics is the collection, analysis, and application of data about how players interact with a game. Analytics transforms design decisions from gut-feel into evidence-based iterations: rather than assuming that a level feels too hard, telemetry can reveal that 60% of players quit at a specific point, and qualitative feedback can explain why.
Analytics is most powerful when combined with qualitative research — data tells designers what players are doing; playtesting tells them why.
(CRE342 Lectures, see source-cre342-lectures)
Quantitative vs qualitative data
| Type | Description | Captures | Tools |
|---|---|---|---|
| Quantitative | Measurable, numerical, system-generated | What players do | Analytics dashboards, telemetry, event logs |
| Qualitative | Descriptive, experience-based | Why behaviours occur | Surveys, think-aloud protocols, video observation, sentiment analysis |
Example triangulation:
- Quantitative: “40% of players quit after Level 2.”
- Qualitative: Playtesters report “the puzzle feels unfair” or “controls are confusing.”
- Combined insight: Level 2 has a specific interaction that players interpret as a rule violation; redesign that interaction.
Engagement metrics
Engagement metrics measure how actively and frequently players interact with the game.
| Metric | Definition | Design implication |
|---|---|---|
| Session length | Average duration of a play session | Short sessions may indicate frustration or lack of hooks |
| Session frequency | How often players return per day/week | Low frequency may indicate weak retention mechanics |
| DAU | Daily Active Users | Core health metric for live games |
| WAU | Weekly Active Users | Mid-term health |
| MAU | Monthly Active Users | Long-term health; DAU/MAU ratio indicates “stickiness” |
| Playtime per player | Total accumulated play time | Distinguishes deeply engaged players from casual |
| Retention rate | % of players returning after a set period (D1, D7, D30) | Core measure of long-term design quality |
Churn rate
Churn is the inverse of retention — the percentage of players who stop playing after a given period.
Churn rate = (Players lost during period ÷ Players at start of period) × 100
Example: 1,000 players start; 250 stop playing within a week → Churn = 25%.
Industry benchmarks (mobile):
- Day 1: 64–72% of players churn (iOS/Android)
- Day 30: 94–97% churn in many mobile titles
- Day 30 retention: typically only 2.5–5%
Design implication: High early churn makes the First-Time User Experience (FTUE) — the first few minutes — the most critical design challenge. If the game does not create an immediate reason to continue, most players will never return.
Using churn data:
- Identify onboarding bottlenecks (high drop-off after tutorial)
- Adjust difficulty pacing or reward timing
- Cross-reference with qualitative feedback
- A/B test changes and re-measure
Progression metrics
Progression metrics track how players advance through the game’s content.
| Metric | What it reveals | Design response if abnormal |
|---|---|---|
| Level completion rate | % of players finishing each level | Sharp drop = difficulty spike, unclear objectives, or poor checkpointing |
| Checkpoint frequency | How often players reach milestones | Too few = fatigue; too many = reduced challenge and tension |
| Failure/retry counts | Balance and frustration indicators | High = frustration or poor tutorial; low = insufficient challenge |
| Item/skill unlock timing | Reward pacing | Long gaps between unlocks = disengagement; use early reward density |
| Achievement rate | Which goals players actually pursue | Rarely attained = too obscure/grindy; too common = lacks perceived value |
Reading progression data as a narrative:
“60% complete Level 3 but only 25% reach Level 4.” → Investigate: UI confusion? Difficulty spike? Unskippable cutscene? Enemy health jump?
Progression metrics map directly to challenge/skill balance. Smooth curves sustain flow; sudden drops create anxiety or boredom. (see flow)
Predictive analytics
Once engagement and progression data is established, predictive analytics attempts to forecast future behaviour — most importantly, which players are at risk of churning.
Methods: Decision trees, random forest, support vector machines (SVMs), neural networks, Hidden Markov Models.
Modes:
- Reactive — identify churned players after the fact; understand why
- Proactive — identify at-risk players before they churn; intervene with targeted rewards or adjustments
Predictive analytics is most valuable for live service games with large player populations where small retention improvements have large commercial impact.
Economic metrics
Economic metrics apply to games with internal economies, virtual currencies, or real-money transactions.
| Metric | Definition |
|---|---|
| In-game currency earn/spend ratio | Identifies economy balance; large imbalance = inflation or deflation |
| ARPU | Average Revenue Per User (total revenue ÷ total players) |
| ARPPU | Average Revenue Per Paying User (total revenue ÷ paying players only) |
| Conversion rate | % of players who make at least one real-money purchase |
| Item popularity / purchase frequency | Indicates perceived value of store items |
| Resource sink tracking | Ensures no soft-lock due to scarcity |
Virality
Virality measures how many new users each existing user recruits. The standard formula is:
k = i × c
Where k is the virality factor, i is the average number of invitations each user sends, and c is the conversion rate of those invitations into new active players.
- k > 1 → the game grows without paid acquisition; each cohort of players recruits more than itself
- k < 1 → the game requires ongoing paid marketing to sustain its player base
- k = 1 → stable; each player is replaced by one recruit on average
Example: Average user sends 100 invites; 3% convert to players → k = 3. One “patient zero” becomes 3 new players, who become 9, who become 27, etc.
In practice, k is measured retrospectively and fluctuates. Studios once used k > 1 as a justification for heavy upfront paid acquisition (buying chart position to trigger organic growth) — this is now considered unreliable. Virality is a side effect of effective design, not a system you can buy into.
Design implication: Social features, share mechanics, and referral rewards are direct levers on i and c. Natural virality (players telling friends because the game is good) is more durable than engineered virality (spam-the-news-feed FarmVille mechanics).
(Hiwiller, Players Making Decisions, Ch. 33, see source-players-making-decisions)
F2P spending distribution (whale economics)
F2P revenue is heavily Pareto-distributed: the spending of a tiny minority of players funds the game for everyone else.
Empirical data (Swrve, reported in Hiwiller):
- 1.5% of users ever converted into paying customers
- Average ARPPU: 15.27 USD/month
- Only 0.45% of all players ever paid above the average
- Top decile of payers (~1 in 700 users) averaged 77.70 USD and contributed >50% of total revenue
Hiwiller’s F2P spending estimation model (using X = a small baseline spend, e.g. 2-3 USD):
| Tier | % of users | Spend |
|---|---|---|
| Top-spenders | 0.2% | 20X USD each |
| Medium-spenders | 0.5% | 5X USD each |
| Low-spenders | 0.7% | X USD each |
| Non-spenders | 98.6% | 0 USD |
This means a game’s revenue is dominated by a tiny number of high-value players. The design and business implications are significant:
- Design: Monetisation systems need enough ceiling for top-spenders without making the game feel pay-to-win for the 98.6% who never pay
- Business: Losing even a handful of whales can materially harm revenue; churn analysis should segment paying vs non-paying players
- Ethics: Whale-dependent models raise questions about whether a small number of vulnerable players are subsidising a free experience for the majority (see dark-patterns)
The same Pareto shape appears in organic game sales: top 0.07% of iOS apps account for 40% of all App Store revenue; the bottom 47% earn under 100 USD/month.
(Hiwiller, Players Making Decisions, Ch. 33–34, see source-players-making-decisions)
Social and behavioural metrics
For multiplayer and community-based games:
| Metric | Reveals |
|---|---|
| Matchmaking wait times | Population balance; long waits signal imbalance or poor matchmaking parameters |
| Player-to-player interactions | Quantity and quality of social engagement; high positive interaction = community cohesion |
| Toxicity reports / abandon rates | Behavioural health of the player base |
| Guild/team participation | Players in social structures retain longer and are more satisfied; decline precedes churn |
Technical and performance metrics
Technical metrics directly influence perceived polish and player satisfaction:
- Frame rate stability (FPS)
- Loading times and latency
- Crash frequency and error rate
- Input responsiveness
Poor technical performance breaks the player-system contract — even well-designed games feel bad when running poorly.
Data visualisation
Visualisation transforms raw data into actionable insight:
- Heatmaps — spatial maps of player deaths, movement paths, or interaction points; reveal where players cluster or die
- Spatio-temporal maps — player behaviour across time; reveal when problems occur in sessions, not just where
- Dashboards — real-time KPIs, engagement graphs, funnel visualisations
- Funnel analysis — what % of players complete each step of a sequence; steep drops indicate friction points
Analytics tools
Unity Analytics (first-party)
Integrated directly into Unity; no external SDK required.
Key features:
- Real-time data: sessions, active users, retention, revenue
- Custom Events: send designer-defined data (level completion, deaths, positions)
- Funnels: track player progression through specific sequences
- Remote Config: adjust game parameters live without rebuilding
- A/B Testing: test gameplay variants
- DAU/MAU engagement metrics
GameAnalytics (free, third-party)
Widely used in indie and mobile development; specialises in player behaviour and economy.
Key features:
- Predefined dashboards: sessions, retention, progression, resources, performance
- Custom Events: specific player actions
- Heatmaps (optional add-on)
- Error and performance tracking
- Cross-platform SDKs: Unity, Unreal, Godot, C++
Sellers’ analytical balance and the iron equation
Sellers (Advanced Game Design, Ch. 10) frames analytics not just as a measurement tool but as a balance method — a systematic way to determine whether the game’s acquisition, progression, and monetisation design is working as a coherent financial system.
The key retention benchmarks Sellers uses as design targets:
| Metric | Target range (mobile F2P) |
|---|---|
| D0 (same-session return) | Goal: close the first session on a hook |
| D1 retention | Strong: 40%+ |
| D7 retention | Strong: 20%+ |
| D30 retention | Acceptable: 5%+; Strong: 10%+ |
| DAU/MAU stickiness | 20%+ indicates habitual play |
These retention benchmarks are not arbitrary — they are the observable indicators of whether the progression curve is engaging players through each phase of the game. A sharp D7 drop almost always indicates that the mid-game progression loop breaks (rewards become too slow, content runs dry, or the challenge curve becomes inconsistent).
The iron equation
The fundamental financial viability test for any free-to-play or service game:
LTV > eCPU + Ops
Where:
- LTV (Lifetime Value): total revenue expected from a player over their entire engagement lifetime
- eCPU (Effective Cost Per User): the cost to acquire that player — advertising, influencer spend, store featuring, etc.
- Ops (Operational cost): ongoing server, support, and content costs per player
If LTV ≤ eCPU + Ops, the game loses money on every player acquired. No volume of growth will resolve this. The iron equation must be satisfied before investing in acquisition at scale.
Progression design’s role: LTV is largely determined by D30 and long-term retention. A game that churns 97% of players by Day 30 has LTV approaching zero. This is why retention is the most important leading indicator of financial health — it is the measurable proxy for LTV before long-term data is available.
The FTUE is the critical battleground: The First-Time User Experience (first 0–5 minutes) is where the majority of players are lost. Even a game with excellent mid- and late-game content will fail the iron equation if its onboarding does not create an immediate reason to return.
(Sellers, Advanced Game Design, Ch. 10; see also progression-and-power-curves for the full analytical balance framework)
Evidence-based design loop
Analytics feeds into an iterative design process:
Hypothesis → Implementation → Measurement → Adjustment → Validation → Hypothesis
Example: Identify 60% tutorial drop-off → hypothesise tutorial is too long → shorten and add feedback → remeasure retention → validate improvement → iterate.
“Without data, you’re just another person with an opinion.” — W. Edwards Deming
Important caveat: Data reveals behaviour; it does not reveal experience. A player who completes every level but gives a low satisfaction rating is not captured by completion metrics alone. Analytics requires qualitative context.
Related
-
playtesting — Qualitative counterpart to analytics; reveals the why behind behavioural data
-
progression-and-power-curves — Progression curve types; iron equation; LTV/eCPU/retention framework
-
game-balance — Analytics-informed difficulty tuning; churn identifies imbalance
-
flow — Progression curves should sustain flow; analytics reveals where the channel breaks
-
reward-systems — Reward timing and pacing tuned through retention data
-
dark-patterns — Economic metrics can reveal whether monetisation systems are exploitative
-
game-industry-realities — P&L, cash flow, platform economics, and the career context in which analytics decisions are made
-
post-launch-and-live-ops — How retention, churn, progression, and community metrics feed into update cadence and support decisions after launch