An app cohort analysis is a very important tool in analytics. It gained great popularity many years ago during the transition from working with absolute and generic metrics to a single-user analysis. This type of analytics allows you to analyze the audience and its behavior much more accurately and correctly draw conclusions about changes in the product. In this article, we'll talk about what kind of analysis it is, in which cases it should be used, what are its features, and how it works in devtodev.
Let’s start with what is a mobile app cohort analysis, and to be more precise with what is a cohort. A cohort is a group of users who installed the app within the same time frame. The time frame can be a day, week, month, quarter, and so on. This is the main feature of the cohort analysis for mobile app users - we only deal with groups and compare them with each other. This way we can take a look at the behavior of users who have started using our product, for instance, one month ago, and follow their ongoing activity or payments and not run into the risk of comparing them with the users who use our app for, let’s say, half a year or more because the metrics of the two groups at the moment of analysis will vary enormously. They may be similar if both cohorts were using the app for a similar number of days, but you should never compare the 3d day of one cohort with day 30 of another (these are the metrics used in app analytics). Cohort analysis always compares cohorts that exist for similar time periods.
We also would like to mention that you can calculate retention and cumulative ARPU using cohorts only. These metrics describe how user behavior changes over time.
Let’s take a look at some examples of where you can use cohort analysis.
Read more: Total Daily Play Time metric
Revenue prediction
As we have mentioned before, you should use cohort analysis to calculate the cumulative ARPU metric. This metric shows the average revenue from a user for a certain number of days. It increases daily and if you make it into a graph, after some time it starts looking like an almost horizontal line. It means that users of this cohort gradually stop paying. It may happen because, for example, they’ve bought premium access and simply don’t need to make other payments anymore. From this moment we can say that we know their LTV value. Thus we know the average amount of money a user pays us by a particular day of their life in the project. We can use this information to forecast revenue from our new users and other cohorts. For example, we know that the day 30 ARPU is $2. If we acquire 1,000 users for $1,500, then most likely we recoup this spend within a month (under the condition that the characteristics of those players are similar to the analyzed cohort). If we analyze this cohort in 3 months and find out that the ARPU is already $3.5, then we can calculate the revenue from the users who we acquired over this period:
1,000*$3.5-$1,500 = $2,000
Read more: Rolling Retention metric
Evaluation of results
Cohort analysis is especially useful in case you have changed the product, and you need to evaluate the impact of these changes, but for some reason, you can’t run A/B tests. In this case, you can compare the metrics of a cohort that was built before the changes took place with a cohort built after the changes. Let’s say you have changed the design of your in-game store, and that could influence your conversion into purchase rate and ARPU. If you compare the two cohorts’ metrics you can see what impact this change had on the audience. The second cohort’s key metrics in the example below are higher and we can conclude that the experiment was a success.
In devtodev, you can run a cohort analysis using a designated section of the left menu named “Cohort Analysis”. On the Custom Cohorts tab, you need to choose several cohorts and metrics that you want to compare. You don’t need to restrict yourself to the financial metrics only, you can analyze, for example, the behavioral metrics such as successful tutorial completion, retention, the number of sessions per user, and many more. The metric choice depends on the goal of the experiment and on what it was supposed to influence.
This kind of analysis allows you to create similar conditions for the compared users because there is no sense in comparing users who use the app for 3 months with those who installed it 7 days ago. At the very least the latter had less time to make a purchase. But if we use the cohort analysis, we can compare the same metrics of different users (i.e. d7 cumulative ARPU) which makes the comparison more accurate and precise.
