How to Calculate Retention Rate in Mobile Games: The Day-N Formula, a Worked Cohort Example, Classic vs Rolling vs Bracket Retention, and Why Tools Disagree on D1

Retention rate in mobile games (Day-N retention) is the share of users who first opened the game on a given day and came back on day N. If 9,600 users first opened your game on November 2 and 3,360 of them returned on November 3, that cohort's D1 retention is 35%.

Day-N retention (%) = cohort users who returned on day N ÷ cohort users on Day 0 × 100

The retention rate formula that tops most search results, (E − N) ÷ S × 100, was built for businesses that count customers or employees per period. The D1, D7, and D30 figures the games industry talks about come from the install-cohort formula above, not from that one. As of November 2026, even tools that share the Day-N formula define the boundary of a "day," the time zone, and the denominator differently in their official documentation, which is how the same game can show D1 figures more than 10 percentage points apart in two dashboards. This post walks through the formula, a worked example, the retention types, the definition traps, and how to read a retention curve. Benchmarks by genre and percentile are covered separately in D1/D7/D30 Retention Benchmarks for 2026: What Good Looks Like and How to Read Your Own Curve.

How do you calculate retention rate for a mobile game?

You calculate retention per daily install cohort: the numerator is the number of people who came back on day N, and the denominator is the size of that cohort on Day 0.

Day 0 is the day of first open, Day 1 is the next day, and Day 7 is seven days later. The denominator stays fixed at the Day 0 cohort size all the way through. If you divide by the previous day's active users instead, you get a day-over-day survival rate rather than retention, and the number looks far better than it is. Tenjin's documentation defines retention rate the same way: unique N-day retained users ÷ unique Day 0 users × 100.

Here is D1, D3, D7, and D30 for the November 2 cohort. The figures are assumptions for illustration.

Two things in this table are easy to miss. First, 15% D7 retention is not the share of people who stayed for seven days; it is the share who opened the game on exactly day 7. Someone who played on days 2 through 6 but skipped day 7 is not in D7. Second, the 480 users at D30 are not necessarily a subset of the 1,440 at D7. A user who skipped day 7 but came back on day 30 still counts at D30. That is why classic retention usually declines over time but can tick back up on event days.

How do you combine several cohorts into one average?

When you combine daily cohorts, do not average the retention rates. Divide the sum of returning users by the sum of cohort sizes, and leave out any cohort that has not yet reached day N, in both the numerator and the denominator.

Below is a daily cohort table built from data through November 10. Assume a large UA push on November 4 raised first opens to 20,000 and pulled that day's D1 down to 30%.

The weighted D1 is 15,744 ÷ 48,000 = 32.8%, while a simple average of the four rates gives 33.5%. The simple average gives the large UA cohort's weak D1 only a one-quarter weight. The more your daily install volume swings, the wider this gap becomes.

For D7, only the November 2 and 3 cohorts have reached day 7, so D7 is 2,560 ÷ 17,600 = 14.5%. If you leave the immature cohorts in the denominator and compute 2,560 ÷ 48,000, you get 5.3%. Retention did not fall; the calculation is wrong. Adjust's documentation draws the same distinction: a mature cohort shows data only for periods that have fully elapsed, while an immature cohort leaves out users who have not completed the period, so cohort size shrinks at later days. Whenever a dashboard's date range includes recent cohorts, check how the tool handles immature cohorts before you read its D7 or D30 averages.

How to slice a cohort table by channel, country, and campaign is covered in Cohort Analysis in Mobile Games: A Practical Guide.

Why doesn't the (E − N) ÷ S formula work for games?

(E − N) ÷ S × 100 measures how many of the customers you had at the start of a period (S) are still there at the end. Applied to a game, it blends long-time loyal players with new users in a single number and hides how fast new installs leave.

