| Measure | What it shows | Planning use |
|---|---|---|
| Funnel step drop-off | The exact step in a linear journey where conversion falls unexpectedly | Flags which level to examine first, because levels are played in sequence |
| Time between actions | Steps where users take an unusually long time to move on | Treat long solve times as a bottleneck signal, even when the level is eventually completed |
| Tester reaction when stuck | Whether a player asks for a hint, puts the level aside happily or loses interest | Separates healthy challenge from the kind of frustration that ends a session |
| Tester experience and persistence | Context for reading any single tester’s result | Record before rating so one expert or one quitter does not set the score |
| Device segment | Whether a weak stage appears only on one type of device | Rules out handling problems before blaming puzzle design |
The funnel and time-between-actions points follow this funnel analysis guide, and the tester questions follow this puzzle difficulty guide.
Learning how to measure puzzle difficulty means pairing per-level funnel data with observed tester behaviour, then merging both into one rank-based score. A level is suspect when drop-off, long pauses and lost interest all point at the same place.
This method belongs to wider indie puzzle game development work. A small team can run it with very few roles, and the guide on how many people to make a puzzle game shows who usually owns testing and analytics.
Setup: per-level tracking before any testing
Game analytics gives the numbers that tester notes cannot: how many players reach a level, how many finish it and how long they take. Set up three events for every level: level started, level completed and level abandoned. Add a timestamp to each, so solve time can be calculated as the gap between start and completion.
Puzzle levels are played in order, so a level funnel is a good fit. Funnel analysis is used for finding conversion rate issues in a linear user journey, and a level sequence is exactly that. Each level becomes a step, and completion rate is the share of players who move from one step to the next.
- Name events consistently. Use the same naming pattern for every level so the funnel can be built without manual cleanup.
- Log device type. It is needed later to separate puzzle problems from handling problems.
- Wait before reading. A new funnel may need a few days to confirm the data is processing correctly, so do not judge levels from the first partial results.
Testing sessions: what to observe
Playtesting supplies the reasons behind the numbers. Before a session starts, ask each tester about their puzzle experience and how long they usually persist with a stuck puzzle. The advice is to ask about experience and persistence before choosing a tier, and the same logic applies to rating a level: the answer tells you how to weight what you then see.
- Record start and finish times. A stopwatch or the event log is enough for solve time.
- Note the stuck moment. Write down the point where the tester stops making progress, not only that they were stuck.
- Classify the reaction. When a tester stalls, note whether they ask for a hint, put the level aside happily or lose interest. Those three outcomes mean different things for the level.
- Keep your own comments out. Do not explain the puzzle mid-session, or the stuck point disappears.
How many testers are enough
No headcount makes a rating reliable on its own, because the mix of testers matters as much as the number. Include players with different experience and persistence, and rate each group’s results separately. A practical stopping rule is to keep adding testers until a new tester no longer changes the rank order of your levels.
Why players quit puzzle levels
Players quit when they cannot tell what to try next. Some puzzles let you see exactly why a move fails, and those give a stuck player something to learn from. A level that rejects moves without explanation leaves only guessing.
The stuck reaction is the best predictor available from sessions. A tester who asks for a hint is still engaged, and a tester who sets the level aside happily may return. A tester who loses interest is the one who matters for churn, so a level that produces that reaction deserves a high rating, even if its average solve time looks ordinary.
Look in the data for levels where abandonment comes after a long pause rather than after quick failed attempts. That pattern suggests players tried, ran out of ideas and left. Quick abandonment more often points to something else, such as unclear instructions or controls.
Reading the level funnel
A funnel shows the exact step where conversion drops off unexpectedly. In a puzzle game that step is a level, so the funnel answers the first question directly: which metrics show a level is too difficult? Low completion rate relative to neighbouring levels is the first one. Long time between level start and completion is the second.
Some loss is normal. Every funnel shows a certain amount of abandonment at each stage, however well the journey is tuned. Do not hunt for a level with no drop-off. Compare each level with the levels around it, and investigate the ones that stand out.
Solve time adds the second dimension. Look for steps where users take an unusually long time to move on. A level with healthy completion but a long solve time is a time bottleneck, and it can still wear players down over a session.
Scoring each level
A numeric rating needs one shared scale. Rank-based scoring avoids inventing thresholds: rank every level on each measure, then combine the ranks.
- Rank drop-off. Order levels from lowest to highest abandonment at that level’s funnel step.
- Rank solve time. Order levels by typical time between start and completion.
- Rank attempts. Order levels by how many tries a player needs before finishing.
- Rank tester stuck signals. Order levels by how often testers stalled, asked for hints or lost interest.
- Combine. Average the ranks into one difficulty score per level. Give the tester stuck signals extra weight if your data is thin, since they explain the cause.
Weigh the ranks by tester group where you can. A level that experienced testers finish quickly but newer testers abandon deserves a rating that reflects your target audience, not the fastest group. Turn the final scores into easy, medium and hard bands only as a labelling convenience for planning the sequence.
Spotting difficulty spikes
A difficulty spike is a level whose score jumps well above the levels either side of it. Plot the combined score for every level in order, then look for peaks. A gradual rise is a curve. A sudden peak followed by a drop is a spike, and it is the level to fix or move.
Confirm any peak with the funnel, which pinpoints the exact step where drop-off occurs. If the funnel and the tester notes agree, the spike is real. If they disagree, trust the tester notes for cause and the funnel for scale.
Spike data also informs pricing decisions. Where a spike falls matters when planning a free levels then paid puzzle game structure, since a hard level near the paywall boundary can lose players before they ever decide to pay.
Troubleshooting odd results
- High drop-off but short solve time. Players are leaving quickly, so suspect unclear instructions or controls rather than puzzle depth. Segment the funnel by device, because segmenting by the type of user device can expose a weak stage on one platform only.
- Long solve time but good completion. The level is slow rather than blocking. Check tester reactions: if they set it aside happily, leave it; if they lose interest, shorten the path to the answer.
- Testers disagree. Split results by experience and persistence before averaging. Disagreement usually means the level suits one group only.
- No clear spike anywhere. Either the curve is smooth or the data is too thin. Add testers before changing levels.
Frequently asked questions
Do control or readability problems count as difficulty?
No. Check size, handling and visibility separately from difficulty. Tap targets, small text or poor contrast can raise drop-off without making the puzzle any harder.
Can a difficulty band be used as a pass or fail line?
No. Difficulty tiers are selection suggestions, not scientific thresholds. Use bands to organise levels, and use the funnel and tester notes to decide what to change.
Does a tester making early progress mean a level is easy?
Not necessarily. Local success does not prove the whole solution works: one good sum or one fitted piece does not prove the entire arrangement will work. Record when testers finish the whole level, not only when they make a first successful move.