Mobile app retention rate: how to calculate it and read benchmarks

A mobile app retention rate is the share of users from one install cohort who come back to the app on a set day after installing. Take the users from the cohort who return under your chosen rule, divide by the cohort’s original size, and multiply by 100. Read it as a curve with three waypoints, Day 1, Day 7 and Day 30, rather than as a single badge you earn or fail.

Imagine a fitness app that gets 84 new members in January. By the end of week two, 39 are still opening it. By week four, 22. By week eight, 11. That sequence says far more about the business than any one number could. Most app teams learn this the hard way: they open the retention dashboard, see a Day 30 figure in the single digits, and spend a quarter arguing about whether it is “good”. The argument misses the point.

What does mobile app retention rate mean?

Two apps can both report an 8% Day 30 retention rate and mean different things. One counts anyone who opened the app at least once from day 30 onward. The other counts only people who opened it on day 30 itself. One blends iOS and Android, new installs and long-tenured users. Same headline, different measurement.

The formula is simple: users from the cohort who return under your rule ÷ the cohort’s original size × 100. The hard part is agreeing on the inputs before the numbers appear.

The cohort is what keeps the metric honest. It works like a class register: 84 students enroll for the first lesson, and you track how many return for lesson two, who is still attending after a week, and who remains at the four-week review. You would never add this week’s new students to last month’s attendance and call the class stable. The same logic applies to subscribers; see customer retention rate.

Where does the curve go?

Retention falls fastest early, and that pattern is normal. OneSignal’s Mobile App Benchmarks of 2024 put average retention at 28.29% on Day 1, 17.86% on Day 7 and 7.88% on Day 30, with results published for 12 app categories. Fewer than one in three users came back the day after installing. Fewer than one in five made it through the first week. By the month mark, fewer than one in twelve remained.

The same benchmark shows business apps lower still: 25.38% on Day 1, 16.85% on Day 7 and 6.94% on Day 30. Category shifts the level; the downward shape stays familiar.

Each checkpoint answers a different question:

• Day 1 reflects onboarding: whether the user reached first value, how well the acquisition channel matched the product, and whether anything broke in the first session.
• Day 7 shows whether the app earned a place in someone’s short-term routine.
• Day 30 is the closest early signal of durable engagement and, for subscription apps, of whether the product can hold a paying relationship.

So the useful question is rarely “what is my retention rate?” It is where the curve flattens, and what happens to the users still there at that point.

The practical shift: read the steepness of each segment, then name the problem. A fall from Day 1 to Day 7 points to weak habit formation. A fall from Day 7 to Day 30 points to shallow ongoing value. They need different fixes.

For subscription apps, the drop between install and month one also explains why engagement retention and billing retention have to be read together. A user can still open the app while a failed payment, an expiring card or a quiet cancellation ends the revenue relationship.

How do you calculate your own retention rate?

1. 01 Fix the cohort One install period, its size locked before you query
2. 02 Define the return An app open or a core action, chosen before you look
3. 03 Pick the window rule Exact day, a band of days, or any time after
4. 04 Divide and repeat Returners ÷ cohort size × 100, at Day 1, 7 and 30

Six steps, each one there to stop a specific error.

1. Fix the install cohort. Choose a group with a shared start, such as everyone who installed in the first week of March, and lock its size before you query anything. Without a fixed denominator, the number drifts as new users arrive.
2. Define the return event before you look at the data. Opening the app is the usual choice, but for some products a core action is better: logging a workout, sending an invoice, connecting a bank account. Choosing the definition after seeing the numbers is how teams end up with a metric that can only go up.
3. Pick a window rule. Exact-day retention counts a user only if they open the app on day 7 itself. A window counts opens anywhere in days 6 to 8. An any-point rule counts anyone who opened at least once from day 7 onward. They do not give the same figure, so write down which one you used, every time.
4. Count the matches at each checkpoint. Day 1, Day 7 and Day 30, same cohort, same rule.
5. Divide by the original cohort size and multiply by 100. Example (hypothetical numbers): 1,000 installs, 260 open on Day 1, so 26%. At Day 7 you count 130: 13%. At Day 30 you count 45: 4.5%. Three numbers, one cohort, one story.
6. Compare against the same cohort’s prior period, not an industry average. The comparison that reflects your work is your own curve moving, cohort over cohort.

