Of all the components of the user lifecycle, retention is probably the most important metric for freemium apps and free-to-play games. Retention is indeed a direct factor in the computation of the lifetime customer value (LTV) of the users acquired.
Early retention metrics such as Day 3 retention can serve as proxies to assess traffic quality for ROI-positive user acquisition campaigns. Needless to say, retention is also a strong indication of the general quality of the app and its user experience.
However, retention has a problem. Everyone talks about it, but there’s no clear consensus on a common definition of retention nor how it is calculated. There are several ways to compute this metric, all of which lead to different results. People often end up comparing apples to oranges.
The purpose of this article is not to affirm which definition is the right one, but rather to establish a list of the main retention computation methods, and take a look at what they are good for. No method is necessarily better than another in absolute terms, they are just suited for different analytical goals. We came up with five different types of retention. Of these, three are most commonly referred to, and two are less widespread calculation methods which can nonetheless be put to good use. Please note that the names we gave each of them are not all “official” denominations, but rather chosen to give the best description of what they are actually about.
Generally, all of the retention metrics can be calculated the following way:
Day N Retention = Number of users retained on Day N (depending on the definition) / Number of users who installed the app on Day 0 (and could potentially be retained)
For each of the methods below, we took the example of Day 28 retention calculated across the different definitions. Here is the legend for the graphs:
Day(s) on which users need to open the app at minimum in order to be considered retained (on top of Day 0)
Example of a day on which users are not considered retained if they open the app
1. Full retention
- How it is computed: which proportion of users come back every single day to the app until D+N.
- Where and why is it used: full retention is extremely restrictive and not so widespread, but it however gives an idea of the level of engagement in the app.
- Day 28 example: only users who come back every single day from Day 1 to Day 28 are considered retained.
2. Classic retention
- How it is computed: which proportion of users come back to the app on Day+N.
- Where and why is it used: classic retention is the easiest to compute analytically and also the most widespread. It gives a general idea of the overall retention level in the app.
- Day 28 example: only users who came back precisely on Day 28 are considered retained. It doesn’t matter if and how often they came back before that.
3. Rolling retention
- How it is computed: which proportion of users come back to the app on Day+N or any day after that.
- Where and why is it used: rolling retention is for instance used by Flurry as their default definition of retention, and allows publishers to get an idea of the churn rate of their app (users who have not yet definitely dropped out), as it is basically equal to 100% minus churn.
- Day 28 example: users who came back on Day 28 or any day after that (such as on Day 50) are considered retained.
It’s worth noting that, if you compare the same metric across these definitions, the resulting retention rates will be ranked in decreasing order. Logically, the Day 28 full retention is indeed always lower than the Day 28 classic retention, which itself is always inferior to the Day 28 rolling retention.
4. Return retention
- How it is computed: which proportion of users come back to the app at least once within N days.
- Where and why is it used: return retention is often used in gambling as it gives an idea of how many people didn’t drop out after the first open (called retainers), which then also allow to retarget the others.
- Day 28 example: all users who came back at least once before Day 28 (eg on Day 5 or 16) are considered retained.
5. Bracket-dependent return retention
- How it is computed: it is a specific and restrictive case of return retention. In this case, we define brackets between typical retention marks such as Day 1/3/7/28/60 etc. Day M is then defined as the bracket mark just below the target retention mark N (eg: if N is 28, then M is 7). The metric will then measure the proportion of users who come back to the app at least once during one of these bracket. Users returning at least once between Day M and N will be considered retained.
- Where and why is it used: This method is useful to understand user behavior and usage patterns in your app.
- Day 28 example: users coming back on day 10 will be considered retained for the purpose of this metric. However, users coming back on Day 5 but not any time between Day 7 and 28 will not be retained.
We hope to have given you a rather comprehensive overview of the main ways to compute user retention in a mobile app or game. It is up to game developers and publishers to understand which definitions can be useful to them and what target levels they should aim for.
Always keep in mind that retention metrics are highly dependent on the type and category of the app/game.
Next time you hear someone talk about retention, don’t forget to ask them: “Yes, but which one”?