User Retention Metrics for Indie Builders

Launch day feels good for about six hours.

You push your app. A few people sign up. Stripe pings. Maybe Product Hunt, X, Reddit, or your own tiny audience sends a burst of traffic. Then the next morning you open your dashboard and ask the only question that matters: did any of them come back?

That's where a lot of first-time builders get stuck. They track signups, pageviews, waitlist growth, and maybe trial starts. Those numbers feel useful because they move fast. But they don't tell you whether your product earned a place in someone's routine.

User retention metrics do.

If you're building a solo SaaS, an AI tool, a niche app, or a marketplace, retention is the closest thing you have to a truth serum. It tells you whether users got value once, then wanted that value again. It also tells you what to fix next. If people vanish after first use, your onboarding probably missed. If they come back briefly but never build a habit, your core loop isn't strong enough yet.

That's why retention should sit right next to feedback. Numbers show where users disappear. Conversations show why. If you haven't built that muscle yet, this primer on what user research actually looks like in practice is a useful companion to the metrics side.

## Table of Contents - The Three Core Metrics You Must Track - User retention rate - Churn rate - DAU MAU ratio - Go Deeper with Cohort Analysis - Why averages hide the truth - How to define a useful cohort - How to Read a Cohort Retention Table - Read rows to understand a single cohort - Read columns to compare the same lifecycle moment - Actionable Strategies to Improve Stickiness - Fix the first value moment - Improve return behavior instead of shallow activity - Use feedback loops before building more features - The Indie Builder's Retention Toolkit - A simple stack that works - Weekend experiments worth running

The Three Core Metrics You Must Track

You don't need a giant BI stack to start. You need three numbers you can trust, and you need to define them clearly.

This is the basic question: how many existing users stayed active over a period?

For a lot of indie products, retention rate is the first sanity check after launch. You start with users at the beginning of a period, remove the new users you acquired during that period, and ask how many of the original group remained.

The standard formula is:

Retention Rate = ((Users at end of period - New users acquired during period) / Users at start of period) × 100

If you want a more detailed walkthrough, this guide to the customer retention rate calculation formula is a solid reference.

A simple SQL version looks like this:

WITH period_start AS (
  SELECT COUNT(DISTINCT user_id) AS users_start
  FROM users
  WHERE created_at < DATE '2026-06-01'
),
new_users AS (
  SELECT COUNT(DISTINCT user_id) AS users_new
  FROM users
  WHERE created_at >= DATE '2026-06-01'
    AND created_at < DATE '2026-07-01'
),
period_end AS (
  SELECT COUNT(DISTINCT user_id) AS users_end
  FROM events
  WHERE event_time >= DATE '2026-06-01'
    AND event_time < DATE '2026-07-01'
)
SELECT
  ((users_end - users_new) * 100.0 / users_start) AS retention_rate
FROM period_start, new_users, period_end;

That query is simplified, but the important part isn't the syntax. It's the definition. If “active user” means anyone who logs in once, you'll get one answer. If it means someone who completes your core task, you'll get another.

Practical rule: define “retained” as a user who repeats the action that delivers the product's value, not just any background activity.

A note on dates. The formula works best when your event data and user creation data are clean. If your product has invited users, imported accounts, or shared workspaces, audit those edge cases before trusting the number.

A quick visual explainer helps if you're sharing these metrics with teammates or contractors:

<iframe width="100%" style="aspect-ratio: 16 / 9;" src="https://www.youtube.com/embed/tpCxXmaILWI" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

Churn is retention's negative twin. It tells you who left during the period.

The formula is straightforward:

Churn Rate = (Users lost during period / Users at start of period) × 100

For subscription apps, “lost” often means canceled. For a usage product, it might mean a user who was previously active but no longer performs the key action within your defined window.

Here's a stripped-down SQL example:

WITH start_users AS (
  SELECT DISTINCT user_id
  FROM events
  WHERE event_time >= DATE '2026-05-01'
    AND event_time < DATE '2026-06-01'
),
end_users AS (
  SELECT DISTINCT user_id
  FROM events
  WHERE event_time >= DATE '2026-06-01'
    AND event_time < DATE '2026-07-01'
)
SELECT
  COUNT(*) * 100.0 / (SELECT COUNT(*) FROM start_users) AS churn_rate
FROM start_users s
LEFT JOIN end_users e ON s.user_id = e.user_id
WHERE e.user_id IS NULL;

Churn matters because it forces honesty. Signups can hide a leaky product. Churn exposes the leak.

What works is pairing churn with a reason code when you can. Canceled because of pricing, confusion, weak results, missing feature, or “just testing” are very different problems. What doesn't work is staring at churn as a single percentage and hoping the answer appears.

This one measures stickiness. It asks: of your monthly active users, how many are active on a given day?

Formula:

DAU/MAU Ratio = (DAU / MAU) × 100

SQL example:

WITH dau AS (
  SELECT COUNT(DISTINCT user_id) AS daily_active
  FROM events
  WHERE event_time >= CURRENT_DATE
    AND event_time < CURRENT_DATE + INTERVAL '1 day'
),
mau AS (
  SELECT COUNT(DISTINCT user_id) AS monthly_active
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '30 days'
    AND event_time < CURRENT_DATE + INTERVAL '1 day'
)
SELECT
  daily_active * 100.0 / monthly_active AS dau_mau_ratio
FROM dau, mau;

Product School notes that a DAU/MAU ratio above 20% is considered good for many B2B products. It also gives a concrete example: if a product has 10,000 monthly active users, a 20% DAU/MAU ratio means about 2,000 daily active users, which is commonly treated as a sign of meaningful stickiness.

That doesn't mean every indie app should chase daily use. A billing tool, proposal generator, or investor update app may have healthy retention without daily behavior. The point is to use this metric only if your product naturally fits recurring frequent use.

Averages are comfortable, and they're often useless.

If you blend all users together, you can miss the exact week your onboarding broke, the exact release that improved activation, or the exact acquisition channel bringing in low-intent users.

A cohort is just a group of users who share a starting point. Most builders start with signup week or signup month.

That sounds basic, but it changes how you make decisions. Instead of asking “what's our retention,” you ask “did users who joined after the new onboarding flow retain better than users who joined before it?” That question is actionable.

Pushwoosh explains that the move to cohort analysis was a major shift because teams stopped averaging all users together and started measuring where users dropped off. It also notes that if most users are lost before Day 7, the problem is usually onboarding or initial value delivery, not long-term engagement.

If your retention curve collapses right after first use, don't add more features yet. Fix the first session.

User retention metrics serve as product tools instead of reporting tools. A signup cohort can tell you whether your launch messaging brought in the right people. A cohort based on first completed action can tell you whether users who hit your activation event behave differently from those who don't.

For solo builders, three cohort types usually matter most:

• Signup cohorts help you compare onboarding changes over time.
• Acquisition cohorts show whether users from directories, social posts, communities, or referrals behave differently.
• Behavior cohorts tell you whether users who did a key action, like generating a report, inviting a teammate, or publishing output, are more likely to stick.

A simple retained-users-by-day query might look like this:

WITH signups AS (
  SELECT
    user_id,
    DATE(created_at) AS signup_date
  FROM users
),
activity AS (
  SELECT DISTINCT
    user_id,
    DATE(event_time) AS active_date
  FROM events
)
SELECT
  s.signup_date,
  a.active_date - s.signup_date AS day_number,
  COUNT(DISTINCT a.user_id) AS retained_users
FROM signups s
JOIN activity a ON s.user_id = a.user_id
WHERE a.active_date >= s.signup_date
GROUP BY 1, 2
ORDER BY 1, 2;

That output becomes much more useful when you turn it into Day 1, Day 7, and Day 30 views. But don't stop there. Look at the event stream around the drop-off point. What did retained users do before they came back? What did churned users fail to do?