Which two mistakes wreck the number?

The first is a leaky cohort. If users who installed in March, April and May all land in one bucket, the denominator keeps growing while the numerator mixes product versions. Retention looks flat when it is getting worse.

The second is a tooling mismatch. If your install count comes from an attribution provider and your session count from a product analytics SDK, the two may disagree on device identity, time zone or what counts as a session. A Day 1 rate above 100% almost always comes from this. Pick one source of truth for each side of the fraction and keep it.

Getting the cohort right is the base for everything else, and the same groundwork you need for cohort retention analysis.

Why do retention benchmarks disagree?

The definition behind a retention figure can move the result more than the app’s quality does. A user who must open the app on exactly day 7 faces a stricter test than one who may open it any time between day 6 and day 8, or any time after day 7. Same behavior, three different verdicts.

Naming the methods: the strict version is classic retention, where a user must return on that specific day. The loosest is rolling retention, where any return from day 7 onward counts. When a retention number comes without its method, ask before you compare.

Definition	Counts as retained when	Effect on the reported rate
Exact day	The user opens the app on day 7 itself	Lowest figure, strictest test
Time window	The user opens it anywhere in days 6 to 8	Higher, depends on the window width
Any point after	The user opens it at least once from day 7 onward	Highest, hides drop-off

Rolling retention is the most flattering and the least informative: a user who came back once in month one and never again still counts as retained.

The definition is not the only variable. Adjust’s guidance on retention benchmarks breaks results down by region, and category widens the spread further, because apps built around daily habits tend to hold users longer than tools opened only when needed.

What should you check before comparing with a benchmark?

• Definition: classic, window or rolling.
• Window width: exact day, or a band of days.
• Platform mix: iOS and Android reported separately or blended.
• Geography: which markets the dataset covers.
• Acquisition channel: paid, organic and referral mixed or split.
• Category: your sub-category, not the all-apps average.

If any of these differ, the two numbers are not directly comparable, and a gap between them tells you nothing about your app.

Subscription businesses also need a second distinction: behavioral retention on one side, paid retention, renewals, involuntary churn and reactivation on the other. A user can stop opening your app while still being billed every month; another can keep opening it daily after a payment failure. For the churn side, see churn rate benchmarks.

What are typical Day 1, Day 7 and Day 30 benchmarks?

The shape is the same across datasets: a steep drop in the first week, a slower decline after that. The figures differ by source.

Benchmark	Day 1	Day 7	Day 30
OneSignal 2024, all categories published	28.29%	17.86%	7.88%
OneSignal 2024, business apps	25.38%	16.85%	6.94%
Adjust 2024 global median, as cited by RapidNative	26%	13%	7%

The Adjust figures come from RapidNative’s mobile app retention playbook, which describes them as “Adjust’s 2024 global benchmark” of median retention. OneSignal reports averages; Adjust, as cited, reports medians. That alone is enough to make the two rows differ, which is the lesson: quoting “the industry average” without naming the source and the method is like quoting a temperature without saying which city it was taken in.

Match the row to your situation. A team shipping a B2B tool should read the OneSignal business apps row (6.94% at Day 30) rather than the all-categories row (7.88%). The difference is small here, but the habit protects you from chasing an average built from apps nothing like yours. Then check that the source used the same window rule as you.

One more boundary: every row above counts a user as retained when they open the app again. None of them says whether that user is still paying.

How is engagement retention different from subscription retention?

1. 01 Engagement retention Users from an install cohort who open the app again. Source: product analytics.
2. 02 Subscription retention Users still paying: renewals, failed payments, cancellations, win-backs. Source: billing, App Store or Google Play.

Consider a subscription app with steady usage: weekly opens hold at 40% of the base, month after month. Then monthly recurring revenue bends downward, and nobody can explain it, because engagement looks fine.

