DAU, MAU, and Cohort Retention Explained for App Devs

The three metrics most indie devs misread when they look at their own analytics: DAU, MAU, and cohort retention.

They sound simple. They're not — at least not the version that drives real decisions. This is the glossary post that lays them out plainly, plus the calculation traps that cost months when you get them wrong.

DAU — Daily Active Users

The number of unique users who opened your app today.

What's hidden in "unique" and "opened":

• Unique: by device ID, user ID, or anonymous ID? Pick one, document it.
• Opened: any session, or only sessions with meaningful action? Both definitions are valid — but compare apples to apples week-over-week.

What "active" means varies by category:

• Social apps: opened.
• Game apps: started a level.
• Productivity apps: created/edited something.
• Subscription apps: completed a session worth tracking.

Define it once. Don't change the definition midway through a quarter.

MAU — Monthly Active Users

The number of unique users who opened your app in the last 30 days (rolling) or in the calendar month.

Trap: MAU is not 30 × DAU. They're independent counts of unique users over different windows.

If your DAU is 1,000 and your MAU is 30,000, that doesn't mean you have 30 different cohorts of 1,000 users — it means your daily user pool has high turnover. Some apps have MAU = 5× DAU. Others have MAU = 30× DAU. Both are different products, neither is wrong by itself.

Stickiness ratio (DAU/MAU)

Stickiness = DAU / MAU

This single ratio tells you how "habit-forming" your app is:

Higher isn't always better — a tax-prep app has 5% stickiness and that's fine. A meditation app at 5% stickiness is broken.

Benchmark against your category, not the social-app averages.

Cohort retention

Cohort retention is the % of users from a specific signup cohort who are still active N days later.

Day 1 retention   = % of installers who opened day 1 (next day)
Day 7 retention   = % still opening at day 7
Day 30 retention  = % still opening at day 30
Day 90 retention  = % still opening at day 90

Industry benchmarks (2026, varies wildly by category):

If your D30 is at the floor, you have a retention problem — paid acquisition won't fix it.

The cohort retention curve

Plot retention over time. The shape matters more than any single number.

Two patterns to recognize:

Pattern A: "Pancake" (good)

D1: 45%
D7: 30%
D14: 27%
D30: 25%
D60: 24%
D90: 24%

Steep early drop, then flatline. This is what you want — you have a stable "core" of retained users.

Pattern B: "Slide" (bad)

D1: 50%
D7: 25%
D14: 15%
D30: 8%
D60: 4%
D90: 2%

Continuous decay. Users are bleeding off at every interval. No stable core. You'll need very cheap acquisition to make this work.

The cohort curve tells you whether your product is "compounding" (stable core) or "churning."

Calculation traps

Trap 1: Mixing cohorts

If you average D7 retention across all cohorts (new and old), you'll get a number that looks fine while every new cohort is getting worse.

Fix: track each cohort separately. Plot multiple cohorts on the same axis.

Trap 2: Sample size

A new cohort with 50 installs has noisy retention numbers. D7 jumps from 20% to 40% based on 5 users.

Fix: don't trust cohort retention until cohort size is ≥500 (for stable percentages).

Trap 3: "Active" definition drift

If your team changes the SDK event that defines "active" mid-quarter, you'll see a spike that's an artifact. Compare with the old definition for 2 quarters before drawing conclusions.

Trap 4: Survivorship bias in cohort retention

D90 retention only includes installers from 90+ days ago. If your product changed materially since then, the D90 number reflects an old product.

Fix: report D90 retention with the cohort age — "D90 for the Feb 2026 cohort" not "D90 retention."

Trap 5: Counting paid users only

If you're a subscription app and you measure "retention" of paid users, you're getting a flattering subset. Always measure both:

• Install retention (unbiased — your acquisition quality + product fit)
• Paid retention (your monetization fit, given product fit)

Different numbers, different decisions.

How to use these for real decisions

Decision 1: "Should I scale paid acquisition?"

Look at D30+ retention of paid cohorts. If it's at or above your category median, scale. If it's below, fix retention before scaling — you'll just bleed money.

Decision 2: "Should I A/B test onboarding?"

D1 and D3 retention are most sensitive to onboarding. If your D1 is below category median, onboarding is broken. If D1 is fine but D7 drops sharply, the issue is first-week activation (the "aha moment" isn't landing).

Decision 3: "Is my paywall too aggressive?"

Compare D7 retention of users who saw the paywall vs users who didn't (or saw a softer version). If paywall-seeing users churn dramatically more, your paywall is poorly placed.

See soft vs hard paywall conversion data.

Decision 4: "What's my LTV?"

Cohort retention is the input to LTV calculation. See LTV for subscription apps.

Tools

Most subscription analytics tools (RevenueCat, Apphud, Adapty, Mixpanel, Amplitude) calculate these automatically. The free tier of most of them covers indie scale.

If you're cohort-tracking manually:

• Daily install timestamp per user.
• Daily active session timestamp per user.
• Cohort group by install day, plot retention curve.

A spreadsheet does this fine for small datasets (<10k installs/month).

Related reading

• LTV Calculation for Subscription Apps
• ROAS Explained for Mobile Apps
• Measuring True ROAS for Subscription Apps
• Mobile Ad Metrics Guide
• Mobile App Monetization Guide 2026

Try the tools

• Ad Analytics Calculator
• Ad Benchmark Analyzer — see where your CPI/ROAS sits.