A few good cohort questions:

| Question | What it helps you decide | |---|---| | Did users from this launch week come back? | Whether your launch audience had real intent | | Did retention improve after the onboarding rewrite? | Whether the change actually helped | | Do users who use the AI feature return more often? | Whether the feature creates value or novelty only | | Do reviewers, builders, or team admins retain differently? | Whether one product loop is stronger than another |

What doesn't work is checking Day 1 once, feeling bad, and moving on. Cohort analysis only becomes useful when you tie it to releases, experiments, and audience segments.

A cohort table looks intimidating until you know what you're looking for. Then it becomes one of the fastest ways to spot product problems.

Start with a simple weekly table.

| Cohort Sign-up Week | Users | Week 0 | Week 1 | Week 2 | Week 3 | Week 4 | |---|---:|---:|---:|---:|---:|---:| | 2026-05-05 | 120 | 100% | 42% | 29% | 24% | 21% | | 2026-05-12 | 140 | 100% | 47% | 31% | 26% | 22% | | 2026-05-19 | 135 | 100% | 33% | 25% | 20% | 18% | | 2026-05-26 | 150 | 100% | 51% | 37% | 29% | 24% |

This is sample data for illustration, not a benchmark. The shape matters more than the exact values.

Reading across a row shows the lifecycle of one cohort over time.

Take the 2026-05-19 row. Users signed up, then retention dropped harder by Week 1 than the surrounding cohorts. That's your clue to inspect what happened during that week. Did you change onboarding copy? Ship a buggy release? Attract low-intent traffic from the wrong post?

Rows are great for matching product changes to user behavior. If you launched a better tutorial in the last week of the month and the next cohort holds up better, that's a useful signal.

A few row-reading prompts:

• Sharp early drop usually points to onboarding friction or weak first-session value.
• Stable early weeks, then decay often means users understood the product but didn't build a habit.
• A flatter curve after a drop can mean you've found a smaller but real core audience.

You want a retention metric that tracks the core value loop. A builder returning after feedback and a reviewer returning weekly are both retained, but not for the same reason.

That's why definition matters so much. Excited Agency notes that retention can change materially based on time frame, what counts as an active user, and how you segment users. It also makes the stronger point that improving raw retention can be the wrong goal if you're measuring weak signals instead of users completing the core value loop.

Reading down a column compares different cohorts at the same point in their lifecycle.

Week 1 is often the most useful early column. If Week 1 retention is much better for the latest cohort, something improved in the early experience. If Week 2 and Week 3 are still weak, your first-run flow got better but your repeat-use loop is still soft.

This is also how you avoid self-deception. A growing product can show decent top-line activity while newer cohorts experience a decline. Column reads catch that early.

Use this quick interpretation grid:

| What you notice | Likely meaning | Next move | |---|---|---| | Latest cohorts improve in Week 1 only | Onboarding improved | Strengthen second-use experience | | All cohorts dip at the same later week | Product habit loop is weak | Add reasons to return | | One cohort performs badly across all weeks | Launch quality or release issue | Review changelog and traffic source | | Retention definition feels too generous | Metric is inflated | Tighten “active” event criteria |

For AI products, this matters even more. A lot of users will try an AI feature once because it's novel. That doesn't mean it solved anything. If retention only counts logins or page views, you can fool yourself into shipping more of the wrong thing.

Retention rarely improves because you added one giant feature. It usually improves because you removed friction from the first value moment, made the product easier to return to, and learned faster from user behavior.

If users bounce early, your job isn't to persuade them harder. Your job is to help them reach value faster.

Cut setup steps. Pre-fill empty states. Show a completed example. If your app creates content, generate a sample output before asking for configuration. If your SaaS needs integration data, fake a safe sandbox experience first so the screen doesn't look dead.

Good onboarding removes waiting. Bad onboarding asks users to do work before they trust the outcome.

Here's a practical shortlist:

