Retention
Retention is the share of a group that returns for useful activity after a set time.
Another example
The team counts groups that still publish in week four. It doesn't count groups that only reopen the app.
Main parts
- 01Cohort definition
- 02Meaningful return event
- 03Time window and retained share
Use it when
Use it when a product becomes more useful through repeat use.
Do not use it when
Never mix different starting groups or count an action that doesn't show real value.
Name used in code
cohort analysis Before you ship
Check the target user, wanted result, current baseline, evidence source, scope, owner, and success level. List assumptions, open risks, and the next test or decision.
Outcome: Use Retention to make a focused product decision backed by evidence. User context: The team counts groups that still publish in week four. It doesn't count groups that only reopen the app. Product concept to apply: Retention. Why it fits: Use it when a product becomes more useful through repeat use. Do not use it when: Never mix different starting groups or count an action that doesn't show real value. Product framing: Name the target user and wanted result. Record the current baseline and evidence. Set what is in and out of scope, the limits, the owner, and the time frame. Decision quality: Keep facts, guesses, and unknowns separate. Record the options you did not choose and what evidence would change the decision. Acceptance criteria: The document names an owner, target user, measurable result, scope limit, evidence source, open risks, and next test. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Target group, baseline, success level, owner, time frame, dependencies, and review schedule.
Check this request
Review the current use of Retention. Definition: Retention is the share of a group that returns for useful activity after a set time. Release checks: Check the target user, wanted result, current baseline, evidence source, scope, owner, and success level. List assumptions, open risks, and the next test or decision. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.