The explanation is usually in the billing system, not the product. A card expires. A renewal is declined. A subscriber taps cancel and never tells you. Usage metrics cannot see any of that.

Public app benchmarks count a user as retained when they return to the app. Subscription economics depend on trial conversion, renewal timing, plan length, payment failures, cancellations and win-backs. Deck’s summary of RevenueCat’s State of Subscription Apps 2025 is one place to see how churn and retention vary by plan length and price. An app can hold modest usage retention while producing durable revenue, or strong usage while losing subscribers at every billing date.

On the App Store and Google Play, failed renewals go through the stores’ own retry and grace periods; see App Store billing retry and grace period and Google Play grace period and account hold.

How do you combine behavioral and billing cohorts?

Pair engagement signals with billing states. Six cohorts cover most cases:

Cohort	Engagement signal	Billing signal	Likely action
Active but unpaid	Opens weekly	Payment failed	Payment update prompt and timed retries
Paid but inactive	No opens for 14 days	Renewal approaching	Value reminder before renewal
Trial near conversion	Opens daily	Trial ends within 3 days	Conversion prompt with a clear benefit
Failed renewal	Still opening the app	Card declined	Recovery retries and an update link
Recently canceled	Stops opening	Canceled	Win-back messages at 30, 60 and 90 days
Long tenure, low usage	Opens monthly	Full price, annual plan	Usage check-in before the renewal date

Day 1, Day 7 and Day 30 activity alone cannot tell low engagement from price sensitivity, an expiring card or a deliberate cancellation. Each needs a different response, and sending a discount to someone whose card simply expired wastes margin.

A card removed before renewal is one of the clearest warning signs. NoChurn gives each new customer a churn score from 0 to 100 at sign-up, based on the payment method, the sign-up source and the custom data you send, and raises it when a card is removed before the renewal date, so you can act before the payment fails.

A caution on small samples: with a modest customer base, attribute comparisons are small-sample observations. Treat a pattern from 40 customers as a hypothesis to test, not proof.

You can push your own attributes, such as sign-up date, sign-up source, seats, usage, onboarding progress or NPS, in one API call, and compare customers who left with those who stayed to see which attributes go with churn (custom data and AI). The revenue view of the same problem is net revenue retention: whether the paying base grows or shrinks after upgrades, downgrades and cancellations.

How do you set your own baseline?

Benchmarks tell you whether you are roughly normal. Only your own cohort-over-cohort trend tells you whether you are improving.

1. Build the baseline from your last three install cohorts. Measure Day 1, Day 7 and Day 30 for each, split by platform and acquisition channel, with the window rule you chose. A flat 20% Day 1 tells you less than a 24% that slid to 17% over two cohorts.
2. Compare with the closest benchmark row, not the global average. If most of your users are on Android in a niche category, the blended figure is the wrong mirror.
3. Add a billing layer if you sell subscriptions. For each cohort, count the Day 30 users who are still paying, those in failed-payment or canceled states, and those who came back through win-back.
4. Give the review a rhythm and a footnote. Monthly cohort reviews work. Next to every figure, write the definition, platform, channel and date range, so the comparison stays honest when someone reads it in six months.
5. Test one change per cohort. Win-back messages at 30, 60 and 90 days after cancellation make a clean single-variable test. One change per cohort window, or you will not know what moved the number.

Before the next review, answer one question: which cohort is losing the most value, and what is the first change you will test on it?

How NoChurn helps

If your retention curve looks fine while revenue drifts, the gap is usually in billing rather than behavior, and that is the layer NoChurn works on. It connects to Stripe in one click and works with Chargebee, Recurly, Paddle, the App Store, Google Play and others, or with any billing through the API. On web billing, it recovers failed payments with smart retries and AI-written emails, runs a cancel flow with offers matched to the reason and the one-click cancel always visible, and sends win-back messages at 30, 60 and 90 days based on the cancellation reason. On the App Store and Google Play, billing retries and the cancel button stay with Apple and Google; NoChurn reads the subscription events and handles scoring and win-back. Pricing depends only on MRR, free up to $300 of MRR and with no commission (a custom sending domain needs a paid plan, from $9).