Suppose October monthly active users (S) were 100,000, 60,000 new users (N) arrived in November, and November monthly active users (E) came to 110,000. (110,000 − 60,000) ÷ 100,000 = 50%, so the formula tells you half of your existing users stayed. But if that month's new cohort has 5% D30 retention, only about 3,000 of the 60,000 are still playing a month later. The 50% is held up by a core audience that has played for years, while most users bought through UA leave in their first week.

The formula causes three problems in games. It cannot show the first day and first week, where most churn happens. It cannot isolate the effect of a campaign or an update, because there is no group of users defined by install date or channel. And the definitions of E and N are unstable: whether a lapsed player who comes back counts as new (N) or as a survivor from S changes the result.

That is why games do not use (E − N) ÷ S as a retention metric, and treat it at most as a secondary check on how well the monthly active base is holding. Churn rate calculations fall into the same trap, as covered in How to Calculate Churn Rate and Avoid the Most Common Mistakes.

What is the difference between classic, rolling, and bracket retention, and when should you use each?

Classic (Day-N) retention only asks whether a user was active on exactly day N. Rolling (unbounded) retention counts users active on day N or any later day. Bracket retention counts users active at least once within a defined window such as days 1 to 3. For the same cohort, rolling and bracket values come out higher than classic.

In a classification of retention types written by a devtodev analyst, rolling retention is defined as users who logged in on day N or later ÷ users who installed N days ago, and it is always greater than or equal to classic retention. Amplitude offers the same concepts as Return On (day N), Return On or After (day N or later, formerly called Unbounded), and Return On (Custom) for custom windows; its documentation example uses brackets of Day 0, Days 1–3, Days 4–6, and Days 7–11.

Rolling retention needs particular care. Because it counts any return on or after day N, the rolling D7 you calculated yesterday for last week's cohort goes up if those users return today. Put rolling figures for recent and older cohorts side by side, and the older cohorts will look better than they are.

GA4 uses the term in the opposite direction. Among the cohort calculation methods in GA4 explorations, "Rolling" counts only users who met the return criteria in that period and in every previous period. It keeps only users who came back without a gap, which is far stricter than what the industry calls rolling retention. Whenever a report says "rolling retention," note which tool's definition it uses.

In practice, we recommend classic D1, D7, and D30 as the core metrics, with one bracket chosen to fit the genre as a secondary view. Use classic when comparing with external benchmarks or evaluating UA channels. For genres people don't open every day, such as strategy and SLG titles played in one or two short sessions a day, or midcore games played in weekend bursts, add brackets like Days 1–3 and Days 4–7 to smooth out the daily noise after D1.

Why does the same game show a different D1 in different tools?

There are four main reasons. Tools differ on whether a day is cut by calendar date or in 24-hour windows from install time, on which time zone they use, on whether the denominator is installs or first opens, and on what counts as a return.

The largest gap comes from the day boundary. Under calendar-date counting, a return on the next date counts as D1, so a user who first opens at 11:50 p.m. and comes back twenty minutes later, after midnight, is D1-retained. Under 24-hour windows, the user has to return between 24 and 48 hours after the first open. In an example Amplitude published, the same app's D1 was 43% by calendar date and 32% by 24-hour window, an 11-point gap. The gap is widest in the first few days and nearly disappears by D30. A 24-hour-window D1 also takes 48 hours to settle.

Calendar-date counting then raises the time zone question. GameAnalytics calculates metrics in UTC dates. A Korean player who first opens at 8:30 a.m. local time (11:30 p.m. UTC the previous day) and returns at 10:00 a.m. (1:00 a.m. UTC the next day) played twice on the same local day but counts as D1-retained in UTC. This is why D1 can be inflated or deflated for games whose players sit far from UTC, in Asia or the Americas.

Denominators differ too. App Store Connect excludes users who installed the app but never opened it from both the numerator and the denominator. A user who installs on January 1 and first opens on January 10 is added to the January 1 cohort's denominator on January 10, so a cohort's retention can change after you have already looked at it. Compare an internal report that uses store downloads as the denominator with an MMP report that uses first opens, and the earlier example gives 3,360 ÷ 10,000 = 33.6% in one and 3,360 ÷ 9,600 = 35.0% in the other.