• Shorten the path to output by reducing fields, choices, and setup branches.
• Use one primary action on the first screen so users know what to do next.
• Teach in context with tooltips or checklists after action, not before it.
• Instrument the first session so you can see where people stall.

Not every active user is a retained user. Some people linger. Some click around. Some open the app because an email nudged them, then leave.

That's why retention quality matters. Fullstory notes that retention is increasingly a revenue and cohort-quality problem, not just a usage problem. The useful question isn't only whether users remain active. It's whether retained users expand value, adopt meaningful features, and represent the right cohort quality.

For indie builders, that changes roadmap decisions.

If your AI summarizer gets lots of repeat opens but users never save, export, share, or build around the result, then the feature may be entertaining but not durable. If your best-retained users consistently use one narrow workflow, build that workflow out first. Ignore requests from drive-by users until your core loop is stronger.

A few things that usually work:

• Reactivation emails tied to a missed milestone instead of generic “we miss you” messages.
• Saved progress and reminders so users can continue where they left off.
• Feature adoption nudges aimed at the one action strongly correlated with repeat use.
• Clear usage history that reminds users what the product already did for them.

If the numbers say users leave after onboarding, talk to the users who left there. Don't guess from a dashboard.

A small in-app prompt can do a lot of work. Ask what they expected to happen. Ask what felt confusing. Ask what they were trying to complete. If you're building in SwiftUI or shipping a simple mobile flow, this SwiftUI user feedback collection guide is a practical reference for adding that loop cleanly.

You should also connect retention work to conversion work. If users don't understand value quickly, both retention and conversion suffer. This article on conversion rate improvement pairs well with retention fixes because the root cause is often the same: the product isn't making value obvious enough, early enough.

Better retention usually comes from clearer value, not louder messaging.

What doesn't work is stacking announcements, badges, popups, and “new feature” banners onto a weak product loop. That creates motion, not stickiness.

You don't need to buy five tools and hire an analyst. You need a workable loop: instrument behavior, review cohorts, run a small change, then talk to affected users.

For most solo builders, one of these setups is enough:

• PostHog if you want product analytics, event capture, funnels, and feature flags in one place.
• Mixpanel if you care a lot about event-based analysis and user paths.
• SQL plus your own dashboard if you want control and you're comfortable querying a Postgres database.
• Plausible or a basic web analytics tool for top-of-funnel traffic, paired with product events elsewhere.

Your minimum event set should be boring and clear:

| Event | Why it matters | |---|---| | Signed up | cohort start | | Completed onboarding | activation checkpoint | | Used core feature | first value event | | Returned and used core feature again | real retention signal | | Canceled or became inactive | churn investigation |

If you want more ideas on patterns teams use to how to increase app retention, that resource is useful for browsing implementation angles without overcomplicating your setup.

You can learn a lot in two days if the experiment is tight.

1. Rewrite the empty state

Show users an example result, sample project, or prebuilt workspace. Empty screens kill momentum.

1. Add an onboarding checklist

Keep it short. The checklist should point to actions that predict retention, not generic profile completion.

1. Trigger one behavioral email

Send it when a user signs up but never completes the core action, or when they complete it once but don't return.

1. Ask one exit question

When someone abandons onboarding or cancels, ask what blocked them. Keep the prompt optional and short.

The important part is documenting the hypothesis before you ship. “We think users drop after signup because they don't know what good output looks like” is testable. “Retention is bad so let's redesign everything” is not.

The best builders I know pair each metric review with a feedback step. Metrics show the break. Interviews, session reviews, support messages, and short forms explain the break. Then the next sprint gets smaller and smarter.

If you want a better operating rhythm for that habit, this piece on continuous improvement cycles is worth reading alongside your retention dashboard.

---

If you've launched something and your user retention metrics are telling you where people fall off, the next step is getting real humans to tell you why. VibeCodingList is built for that loop. You can submit your app, get targeted feedback on onboarding, UX, and core flows, and use that input to improve the exact moments your retention data says are weak.