App cohort analysis groups your users by a shared starting point, such as the week they installed, and follows each group over time. It shows whether retention, engagement and revenue are getting better or worse for each new group of users. Overall averages can't show you that. To run one, pick a trigger event, pick a time window, build a cohort table, then compare rows and columns. This guide takes you through each step and shows where teams go wrong.
TL;DR
- A cohort is a group of users who share a starting event or trait, usually the install date. You compare groups at the same stage of app use instead of blending everyone into one average.
- Choose the window to fit how often people use the app: daily for the first week, weekly for the first month, monthly for the long-term view.
- Read a cohort table across a row to follow one group's journey, and down a column to compare groups at the same age.
- Use cohorts to judge a release, a campaign or an onboarding change. Check cohort size and outside factors before you credit the change.
- Google Analytics 4, AdMob and most mobile analytics tools offer cohort reports, so you can start without building anything.
Table of Contents
- What app cohort analysis is, and why averages mislead
- Choose how to group your users
- Which metrics to track by cohort
- How to run a cohort analysis, step by step
- How to read a cohort chart
- Worked examples: what cohorts tell you to do
- Common mistakes and limits to keep in mind
- Our view on cohort analysis
- Getting cohort analysis built into your app
- FAQ
- Sources
What app cohort analysis is, and why averages mislead
A cohort is a group of users who installed the app within the same time frame, and cohort analysis compares those groups at similar stages of use. devtodev describes it as a way to avoid blending users at different stages into one average.
Daily and monthly active users (DAU and MAU) are the usual headline figures. They are useful, but they put the whole user base into one bucket. Sensor Tower notes that this hides how well an app generates and keeps its power users, who tend to have the highest lifetime value.
The typical trap is growth masking decline. If new installs keep arriving, total active users can rise while older users quietly disengage. Stripe makes the same point for customer retention: a stable overall rate can hide new customers leaving quickly while older cohorts keep the average afloat. Cohorts let you look inside the average.
Cohort analysis also sits alongside two other methods. Amplitude explains that funnel analysis shows where users drop off and path analysis shows how they navigate. Cohort analysis adds the time dimension. Together they give a fuller picture of behaviour.
Choose how to group your users
Before opening any tool, decide what defines a cohort. There are three common ways to do it.
| Cohort type | Grouped by | Example |
|---|---|---|
| Time (acquisition) | When users installed or signed up | Everyone who installed in the week of 3 March |
| Behaviour | An action they took | Users who completed onboarding, or bought within seven days |
| Attribute | A trait of the user or their source | Users from one country, platform or campaign |
A cohort definition needs two things: the event that starts the clock and the timeframe in which a follow-up action must happen. UXCam's guide gives the example of users who installed in January and made a first purchase within 30 days. You can stack criteria, for instance installed in January and from a specific country.
The tools differ slightly in what they let you choose. Google Analytics 4's cohort exploration can build cohorts from acquisition date, an event, transactions or conversions, with daily, weekly or monthly granularity. AdMob's cohort report places users in a cohort on the day they install and first open the app, which it calls D0.
If you aren't sure which grouping to use, try several. Ian Gow's chapter on cohorts suggests running the analysis with different groupings, without making cohorts so small that patterns disappear.
Pick a time window that suits the app
The right window depends on how often people should use the app. A daily-use app needs daily cohorts. A meal planner or fitness tracker, used less often, will show clearer patterns weekly or monthly.
Amplitude recommends daily cohorts for the first week, when activation happens fast, weekly cohorts for the first month, and monthly cohorts for longer-term retention. For a consumer app expecting daily engagement, it suggests retention windows from day 0 to day 30.
Two practical habits help. Index the install or trigger day as Day 0, so that Day 6 means six days after the trigger. And favour periods that are multiples of seven, because weekly periods cancel out day-of-week effects, as Kyle Giddon's technical write-up explains. Without that, a cohort that installed on a Friday can look worse than one that installed on a Monday for no real reason.
GA4 also offers three calculation types, and it pays to know which one you are looking at:
- Standard counts only the individual period.
- Rolling counts that period plus all previous ones.
- Cumulative counts any period within the exploration.
Which metrics to track by cohort
Retention is where most teams start, but cohorts work for anything you can measure per user over time.
- Retention and churn: the share of a cohort still active at a given age, and the share that has gone.
- Engagement: sessions per user, session length, or how often a key feature is used.
- Conversion: the share of a cohort that completes a first purchase, sign-up or booking, and how long it takes.
- Revenue and lifetime value (LTV): cumulative revenue per user at each age.
Platform reports show what this looks like in practice. AdMob's cohort report gives average per-user data at D1, D3, D7, D14, D28 and D60, including in-app purchase LTV, subscription LTV and a cohort retention rate. Its worked example shows a D3 LTV of £0.013 for one install week.
For subscription apps, the definitions shift. Apphud's documentation explains that a renewal is the next paid period in a subscription chain, not a calendar interval. Its charts show average revenue per paying user and the average number of renewals per user. Branch's documentation covers ARPU, ARPPU, lifetime value, retention, revenue, ROAS and ROI, and notes that cumulative data shows what happened that day plus all previous days.
If you are deciding which of these to put on a dashboard, our guide to mobile app KPIs for product managers, marketers and engineers sets out what each team should watch. For the retention side specifically, customer retention strategies give a useful framework for deciding which levers to pull once the cohort data shows a problem.
How to run a cohort analysis, step by step
- State the question. "Is onboarding keeping more people since the redesign?" is a better start than "how is retention?". The question decides your cohort definition and metric.
- Choose the trigger event. For most apps this is install or first open. For a retailer's app it might be first purchase, if you care about repeat buying.
- Choose the metric and window. Retention at day 1, 7 and 30 is a sound default for consumer apps. Pick weekly or monthly windows if usage is less frequent.
- Split users into cohorts. Use the cohort report in your analytics tool, or export event data and group it yourself.
- Build the table or heatmap. Cohorts go in rows, time since the trigger goes in columns, and each cell holds the metric.
- Compare and look for breaks. Look for the point where a cohort drops, and for rows that behave differently from their neighbours.
- Tie findings to changes. Line up releases, campaigns and seasonal events against the rows that moved, then decide what to test next.
Unity suggests a habit that keeps this lightweight: check the high-level performance and user activity reports first, then open the cohort report to see how monetisation and user-acquisition choices affect retention and LTV. That keeps decisions quick.
How to read a cohort chart
A cohort table has cohorts in rows, such as install weeks, and time since install in columns: week 0, week 1, week 2 and so on. Each cell shows the percentage of the cohort that was active, or the cumulative revenue per user at that age. ASOWin's practical guide puts the reading rule well: reading across a row shows one cohort's journey, while reading down a column compares cohorts at the same age.
Here is an illustrative table. The figures are invented to show the reading method and are not benchmarks.
| Install week | Week 0 | Week 1 | Week 2 | Week 4 |
|---|---|---|---|---|
| 3 March | 100% | 28% | 19% | 12% |
| 10 March | 100% | 27% | 18% | 11% |
| 17 March (new onboarding) | 100% | 36% | 26% | 18% |
| 24 March | 100% | 35% | 25% | 17% |
Read across the 3 March row and you see the usual decay. Read down the Week 1 column and you see a jump from 27% to 36% for the cohort that got the new onboarding, which then holds in the next cohort. That is a pattern a blended retention figure would have smoothed away.
Unity's guide adds that day 0 always shows 100% retention, and that shading on heatmaps makes anomalies easy to spot. A dark cell in a column of light ones deserves a question.
Where the curve usually breaks
Most retention curves have three zones, and each points to a different kind of problem:
- Day 0 to day 1: the activation gap. A big loss here usually means onboarding or first-run experience needs work.
- Day 1 to day 7: the habit-forming stretch. Users who find no reason to return fall away.
- Day 7 to day 30: the long tail, which depends on depth of value and re-engagement.
If the first drop is your problem, our user onboarding workflow guide covers how product teams structure the first session. For context on what healthy numbers look like, see our app retention benchmarks.
Worked examples: what cohorts tell you to do
Judging an update without an A/B test
Suppose you redesign a checkout flow. Total revenue will not tell you whether it worked, because new users keep arriving and distort the trend. Average revenue per user is also unreliable because users sit at different stages. VentureBeat's article on cohort analysis makes this argument: cohorts isolate whether the update improved the purchase process.
devtodev gives a concrete case. After an in-game store redesign, the cohort that arrived afterwards showed higher purchase conversion and ARPU than the cohort before, which pointed to a successful change. This is helpful when running a formal A/B test is not practical.
Checking whether paid acquisition pays back
Advertising platforms charge for installs, not for the actions you care about. So the useful question is how much revenue a group of installs generates over time. Adapty's worked example shows a January cohort that brought $2,900 in revenue from 73 subscribers, with subscriber numbers falling from 67 in January to 38 in February and 10 in June. In its $4,000 advertising scenario, subscribers had to pay over $1,500 just for the cohort to recoup the spend. Even with zero cancellations, payback would take at best four to five months.
The lesson applies to any app with paid acquisition: judge a campaign by what its cohort does over months, not by the install count in week one. Our piece on effective mobile app marketing covers the acquisition side.
Finding the feature that keeps people
Behaviour cohorts answer a different question. Compare users who used a particular feature in their first week with those who did not, and check their week-four retention. If the first group stays far longer, that feature is worth surfacing earlier in onboarding. Treat this as a lead to test, not proof of cause, as the next section explains.
Common mistakes and limits to keep in mind
Cohort analysis is powerful, and it rewards care. These are the mistakes we see most often:
- Survivorship bias. If your data does not cover each cohort's whole life span, only users who stayed are in the set, and older cohorts look better than newer ones. Ian Gow's chapter explains the effect.
- Tiny cohorts. Percentages from a handful of users swing wildly. Make sure each cohort is large enough before you act on a difference.
- Ignoring context. Seasonal peaks, a holiday sale or a press mention can lift one cohort for reasons unrelated to your product changes.
- Crediting a feature without a comparison. A retention lift after a launch needs a comparable cohort that did not get the feature before you call it a win.
- Looking at retention alone. A cohort can retain well and still use few features or be unhappy. Pair retention with engagement and conversion.
- Early adopters differ. In consumer services, early adopters are often more enthusiastic and retain differently from later users, so the first cohorts may not predict the rest.
Platform data has limits too. Store-side reports often aggregate data to protect user privacy, which can suppress small cohorts and rule out row-level exports. They are a good first read. Questions about cause usually need your own analytics pipeline with event-level data.
Our view on cohort analysis
We have built more than 300 apps, and the same thing happens at almost every analytics review. A team shows us a healthy-looking active-user line, and the cohort table underneath tells a different story.
Our advice is to plan for cohort analysis before the first line of code. Decide which events mark activation, name them consistently and make sure they are tracked from the first release. Retrofitting that after launch means your earliest and most interesting cohorts are lost.
Start with one question per review, not a wall of charts. Did the last release help day-7 retention? Did the new campaign bring users who stay? A single clear answer is worth more than twenty heatmaps.
Finally, treat cohort findings as input to design, not a verdict. When a column drops, go back to the screens and the user flow behind it. That is why we run discovery, design, development and deployment as one connected process, with analytics and post-launch support built in.
Paul
Getting cohort analysis built into your app
Cohort reports are only as good as the events your app sends. If you are planning a new app, or you have one whose tracking has gaps, we can help. Our discover, design, develop and deploy process includes strategic discovery, where we agree the events and KPIs worth measuring, and ongoing analytics and maintenance after launch.
If your app is already live and you want an expert review of its analytics, retention or user experience, our Mobile App Clinics are a good place to start. For a wider look at the tools and methods, read our practical strategies for mobile app analytics, or get in touch about your project.
FAQ
What is the difference between cohort analysis and retention analysis?
Retention analysis measures how many users come back. Cohort analysis is the method that splits users into groups so you can compare that retention across them. Retention is one metric you can examine by cohort, alongside revenue, engagement and conversion.
How big should a cohort be?
There is no universal number, but small groups produce unstable percentages. One practitioner suggests a minimum of 30 users per cohort as a floor. In practice, larger cohorts give more reliable comparisons. If yours are small, widen the window from daily to weekly.
Can I do cohort analysis for free?
Yes. Google Analytics 4 includes a cohort exploration, and AdMob has a cohort report for apps that show ads. Both give you retention and, in AdMob's case, lifetime value by install day. Your app must send the right events for the reports to be useful.
How often should I review cohort reports?
Match the review to how fast your app changes. Teams that ship often or run paid acquisition benefit from a short regular check, while slower-moving apps can review weekly or monthly. Always review after a release or campaign, once the new cohort has aged enough to compare.
Sources
- devtodev: App Cohort Analysis
- Sensor Tower: Power user curve
- Stripe: Cohort analysis for businesses
- Amplitude: The Complete Guide to Cohort Analysis
- UXCam: How to do cohort analysis
- Google Analytics Help: Cohort exploration
- Google AdMob Help: About the Cohort report
- Ian Gow: Cohorts
- Kyle Giddon: Technical construction of cohort retention metrics
- Apphud: Subscribers Retention
- Branch: Cohort analytics
- Unity: Analyzing cohort reports
- ASOWin: Cohort analysis for mobile apps
- VentureBeat: Why cohort analysis is a game-changer
- Adapty: Cohort analysis for mobile apps