# User Retention Strategies: Choose the Next Test

> Define repeated value, investigate the gap, and design a retention test with a reason to stop.

- Author: Rishikesh Ranjan · Published: Sep 6, 2026
- Type: Playbook
- Tags: Retention, Onboarding, User Behaviour
- Growth levers: Retention (primary), also Activation
- ~2742 words

---

Suppose you're responsible for a weekly planning product. An owner publishes a plan, teammates add updates, and the owner never publishes another one. A reminder, rebuilt onboarding or a streak could all go on the list. But did the owner forget, find the process exhausting, move the meeting elsewhere, or simply finish the project? You don't yet know.

The starting move proposed in this playbook is to **define the useful action** you want people to repeat, check where the relevant group stops, then test a change suited to that gap. Give the event and interval as much attention as the user retention strategy itself.

Those answers would call for different work. Before choosing a user retention strategy, leave room for an explanation that doesn't require another feature.

- Choose the action and interval before interpreting the rate.
- Compare groups at the same age, then investigate the difference.
- Treat a proposed fix as a hypothesis, with a later outcome and a reason to stop.

## Define user retention around the job

In the planning example, **publishing a usable weekly plan** is a candidate event. Creating a workspace is easier to record, but it doesn't tell you whether a plan exists. Even publication needs a closer look: did teammates use the plan, or did the owner publish an empty template to finish setup? Choose the proxy, then check where it could mislead you.

And why weekly? That's an assumption about this example's job, not a benchmark to copy. Ask when the next plan is needed and compare that answer with the actual time between useful sessions. Keep separate views for roles or jobs that recur differently. An occasional project planner shouldn't automatically inherit the weekly team's definition of success.

That event-and-interval choice is the starting point in Amplitude's retention method. It asks teams to choose a [critical event and product usage interval](https://amplitude.com/books/mastering-retention/your-critical-event-and-product-usage-interval?utm_source=productgrowth.blog): the action representing the product's core value, and the window in which it's expected to recur. It's a practitioner's measurement method, with no promise that using it will improve retention. What are you counting, and why that often?

