Mobile app retention

Mobile app retention describes whether people use an app again after an initial experience. A useful measure names the starting group, the later action and the time allowed for that action. An app open shows a return; an action tied to the person’s task can say more about whether the app helped.

Define the return that matters

Start with the job the app serves. A daily planning tool may give someone a reason to return tomorrow; a trip organiser may be useful when its saved itinerary is needed weeks later. The same daily target would misread those different patterns.

Choose a later action that represents useful activity for your product. That might be updating a plan, consulting a booking or completing another task. Keep app opens as a separate measure if they help explain the journey. An open alone does not establish that the person found what they needed.

The detailed activity decision is whether the recorded action represents a real result, covers valid ways to use the app and remains measurable as the product changes.

How to Define a Useful Return Action

Keep the cohort and clock visible

A retention rate needs a starting group and a later window. For example, a team could group eligible people by first recorded app open and count those who complete a specified task during a defined period after that open. This window illustrates a definition; it is not a target. Count each eligible person once in the starting group and at most once in the return window.

Task-based retention = eligible cohort members who complete the defined later action in the stated window ÷ eligible members of that starting cohort.

Show both counts beside the rate. State whether the unit is a person, account, device or installation, and how reinstalls and multiple devices are handled. Let every included member finish the return window before making a finished-window comparison.

Dashboard rates may use different populations. Apple’s App Store Connect retention view groups devices by installation date and excludes installations that have never opened the app.

Apple notes that a cohort denominator can grow when someone opens the app for the first time days after installing it. Neither report should be relabelled as a custom task-based rate.

Apple’s grid separates installation date from the day of the later opening. This makes the time offset explicit: a Day 5 cell describes an opening five days after installation, rather than an opening during a rolling five-day period.

Apple’s retention data can be filtered by app version, device, platform version and region. These views can help locate where an opening pattern differs, such as between device types or regions, before treating a whole-app change as uniform.

Key App Retention Metrics in Australia

Match the window to the job

Choose a window around the next plausible need. A missed day may matter for a daily routine and mean little for a task used only when travel approaches. Where another opportunity to use the app is observable, consider reporting use around that opportunity. Where it is not, state what a time-based rate cannot reveal.

Check dashboard period rules before interpreting a cell. A label such as “week 1” needs the reporting rules beside it.

Read the cohort grid

In a time-based retention grid, each row follows a cohort that installed on the same day, while each column represents a day offset from installation. A cell reports the percentage of eligible active devices that opened the app on that offset; for example, Day 1 and Day 5 show different points in the same cohort’s pattern.

Read across a row to see whether opening is concentrated soon after installation, falls away quickly or rises again later. A later rise can suggest that people are returning after a delay, rather than following a steady day-by-day pattern. Treat these shapes as prompts to investigate, not explanations of why behaviour changed.

An Average row summarises retention across the cohorts currently visible for each day offset. Use it as a quick overview, then inspect individual cohort rows: an average can conceal different patterns among installation dates. Changing which cohorts are visible also changes the set represented by that summary.

iOS vs Android Retention Patterns in Australia

App Retention Over Time: Cohort Grid Interpretation

Investigate a change

A lower rate is a reason to inspect the journey, not a diagnosis. Check whether the entry or return event changed, whether the feature was available to the cohort, whether the full window elapsed and whether people could resume their task. Then ask whether another need was likely to arise during the period.

Those checks lead to different decisions. Repair a completion event that fires at the wrong point. Improve recovery if saved work is hard to reach.

Reconsider the window if the next need ordinarily comes later. More reminders are justified only when they serve a current user need.

Compare cohorts only when their action, identity rule, eligibility and elapsed time are compatible. Keep platform, app version and relevant Australian service availability visible where they affect use. A difference between cohorts does not, by itself, show that a product change caused it. Record the cohort start, eligible count, return action, window, returning count and known data gaps with each decision.

Investigating a Drop in App Retention