Measuring retention from a clearly defined starting event

Choose the event that defines the retention cohort before counting later activity. Downloads, first app launches and first completed tasks create different starting groups. State the rule beside every rate so readers know who could return.

Choose the starting event

Use first recorded open to ask whether people use the app after launch. Use first verified feature completion to ask whether people reuse that feature after initial success. The latter excludes people who never complete it, so its rate cannot describe retention among all first-open users.

Write the starting state and timestamp precisely. For a hypothetical saved-plan feature, “first plan successfully saved” needs a rule for failed saves and repeated saves.

Decide whether an existing customer on a new phone qualifies. Choose whether the measurement unit is a person, account, device or installation, and use only an identity connection the available data can support.

Check whether an automatically collected event represents a launch or a download before using it as a cohort start.

Apple’s App Store Connect retention view groups devices by installation date and excludes installations that have never opened. Its denominator may grow when an installer first opens days later. A report-defined start of that kind cannot silently replace a custom first-task cohort.

Starting Events and Their Impact on Retention Rates

Specify the return and window

A complete definition states the starting event, eligible population, identity unit, later action, window and repeat rule. For example: among eligible accounts whose first verified plan save occurred during a given week, what share opened that plan again during days 7–13 after the save? The example is a proposed definition, not a platform preset or benchmark.

The denominator is distinct eligible accounts with a qualifying first save. The numerator is those same accounts with at least one qualifying later plan open in the window. Several opens by one account count once; the starting save does not count as a return.

Retention rate = qualifying starting-cohort members with the later action in the window ÷ all eligible members of that starting cohort.

If a hypothetical cohort contained 200 eligible accounts and 50 opened their plan in the defined later window, the rate would be 25%. Those numbers show the arithmetic only.

Let the window finish

A person who started yesterday cannot yet qualify for a return window two weeks later. Mark recent cohorts as pending until every included member has had the full elapsed opportunity. Show counts with percentages, especially for small cohorts.

State whether “day 7” is a calendar day in a reporting time zone or an elapsed interval from each starting timestamp. Check how the chosen tool assigns calendar days and week boundaries before comparing cohorts.

Confirm whether the tool’s calculation mode and inclusion criterion match your written definition before comparing cohort rates.

If the question requires account-level identity across devices, verify that the chosen analysis supports it; a cohort cell is not automatically an account-level rate.

Check boundary cases

Review reinstalls, second devices, failed starting actions, actions completed outside the app, returns after the window and event changes across app versions. Each can change who enters or qualifies. Keep the written cohort definition with the rate so another reader can reconstruct the comparison.