Why the level system in a mobile app does not retain users
The level system in a mobile app almost always appears first: an experience bar, a level number, a pop-up notification about leveling up.
The problem is that by itself it does not retain anything — progression in a game works only when the reward arrives before the player has time to get bored.
A typical breakdown is a linear experience curve. Each next level costs the same increment more, and by the tenth step the cost of progression grows several times: the player has not yet received anything tangible, but the pace has already dropped.
The second skew is that the reward does not change the game: an increase to a characteristic that affects nothing devalues the entire path traveled.
Early churn of players almost always occurs on the second or third day. The events show the same picture: the player reaches the third or fourth level, takes the reward, and does not open the app the next day.
The share of those who reach the first significant reward turns out to be several times lower than the share of those who reach the third level — which means the curve was calculated from the desired number of levels, not from the real pace of progression.
This is treated by rebuilding the experience curve: milestone rewards are placed on the steps that the player passes in the first sessions, and then the cost of a level grows together with the unlocked opportunities.
Retention in an app rests on the rhythm of rewards, not on their quantity. Below we discuss how to calculate such a curve and where it breaks.
Measurable effect: retention, returns, pace of progression
Progression is evaluated not by "it became more interesting" but by four related quantities: first- and seventh-day retention, the share of players returning after a pause, the pace of level completion, and engagement in the app — the number and length of sessions per day.
These indicators move together: as the pace of progression accelerates, the share of those who reach the middle of the story grows, and along with it, returns.
According to industry measurements GameAnalytics, first-day retention in the median stays at about a third of installs, while the upper quartile differs several times over. The main loss occurs on the third to fifth levels — that is, in the first minutes, not in late content.
A practical shift is provided by three solutions. The first levels are shortened to a quick completion so that the reward is received before the player closes the app.
The progress bar shows a visible remainder until the next level, and the reward is given at the session boundary, not at its beginning. Plus, an unfinished goal remains — "almost achieved" — and that is what pulls the player to the next day.
In our practice, reworking progression accelerated the pace of completing the first ten levels and increased the share of returns after a pause of three or more days: progress is saved, the nearest goal is visible, the next step does not require relearning. We calculate retention metrics by install cohorts — otherwise, growth in acquisition masks churn.
The result: with the same volume of acquisition, the active base is wider, and each install yields more sessions. This is the measurable result: not levels for the sake of levels, but a managed retention curve.
Progression models: linear, seasonal, hybrid
A progression model is not about a beautiful scale, but about how long the product maintains motivation without a constant influx of new content.
If levels grow endlessly, the audience hits a ceiling and the scale stops meaning anything; if it is reset too often, past efforts are devalued.
Therefore, we first look at the length of the content cycle, the share of newcomers, and the frequency of updates, and only then choose the mode.
| Option | When suitable | Limitations |
|---|---|---|
| Linear progression | Content is updated in large blocks, the core audience is stable, a simple and honest scale is needed | The ceiling is reached and motivation falls; a newcomer forever lags behind a veteran; levels have to be manually appended |
| Seasonal levels | Regular releases, competitive content, an even entry for newcomers is needed | Season reset devalues past efforts; without honest transfer of rewards and timers, dissatisfaction and confusion in data grow |
| Hybrid progression model | A long product with seasonal events and a constant base scale | Two scales and two analytics — more expensive to support; errors in transfer rules are felt by players most strongly |
The hybrid is a working compromise: the base scale lives for years and stores history, while seasonal levels are built on top and reset.
We make the season reset soft — ranks, rewards, and cosmetics remain with the player, only seasonal experience and leaderboard position are reset.
We move transfer rules and recalculation of already accumulated progress into settings, not into code: a new season launches without an app update, and the player does not lose achievements due to a migration error.
Implementation stages: from mechanics audit to handover
Implementing levels is not "turning on an experience bar". The work proceeds in stages, and each ends with an artifact: an event map, a curve configuration, accrual rules, a control group report.
- Audit of game mechanics and data. We analyze which actions are already logged, where progress is calculated, and how session history is stored. The output is an event map suitable for experience accrual and a list of places where an additional collection point is needed.
- Progression design. We calculate the curve: how many actions until the next level, how the step grows, where the "wall" appears. The first levels are completed quickly, then growth is smooth, otherwise the middle of the funnel falls off.
- Reward setup. We determine what a level gives — accesses, cosmetics, leaderboard position. Accrual lives on the server and works idempotently: resending an event does not double experience or grant a reward twice.
- Data schema and synchronization. Profile model, experience storage, behavior offline and when logging in from another device. We version the schema so that new fields do not break previously released builds.
- Testing changes on traffic. We roll out the mechanic to a portion of users and compare with the control group: retention, returns, session depth, profile response speed. The mechanic remains only if the gain is reproducible.
- Observability. A dashboard with level distribution and the share stuck on one step, alerts for discrepancy between events and experience balance.
- Handover. Documentation on rules, access to configuration, and instructions on how to change the curve and rewards without releasing a new app version.
Handover artifacts: configurations, schemas, regulations
After handover, the block of levels and experience should not remain a black box that only we know how to edit. We move progression parameters into configurations and hand them over along with documentation — balance changes without rebuilding the app. Here is what remains in your hands.
- Progression schema — level tree, experience thresholds, and growth curve formula. It is visible at which step the player gets stuck; the threshold is edited with one line in the settings file.
- Experience accrual rules — source table: how much experience an action gives, daily limits, multipliers for a streak, protection against double accrual.
- Reward tables — binding a reward to a level or event, drop weights, re-issuance rules. They are verified against accrual rules in tests, not on live players.
- Seasonal event regulations — launch window, what happens to accumulated experience when a season ends, how unclaimed rewards are transferred, who launches a season early.
- Data schema and logging — where the current balance is stored, how progress synchronizes between devices, what to write to the log to analyze a disputed accrual.
- Check matrix and edit instructions — acceptance scenarios (level jump, limit cap, season rollback, two devices) and a list of parameters that are changed by settings without an app update.
Configurations are versioned together with the code, so any balance edit can be rolled back to the previous state. We hand over in source formats, with comments and a filled-in example.
Case study: how weekly retention grew after a relaunch
A game app with casual puzzles: installs came in waves, but by the end of the first week, less than a fifth of players remained.
Analysis of the funnel showed that the reason was not traffic or the number of levels, but the progression itself: the reward came rarely, experience was accrued in one block at the end of the level.
The player did not see whether they were approaching the next level and found no reason to open the app tomorrow.
The threshold of the next level grew faster than the player could accumulate experience — at the third or fourth level, it required twice as much as the average completed level gave.
The bar froze at 60–70%, and the streak reset for a missed day with no possibility of recovery: after such a break, one did not want to return.
What was changed during the mechanics relaunch
Experience was split into short accruals for actions within a level, the bar moved every 20–30 seconds instead of several minutes.
Thresholds were leveled so that a new level came every 2–3 sessions, not once a week; the streak was allowed to be restored once, and rewards at levels were tied to cosmetics and unlocking new modes.
After the update in App Store, progress synchronized between devices, so changing the phone no longer reset achievements.
Metrics before and after
First-day retention grew from 41% to 52%, first-week retention — from 18% to 29%. The share of players reaching the fifth level rose from 22% to 47%, the average number of sessions in the first week — from 3 to 5.
Time to the first level decreased from nine minutes to two and a half, so a newcomer received the first reward in the same session.
The curve held even a month after the relaunch: the mechanic changed, not a one-time promotion. Next, we tune progression by segments — short steps to reward for newcomers, an accelerated return to rhythm for those who returned after a pause.
How does seasonal progression differ from permanent progression?
These are not alternatives, but two modes of one scale. Permanent progression lives for the entire lifespan of the app: levels, experience, and unlocked opportunities accumulate and do not reset.
Seasonal progression goes in cycles — when a season ends, the scale compresses, rewards are replaced, and the player's leaderboard position is recalculated anew.
The difference in maintaining the mechanics is fundamental. The permanent scale is configured once: experience curve, multipliers for actions, level thresholds — after that, only pinpoint balance edits.
Seasonal progression requires content updates for each start: new tasks, rewards, screen design. If you miss a release, players open an empty season, and the motivation to return is reset along with it.
The approaches affect returns differently. A season gives predictable bursts of activity at the start, but retention between cycles sags if the new season has nothing to offer.
The permanent scale gives an even schedule of visits: a person comes in to finish a level or complete a collection. Content updates in both cases pass App Store review, so the season start date is planned with a margin, not by the calendar.
| Criterion | Permanent progression | Seasonal progression |
|---|---|---|
| Content update cycle | once a quarter or less often | every season, strictly by calendar |
| Maintenance of mechanics | configured once, then balance | constant flow of tasks and rewards |
| Impact on returns | even growth, holds the core audience | spike at the start and decline by the end of the cycle |
| Risk during update | low: old levels do not break | high: progress reset annoys active players |
| When to choose | long apps with accumulation | short cycles and regular events |
In practice, they are combined: the permanent scale is responsible for long-term motivation, the seasonal one — for regular reasons to return. We break down both mechanics into stages so that support is planned in advance and does not turn into a rush before each start.
Technical doubts: questions about implementation and support
We design progression as a server subsystem: level thresholds, experience accrual curve, and reward tables live in configuration, and the client only displays the player's state. This removes desynchronization between platforms and experience cheating through a modified client. Below are the questions most often raised by technical teams at the evaluation stage.
How do you control experience inflation?
The accrual curve is defined by a formula, not by a separate line for each level, and is verified by simulation: we run the player's behavior at different intensity over a horizon of 30/60/90 days and see where they land on the scale.
If experience sources grow faster than thresholds, the upper levels are devalued — we adjust the coefficients before release, not after complaints.
What to do if a new mechanic conflicts with the existing economy?
We catch mechanic conflicts at the design stage: we create a map of all experience sources and look at intersections — for example, a daily login reward devalues progression tasks.
We put controversial mechanics behind a separate flag and enable them in stages, tracking the distribution of players by level.
Can levels and rewards be changed without releasing a new version?
Yes. Thresholds, multipliers, and reward composition are stored in a remote configuration, so we release balancing and seasonal changes without an update in the stores — an app version is needed only when the logic itself changes.
Each change is versioned, and the configuration can be rolled back to the previous one if metrics sag.
Let's discuss the task and come back with an estimate and plan
To come back with an estimate and plan, we need not a brief "add levels" but input data for an audit.
Progression touches experience accrual, balance storage, analytics, and anti-cheat protection — without these details, the estimate turns into a range "from and to".
- App events and current analytics: which actions are already logged, where sessions and retention are calculated.
- Progression rules: how many levels, experience step, what is given at a level, whether there is a diminishing or accelerating curve.
- Data schema: where the experience balance is stored, who is the source of truth — client or server, what happens offline and on re-entry.
- Anti-cheat requirements: server-side validation of events, restrictions on double accrual, daily limits.
- Platform restrictions and the share of users on old builds — this determines whether a forced update is needed.
- Test accounts and access to development and testing environments: accrual, level reset, change rollback.
- The person responsible on the customer's side who approves progression rules and the reward issuance procedure.
The first step is task analysis: we go through the list, mark what already exists and what needs to be designed. After that, we provide an estimate of implementation work and a staged progression implementation plan, with checkpoints on a test audience.
We describe post-handover support separately: monitoring accruals, investigating balance discrepancies, and adjusting rule balance based on actual behavior. Describe the task — we will come back with an estimate and plan.