Finally, the return event differs. Values change depending on whether a tool counts app opens, session starts, or a specific event. GA4 lets you choose both the cohort inclusion criteria and the return criteria from events, transactions, or conversions, which is why you should check whether an app woken in the background by a push notification is being counted as a return.

Because of these differences, it pays to keep a one-page internal retention definition. It only needs five lines: the day-boundary method, the time zone, the denominator (whether it is first opens), the return event, and how reinstalls are handled. Check that those five match before comparing your numbers with an external benchmark or a partner's report.

How do you read a retention curve?

A retention curve plots classic retention from Day 0 to Day N. What matters on the curve is not the height at any single day but where it drops most and where it flattens.

Most games drop hardest between Day 0 and Day 1, lose less each day through the first week, and then level off. Each segment points to a different place to look. A low D1 points to the first-session experience and traffic quality; a steep fall between D1 and D7 points to reasons to come back daily (daily rewards, progression goals, events); a curve that is still falling after D30 points to content depth and live operations. How the first session shapes D1 is covered in Onboarding Decides Your D1: First-Session Design and the FTUE Metrics That Matter.

There is also a way to summarize the curve in one number. Add up classic retention from Day 0 through Day 30, and you get the average number of days an installed user was active in their first 31 days, because each day's retention is the probability of being active that day. If the sum is 4.2, the average user played on 4.2 days in their first month, and multiplying that by revenue per active day (ARPDAU) gives an approximation of 30-day LTV. That is why widening the area under the whole curve feeds revenue more directly than lifting D1 alone.

External reference points only work when definitions match. In GameAnalytics' 2026 benchmarks report (calendar year 2025, more than 16,000 mobile games with at least 1,000 MAU, updated August 24, 2026), median D1 retention for mobile games is around 22%, with the top 25% just above 30%. Median D7 is just under 4%, and median D30 is around 0.7–0.8%. These are far below the commonly quoted "35/15/5" for D1/D7/D30. The report uses strict retention on UTC dates and includes a broad set of small games, so align definitions and population before comparing it with your own numbers. Genre differences are covered in Retention by Game Genre: Why It Varies and How to Optimize It.

Using retention as a campaign performance standard

Once the retention formula is set correctly, you can compare UA channels by cohort curve rather than by install count. Put channel-level D1 and D7 curves side by side under the same definition, and you can separate channels whose installs are cheap but whose curves break early from channels that cost more per install but whose curves hold.

Playio is an Android-based community of 5 million gamers that matches players with games that fit their tastes, using genre preferences, play history, and in-game behavior data. Its default pricing is CPI, and it also supports CPE tied to in-game actions such as reaching a cumulative playtime, playing across several days, or hitting a specific level. When you set playtime-based or daily-play-based rewards as the goal for the D1–D7 stretch where the curve drops most, you pay not for a single install but for players who make it past the first week and widen the area under the curve. When evaluating such a campaign, apply the definitions in this post as they are, and compare D1, D7, and D30 against other channels' cohorts from the same period on the same basis.