Here, user retention means a person repeating the chosen action within the chosen interval. That's a usage measure. Mixpanel [distinguishes usage retention from payment retention](https://mixpanel.com/blog/retention-analytics-primer/?utm_source=productgrowth.blog), which matters when you choose the unit. Imagine a paying account with several inactive seats: the account and those individual users would tell different stories. If you're deciding what to do about renewal, start with the [customer retention strategies playbook](https://www.productgrowth.blog/p/customer-retention-strategies) instead.

The job might also be over. Mixpanel's [healthy-completion counter-case](https://mixpanel.com/blog/retention-analytics-primer/?utm_source=productgrowth.blog), attributed to a product manager at ZipRecruiter, describes transactional use that can end because the service did its job. That gives you a question to ask, not grounds to declare your departed users satisfied. As a separate, hypothetical illustration, think of a job seeker who's accepted an offer: another application session might be the wrong outcome.

> **Steal this:** Write a provisional definition: A user is retained when they \[chosen useful action] within \[interval]. Beside it, name one successful user this definition might wrongly label as lost.

## Diagnose the cohort before selecting a strategy

Start with a group you can follow: owners who published their first plan in the same week, for example. That's your cohort. Mixpanel's [guide to reading a cohort table](https://mixpanel.com/blog/cohort-analysis/?utm_source=productgrowth.blog) describes two views: across a row follows one group as it ages; down a column compares groups at the same age. Compare a second-week result with another second-week result, not with a group that has barely started.

Before explaining a gap, check that it's real in the records. Inspect a few underlying events, confirm stable user identities, and check whether a renamed event broke the comparison. **Repair unreliable tracking** before treating the curve as a product verdict. Then start with the suspected gap and a few plausible explanations, rather than splitting the data into every available dimension at once.

**Same age doesn't settle the comparison.** Perhaps the newer cohort came from a different campaign, used a different product version, or contains more experienced planners. Check which of those conditions changed before calling the release a success. The groups still need to be otherwise comparable.

Now suppose owners who invite teammates also return more often. Does the invitation explain it, or does it identify an already committed team? Heap's [retention-flow correlation caveat](https://www.heap.io/blog/saas-user-retention-flows?utm_source=productgrowth.blog) explicitly warns against treating an associated behavior as its cause. Keep the invitation as a candidate explanation. On that evidence alone, you don't have a reason to make it a mandatory setup step.

Use these proposed questions to investigate the gap. The rows don't rank proven fixes or tell you which change your product needs.

| Observed gap | Question to investigate | Possible test |
| --- | --- | --- |
| No completed value event | Is setup blocked, or did the promise attract the wrong job? | Change one obstructive step after verifying the actual blocker |
| Value once, then no repeat | Is there another job to do? Is the next step clear? | Expose one useful next action to an eligible group |
| Use fades over later intervals | Did the job, team or required output change? | Test a revised workflow for the affected segment |
| A return without another useful visit | Was the comeback useful or merely interesting? | Route the return to a specific unfinished or newly available task |
| One role drops while another continues | Do the roles need different actions or intervals? | Separate the definitions before changing either experience |
*Author-proposed diagnostic questions and possible tests, not observed intervention effects.*

### Use interviews to widen the explanation

You could start with **five conversations** across continued use, stalled use and apparently successful departures. Five is a manageable first batch, not a research-derived sample size: it can't tell you how common an explanation is or establish why an intervention will work. Expand the batch if a relevant role is missing or the accounts conflict.

Ask someone to walk through the last occasion they needed the product. What were they trying to finish? What happened next? What did they use instead, if anything? Compare their account with the event record, without treating either as a complete explanation. Avoid asking whether they'd like the feature you've already decided to build.

Difficulty reusing the previous plan is only one possible answer. If the interviews instead suggest the weekly meeting was cancelled and no new plan is needed, a roll-forward feature would address a different problem. Better to find that out before shipping.

## Connect user activation to the next useful session

Call the first usable published plan activation in this fictional product. That's a working definition for the example, not a claim that every product has one universal activation event. But a first plan leaves the next question open: does the owner have another planning job, and can they do it without starting from scratch?

Map the path to that first plan. Which steps are required for the result or for safety? Which are optional setup, and which have a purpose you can't explain? Pick a suspected obstruction to investigate without promising to remove a fixed number of clicks. If teammates or imported data are genuinely required, you might need to explain that requirement better rather than remove it.

Then look at where the session ends. What state is saved, what will be waiting when planning is due again, and what does the owner have to remember? You could try a visible roll-forward action that carries selected unfinished items into a new draft. Keep a blank-plan option too; yesterday's work might no longer belong.

The hypothesis: eligible owners who can see that action may publish the next plan more often because they have less setup to repeat. That's **plausible, but untested**. Before building it, check whether the feature already exists, whether owners can find it, and whether repeated setup is actually the problem they describe.

> **Steal this:** Put the next useful session in the activation brief. Name what the user will need then, what the product will preserve, and what evidence would make you abandon the proposed connection.

## Treat return cues and accrued value as test inputs

The roll-forward action leaves both saved work and a cue to return worth examining. A proposed operating model brings them together with the earlier questions: clear promise, first value, repeated value, a useful return cue, and accrued value. By accrued value, I mean prior work that could be worth using again, such as an editable plan or useful history. These are questions to inspect, not five scientifically established causes of retention.

![Five-part proposed retention review: clear promise, first value, repeated value, useful return cue, and accrued value.](https://www.productgrowth.blog/media/posts/user-retention-strategies/01-retention-loop.webp)
*A proposed operating model, not a measured causal diagram. Use the five parts as questions when reviewing a recurring product job.*

Read the loop against the planning example. Was the promise a usable weekly plan, and did the owner get one? Is another plan needed? Would a chosen cue be welcome when that job returns? Is any earlier work worth carrying forward? The arrows show the proposed review sequence, without proving that improving one part changes the next.

Would a consistent cue help? A [2022 context-stability paper](https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2022.883795/full?utm_source=productgrowth.blog) offers adjacent evidence: it studied 95 university students over six weeks and separately analyzed 218 iPhone habit-app users' records collected from September 2018 to February 2021. Reported context stability was associated with automaticity and self-reported completion of each habit repetition's goal. But the student study's assigned stable-versus-variable groups did not differ significantly on either outcome. The studies used self-reports from people intentionally building habits, and the app was developed by the first author. Neither was a SaaS retention experiment.

That leaves a consistent cue as something to test in the planning product, with no research-backed promise that it'll work. Ask whether the owner wants a cue near their chosen planning session. If a cancelled meeting or completed project means **another plan is no longer needed**, suppress its cue. A calendar slot doesn't prove the underlying job still exists.

Saved work needs its own test. Let the owner review which unfinished items carry forward and discard stale ones. Watch for correction work, duplicate plans and unwanted reminders of old tasks. If reusing the saved state takes more cleanup than starting fresh, revise or remove it. Keeping the information doesn't settle whether it's useful.

### What the Duolingo example does and doesn't show

What about showing continuity through streaks? Duolingo's [Q4/FY 2024 shareholder letter](https://investors.duolingo.com/static-files/d0adccff-bfe0-4d10-a5bc-f116d746afd2?utm_source=productgrowth.blog), published February 27, 2025, reported a Q4 daily-active-to-monthly-active user ratio of 34.7%. It also said over 10 million users had streaks of a year or longer and one-third of daily active users had a Friend Streak. Those last two statements describe the letter's current figures, without giving exact snapshot dates.

| Metric | Value |
| --- | --- |
| DAU / MAU | 34.7% — Q4 2024; company-reported |
| Year-long streak users | >10M — Stated in February 2025 letter |
| DAUs with a Friend Streak | One-third — Stated in February 2025 letter |

The company says its operating metrics weren't independently validated. And seeing engagement and streak participation together **doesn't isolate a streak's effect**. For the planning product, the figures leave you with a design question about showing continuity; they don't justify importing a daily streak into a weekly job.

## Use behavior-triggered messaging with an exit condition

Before sending a behavior-triggered message, try this narrower eligibility question: is there **something useful for this person to do now**, and have they agreed to this channel? If you're unsure, investigate before sending. An unfinished draft or fresh teammate input could give a planning prompt a purpose, provided it still matters to the owner's current job.

Apple's [notification design guidance](https://developer.apple.com/design/human-interface-guidelines/notifications/?utm_source=productgrowth.blog) puts some constraints on that choice: timely, high-value information and user consent. It discourages repeated notifications for the same thing and messages that merely tell someone to perform an in-app task. Treat that as platform guidance. It doesn't establish that a particular message will raise retention.

You can use lifecycle labels to organize that investigation. [Amplitude's lifecycle taxonomy](https://www.amplitude.com/books/mastering-retention/the-retention-lifecycle-framework?utm_source=productgrowth.blog) defines a new user as being in their first usage interval; a current user was active in the previous and current intervals. A resurrected user is active now, was inactive in the previous interval, and had been active before that. A dormant user was active in the previous interval but is inactive in the current one.

The label still doesn't tell you why someone stopped. Try examining a new owner's blocked setup separately from a returning owner's unfinished plan. Check a dormant owner's reason for leaving before composing a comeback offer. The same reminder won't necessarily fit each state, and inactivity alone doesn't establish dissatisfaction or permission to contact someone.

- **Define eligibility:** name the relevant product state, recipient and permitted channel.
- **Write the value payload:** say what changed or what can be completed, not just that the app misses them.
- **Suppress on completion:** cancel the cue if the task is done or no longer relevant.
- **Set the exit:** honor opt-outs, investigate wrong-state delivery and stop when a predeclared quality limit is breached.

Once the message goes out, treat recorded opens as a **limited channel signal** after checking how they're tracked. They don't answer the retention question. For the planning hypothesis, you're looking for another useful published plan within the chosen interval; a recorded open without that later job completion leaves the question unanswered.

## A proposed 30-day user retention sprint

You could budget a 30-day sprint for this investigation. It's a **proposed planning boundary**; it doesn't establish that a team can ship or measure a retention improvement in that time. Extend it if tracking, engineering work or the product's cadence needs longer. A monthly product may reach the end of the calendar with its outcome still unobserved.

1. **Days 1 to 5:** draft the retained-user definition, inspect tracking and choose the interval. Record a baseline only after checking what the underlying events represent.
2. **Days 6 to 10:** investigate one gap using relevant cohort comparisons and an initial interview batch. Write competing explanations, including successful completion or changed need.
3. **Days 11 to 20:** specify and, if feasible, build one controlled change. Agree eligibility, outcome window, guardrails and analysis rules before reading results.
4. **Days 21 to 30:** inspect assignment, exposure and data quality. Read mature outcomes only. Continue observation, repair the test or report it inconclusive when the planned comparison is not available.

### Write the experiment brief before the result

Suppose the investigation points to difficulty starting the next plan for the fictional owner, who published a plan and received teammate input. The team decides to test a roll-forward prompt. Use that scenario for the brief below; it isn't an interview finding or an experiment that actually happened.

- **Eligible users:** new owners who published a plan and received at least one teammate update, with another planning cycle due.
- **One change:** show an in-product roll-forward prompt. Do not add a reminder in the same test if the question concerns the prompt.
- **Assignment:** consider randomizing by workspace so owners sharing a workspace do not receive conflicting experiences. Keep the reported retention unit as eligible owners.
- **Early action:** an eligible owner starts a rolled-forward draft.
- **Later outcome:** an eligible owner publishes the next usable plan in the second weekly interval.
- **Quality checks:** abandoned duplicate plans, unwanted carried-forward items and reports of confusing state.

Before launch, ask the analyst to specify the required sample, observation window and how uncertainty will be reported for the actual traffic. This playbook has no sample-size shortcut. Record who enters the denominator, what happens when an owner changes workspaces, and when a cohort has had enough time to reach the outcome.

More roll-forward starts with an unclear publication result would leave the hypothesis open. An improvement in the later result under the agreed analysis still needs its quality check: if correction work breaches the limit, investigate or stop instead of accepting the trade-off by default. And **if neither group has matured, wait**. The sprint's end date isn't an outcome.

## Keep user retention metrics tied to the decision

For this test, try a small scorecard: an early action, a later repeated-value outcome and a quality check. Tailor it to the decision; it isn't a standard set of retention metrics every product needs. Add a measure when it could change what you do, not because it appears on another dashboard.

| Proposed measure | Decision it informs | Limit to check |
| --- | --- | --- |
| First usable-plan publication | Whether eligible owners reached the candidate activation event | Publication may still be a weak proxy for actual usefulness |
| Roll-forward draft starts | Whether the tested action was used | A start is not the later retained-use outcome |
| Second-week usable-plan publication | Whether eligible owners repeated the chosen action | Compare mature groups and retain uncertainty |
| Duplicate or unwanted carried-forward work | Whether the change creates unacceptable correction work | Choose a product-specific limit before reading results |
*Illustrative scorecard for the proposed planning-product experiment, not reported results.*

Keep the unit beside the rate. An owner-level outcome shouldn't quietly become workspace retention when you report the result. Preserve the original eligibility and interval definitions, recording any changes needed to repair tracking. If a repair changes who counts, **rebuild a comparable baseline** before judging the intervention.

## Questions before running the test

#### What if the cohort is too small for a useful experiment?

Treat the result as uncertain rather than using a five-person interview batch to estimate lift. Use conversations to refine the problem, repair obvious tracking issues, and agree a longer observation window or a different decision approach with your analyst.

#### Can the sprint end before the retention window closes?

Yes. Close the delivery work if appropriate, but leave the outcome open. State which groups have matured and when the planned comparison becomes available. Do not shorten the user interval to produce a result by Day 30.

#### Should a successful departure count as churn?

Keep it visible as a separate interpretation until you have checked what happened. The measurement can record inactivity while the product decision recognizes a completed job. Define a legitimate future re-entry event instead of assuming another session is needed.

You don't need to build this whole test to take the next step. **Choose the cohort and check its baseline counts.** Once those are trustworthy, decide whether another analysis, another conversation or a product change is worth doing next. The [retention-rate calculator](https://productgrowth.blog/calculators/retention-rate?utm_source=productgrowth.blog) can check the arithmetic for entered counts; defining and reconciling the cohort is still your job.

**Next job: Check the arithmetic for your retention baseline.** Choose a fixed cohort and interval, then enter its starting and remaining user counts. For a closed cohort, enter zero new users. The calculator checks the rate; it does not identify the cohort. [Continue](https://www.productgrowth.blog/calculators/retention-rate)

---

All posts: https://www.productgrowth.blog/archive · Site: https://www.productgrowth.blog