TL;DR
- 77% of users who install your app stop using it within 72 hours. Most of that churn happens inside the first session.
- 2026 cross-industry medians: Day-1 = 26%, Day-7 = 11%, Day-30 = 5.4%. Subscription apps retain ~2.5x better at D30.
- The five real churn causes: no "aha moment", ad/product mismatch, no external trigger, crashes/slow loads, and one-and-done intent (which is fine).
- The uncomfortable part: you probably already know the tactics. The real bottleneck is that your experiment cycle takes 3 weeks while your cohort churns in 3 days.
- Fix the cycle time, not the tactics list.
The number
77% of the users who install your app stop using it within 72 hours. Not a month. Not a week. Three days.
That stat traces back to Andrew Chen's analysis at a16z, and every benchmark report since (Adjust, AppsFlyer, Sensor Tower) lands in the same neighborhood. The 2026 numbers, by vertical:
| Vertical | Day 1 | Day 7 | Day 30 |
|---|---|---|---|
| Social & Communication | 30% | 15% | 8% |
| Gaming (Casual) | 27% | 10% | 4% |
| Finance & Fintech | 33% | 18% | 12% |
| Health & Fitness | 24% | 10% | 6% |
| E-commerce & Retail | 22% | 8% | 4% |
| Productivity | 29% | 14% | 10% |
| Subscription Apps (all) | 35% | 22% | 14% |
| Cross-category median | 26% | 11% | 5.4% |
Two things worth noticing: subscription apps retain 2.5x better at Day 30 (paywalls are a commitment device), and fintech beats casual gaming 3x at D30 (utility beats entertainment on retention, almost always).
Make sure you're measuring the same thing as the benchmarks
Retention has three variants, and teams routinely fool themselves by measuring one internally and comparing against another:
- Classic — user came back on exactly day N. Punitive, but it's what the benchmarks above use.
- Rolling — user came back on day N or later. More forgiving.
- Bracket — user came back anywhere in days N–M. Useful for weekly cohorts.
If you want to sanity-check your own numbers, classic Day-N retention is one query away:
-- Classic Day-N retention per install cohort
WITH installs AS (
SELECT user_id, DATE(install_time) AS cohort_day
FROM app_installs
),
activity AS (
SELECT DISTINCT user_id, DATE(event_time) AS active_day
FROM app_events
)
SELECT
i.cohort_day,
COUNT(DISTINCT i.user_id) AS cohort_size,
COUNT(DISTINCT CASE WHEN a.active_day = i.cohort_day + INTERVAL '1 day'
THEN i.user_id END) * 100.0 / COUNT(DISTINCT i.user_id) AS d1_retention,
COUNT(DISTINCT CASE WHEN a.active_day = i.cohort_day + INTERVAL '7 day'
THEN i.user_id END) * 100.0 / COUNT(DISTINCT i.user_id) AS d7_retention
FROM installs i
LEFT JOIN activity a USING (user_id)
GROUP BY 1
ORDER BY 1;
Segment this by acquisition channel before you conclude anything. A cohort with 15% D7 overall might be 30% from organic and 4% from one bad Facebook creative. That's not a retention problem — that's an ad-relevance problem wearing a retention costume.
Where the 77% actually dies: the first session
The churn isn't spread evenly across 72 hours. Roughly 60–70% of it happens inside the first session. Users don't drift away over three opens — they open once, hit friction, close, never return.
The consistent offenders, with rough measured costs:
- Signup wall before showing value: –30-40% of installers on that screen alone
- Phone verification: another –15-20%
- Push permission prompt on Day 0 (before any value): ~4x lower opt-in vs. asking after value
- More than five onboarding screens: ~20% more churn vs. three or fewer
The cheapest fix in mobile is deferring everything. Guest mode instead of a signup wall:
// Instead of gating the app behind auth, persist a local guest identity
import AsyncStorage from '@react-native-async-storage/async-storage';
import { v4 as uuid } from 'uuid';
export async function getOrCreateGuestId() {
let id = await AsyncStorage.getItem('guest_id');
if (!id) {
id = `guest_${uuid()}`;
await AsyncStorage.setItem('guest_id', id);
}
return id;
}
// Later, when the user actually signs up, merge the guest state
export async function upgradeGuestToUser(userId) {
const guestId = await AsyncStorage.getItem('guest_id');
if (guestId) {
await api.mergeAccounts({ from: guestId, to: userId });
await AsyncStorage.removeItem('guest_id');
}
}
Same logic for push permissions — ask after the user has experienced value, not on launch:
// Don't request on app open. Trigger contextually, e.g. after first "aha" action
async function requestPushAfterValue(trigger) {
const alreadyAsked = await AsyncStorage.getItem('push_prompted');
if (alreadyAsked) return;
if (trigger === 'first_workout_completed') {
// Pre-permission soft prompt first — protects your one real OS prompt
const wants = await showSoftPrompt(
"Want a reminder before your streak breaks?"
);
if (wants) {
await requestNotificationPermission();
}
await AsyncStorage.setItem('push_prompted', 'true');
}
}
The five real reasons users churn
Skip the twenty-tactic listicles. Churn comes from a small set of root causes:
- They never hit the "aha moment." Duolingo: first lesson done. Instagram: first personalized feed. Fintech: first balance after bank link. Users who reach it retain at 3-5x the rate of users who don't. Your entire first session should be a speedrun to that moment.
- The ad promised something the app isn't. Invisible in aggregate, obvious when you segment by channel (see the SQL above).
- No external trigger. Apps that survive past D7 almost always reach out — a push tied to a real event (someone messaged you, your streak's about to break), not "hi, we miss you." Apps that rely on being remembered lose to apps that reach out.
- Crashes and slow screens. Users don't file bug reports; they uninstall. And crashes disproportionately hit your heaviest users, because they hit more code paths.
- They got what they came for. One-time intent (check a flight, convert a currency once) isn't a retention failure. Segment churn by intent before you panic.
The part nobody writes: your bottleneck is cycle time, not tactics
Here's the uncomfortable truth: you already knew most of the above. Everyone's read the same posts. Everyone has the Notion doc of retention experiments. So why is the median D30 still 5.4%?
Because most teams can't ship a retention experiment in under three weeks.
Week 1: spec + Figma + design review. Week 2: implementation + new tracking event + QA. Week 3: ship to 20%, wait for the cohort to season, analyze. By the time you know whether the shorter signup form moved D1, the cohort you wanted to save has been gone for two and a half weeks. You're permanently fighting the last war — with eighteen more experiments queued behind this one.
Duolingo runs hundreds of A/B tests a year. Netflix ships micro-experiments continuously. The gap isn't ideas — it's that they ship an experiment in a day and you ship one a month.
This is where tooling actually changed the math. Building in an AI-native stack like RapidNative means the guest-mode experiment above is a prompt — "make signup optional, add continue-as-guest, persist state locally" — with a working build on a real device via QR code in under a minute, instead of a sprint. When iteration cost collapses that far, the strategy flips: you stop hoarding experiments and start running them in parallel.
A weekly experiment cadence that actually compounds
If your iteration cost is low enough, this rhythm works:
- Monday AM — pull last week's cohorts, segmented by channel and onboarding variant. Find the biggest first-session drop-off.
- Monday PM — one hypothesis, one line: "changing X to Y improves D1 by Z% for cohort A."
- Tuesday — build the variant.
- Wednesday — ship to 50% of new installs.
- Next Monday — cohort's seasoned. Ship the winner or kill it. Next experiment.
That's ~5 experiments a month, 60 a year. Even at a 1-in-5 hit rate you're compounding at a pace nobody on a three-week cycle can touch.
The bottom line
Retention in 2026 isn't a knowledge problem. The benchmarks are public and every founder can recite why users churn. The teams that win are the ones shipping retention experiments faster than their cohorts churn.
Stop asking "which tactic should we prioritize?" Start asking "what's the smallest experiment we can put in front of real users this week?"
What's your team's actual experiment cycle time — days or weeks? And what's the one onboarding change you've been meaning to test forever? Drop it in the comments, I'm curious what's stuck in everyone's backlog. 👇
Top comments (0)