More details are available here. (https://playioadsen.oopy.io/bizdeck)

Key Takeaways

Retention rate in mobile games is the number of cohort users who returned on day N divided by the Day 0 cohort size, with the denominator fixed at Day 0 throughout. When combining cohorts, divide the sum of returning users by the sum of cohort sizes and exclude cohorts that have not yet reached day N. The (E − N) ÷ S formula common in search results mixes long-term and new users and hides first-week churn, so it does not work as a game retention metric. Classic retention looks at exactly day N, rolling at any day from N onward, and bracket at a defined window, and rolling and bracket are always higher than classic. As of November 2026, tools differ on the day boundary (calendar date vs 24-hour window), time zone (property time zone vs UTC), denominator (installs vs first opens), and return event, so the same app's D1 can land as far apart as 43% and 32%. Read the retention curve for where it drops most and where it flattens, and summarize it as the sum of Day 0–30 retention (active days per user), which connects directly to LTV.

For inquiries about Playio's advertising solutions, reach out at: [email protected]

Sources (for data verification; decide at publishing whether to show):

• Tenjin, Retention Rate (RR) documentation (retention rate = unique N-day retained users ÷ unique Day 0 users × 100; with the UTC cohort option, Day 1 begins at the first UTC midnight after install): https://tenjin.com/docs/retention-rate-rr

• Google Analytics Help, [GA4] Cohort exploration (inclusion and return criteria; standard, rolling, and cumulative calculation — rolling requires meeting return criteria in that period and all previous periods; daily = midnight to midnight in property time zone, weekly = Sunday to Saturday, monthly = calendar month): https://support.google.com/analytics/answer/9670133?hl=en

• Adjust Help Center, How cohorts work (moment of install or reattribution is 0, D0 = 24 hours after install; mature cohorts show only elapsed periods, immature cohorts exclude users who have not completed the period, so cohort size shrinks): https://help.adjust.com/en/article/how-cohorts-work

• GameAnalytics Docs, Metrics (retention = share of users who installed on a day and returned N days later, reported as DayN; strict retention ignoring previous days; calculated in UTC dates and hours): https://docs.gameanalytics.com/events-metrics-and-filtering/metrics

• Apple Developer, App Store Connect Analytics Help — App retention (installers who never open are excluded from numerator and denominator; a January 1 install first opened on January 10 is added to the denominator on January 10; based only on users who share diagnostics): https://developer.apple.com/help/app-store-connect-analytics/engagement/app-retention

• Branch Help, FAQ on Day 0 and Day 1 (Day 0 is the install day, Day 1 the following day; install tracked as first open): https://help.branch.io/faq/docs/most-sites-would-refer-to-day-0-as-the-day-the-person-installed-the-app-wouldnt-it-be-100-can-you-tell-me-what-you-mean-by-day-0-and-day-1

• Amplitude Docs, Interpret your retention analysis (Return On / Return On or After, formerly Unbounded / Return On (Custom); bracket example Day 0, 1–3, 4–6, 7–11; choice of 24-hour windows or calendar dates): https://amplitude.com/docs/en/analytics/charts/retention-analysis/retention-analysis-interpret

• Amplitude Blog, Why N Day Retention is the Metric that Matters for Mobile Games (originally published 2020-02-14; same app D1 43% by calendar date vs 32% by 24-hour window; gap largest in the first days; 24-hour-window D1 needs 48 hours): https://amplitude.com/blog/n-day-retention-for-mobile-games

• WN Hub, 4 types of retention: what is retention?, Vera Karpova (devtodev), 2017-11-24 (classic retention formula; rolling retention = logged in on day N or later ÷ installed N days ago, always ≥ classic; full, return, and range retention): https://wnhub.io/news/other/item-13524

• GameAnalytics, 2026 Mobile & PC Gaming Benchmarks (2025-01-01 to 2025-12-31, 16,000+ mobile games across 9 regions on iOS and Android, MAU ≥ 1,000; mobile D1 median ~22%, top 25% just above 30%; D7 median just under 4%, top 25% 6–7%; D30 median ~0.68–0.79%, top 25% 1.6–1.8%; updated 2026-08-24): https://www.gameanalytics.com/reports/2026-mobile-pc-gaming-benchmarks

• Own calculations: 11/2 cohort (9,600 first opens) D1/D3/D7/D30, four-cohort weighted averages (D1 15,744 ÷ 48,000; D7 2,560 ÷ 17,600) and the error from including immature cohorts (2,560 ÷ 48,000), (E − N) ÷ S example (100k, 60k, 110k), 10,000 installs vs 9,600 first opens, KST/UTC boundary example, sum of Day 0–30 retention = active days per user: illustrative assumptions and calculations