Demystifying Cohort KPIs, part II: Constructing crystal-clear revenue analysis

Cohort analysis is one of the most useful and informative ways to understand how users are moving through your app and engaging with its various elements. This week, we’re going to look into revenue KPIs, which are KPIs you can use to analyze and understand the revenue which your users generate.

Applying revenue-related KPIs to cohorts doesn’t just allow you to see how much money your users are spending. When you properly leverage your revenue KPIs, you can strike a well of data: determine where your most valuable users come from, what spurs them to spend and if there are any significant purchasing patterns.

If you’d like to start with some background reading, you can check out our KPI documentation. And don’t forget that the third and final post of Demystifying Cohort KPIs is coming next week.

A quick refresher

To begin, let’s review the cohort model we used last week. We’ll be using the same model that we used in our first post to calculate out metrics: today is Monday, and we’re looking at the three users who installed our app last week (ending with yesterday, on Sunday). To make it easier, we even named them. Alice installed our app on Tuesday, Bob on Friday and Charley on Sunday (the last day). Here’s the retention table for our cohort:

DOW \ DAI	0	1	2	3	4	5	6	7
Mon	0	0	0	0	0	0	0	0
Tue	1	0	1	0	1	0	0	na
Wed	0	0	0	0	0	0	na	na
Thu	0	0	0	0	0	na	na	na
Fri	1	1	1	0	na	na	na	na
Sat	0	0	0	na	na	na	na	na
Sun	1	0	na	na	na	na	na	na

Retained Users segmented by Install Day

Charley installed our app yesterday but hasn’t been back since, while Bob installed on Friday and has been using the app every day since except today.

With this in mind, let’s move on to looking at how Alice, Bob, and Charley trigger revenue within our app.

Revenue

Our app makes revenue from user purchases, which adjust tracks through the custom event setup. This is how you can define events in your apps that bring revenue once triggered. Let’s look at the revenue table per install day for our example:

DOW \ DAI	0	1	2	3	4	5	6	7
Mon	0	0	0	0	0	0	0	0
Tue	10$	0	0	0	0	1$	0	na
Wed	0	0	0	0	0	0	na	na
Thu	0	0	0	0	0	na	na	na
Fri	10$	0	12$	0	na	na	na	na
Sat	0	0	0	na	na	na	na	na
Sun	0	0	na	na	na	na	na	na

Revenue in USD segmented by Install Day

Looking at this chart, we can understand how our three cohort members have spent money within our app: Charley hasn’t triggered any revenue yet, Alice triggered revenue once on her install day and again on day 5 after install, and Bob triggered revenue on his install day as well as yesterday.

If we assume that there’s only one tracker setup, then we can represent the tracker segmentation using the above rows.

Tracker \ DAI	0	1	2	3	4	5	6	7
Last week’s users	20$	0	12$	0	0	1$	0	0

Revenue in USD for last week's cohort

Revenue per User

Understanding the total amount of revenue made for each day after install is already very interesting to identify trends in purchases, over a user’s lifetime. But if we are looking at comparing cohorts - say, two different weeks, or two different acquisition sources - total revenue alone isn’t so helpful.

To compare them properly, we need to compensate for varying sizes of different cohorts. That’s a key reason why we would want to calculate the revenue per user.

We can start with the simplest calculation, which is to divide Revenue by the Cohort Size. This is how the revenue per user KPI is defined in the Adjust UI. Making this division gives us the following table:

Tracker \ DAI	0	1	2	3	4	5	6	7
Last week’s users	(20/3)$	0$	(12/2)$	0$	0$	(1/1)$	0$	0$

Revenue Total

The revenue per user, once split out per cohort day, gives us a view of the development, and specific snapshots that we can use to compare between different sources. But the metric does not quite as easily encapsulate the aggregated development of revenue across a longer period of time. Especially with smaller cohorts, it’s very handy to aggregate the development up until a certain day, so that we can compare the total revenue development in cohorts.

For this reason, we’ll crunch out the total revenue. This KPI shows the accumulated revenue for the whole cohort. The value for each day-after-install is derived from the revenue total for this day-after-install and all days-after-install before:

Tracker \ DAI	0	1	2	3	4	5	6	7
Last week’s users	20$	20$	32$	32$	32$	33$	33$	33$

Revenue Total in USD for last week's cohort

On day 2 after install, for example, we see the contribution from Bob’s purchase made yesterday added to Bob and Alice’s purchases made on their install days.

This also allows us to see when a cohort breaks even on their acquisition costs. If we’ve tracked the acquisition from a paid newsletter campaign, for example, it’s very helpful to see if a cohort pays for itself, and if so, when.

Revenue Total In Cohort

A cohort is complete if all users from the cohort installed in a time frame that allowed them to reach all the days-after-install being studied.

The Revenue Total In Cohort is one of the trickier KPIs that people sometimes struggle to read, especially for incomplete cohorts. It’s defined as the accumulated revenue from users in the cohort.

The following table is derived from the Revenue data found above. You can see it mirrors the Revenue Total table until day 3 after install. However, from day 4 after install onwards, Bob’s contributions are excluded. This is because Bob only installed three days ago. From day 4-after-install until day 6-after-install, the KPI shows only Alice’s revenue contributions. Alice is the only user in this cohort who has 6 full days-after-install. There are no users that installed 7 days ago for this cohort, so 0 revenue shows in this column.

Let’s build the table for our example:

Tracker \ DAI	0	1	2	3	4	5	6	7
Last week’s users	20$	20$	32$	32$	10$	11$	11$	0$

Revenue Total in cohort for last week's cohort

It’s worth mentioning that for complete cohorts, the KPIs Revenue Total In Cohort and Revenue Total have the same values.

Now, this metric looks weird. But it comes in handy in many later calculations, and is a step to calculating further KPIs. Understanding that it looks a bit funky is a good reason to avoid becoming confused when your pivot tables spit out seemingly inconsistent results.

Lifetime Value

We’ve previously computed the revenue per user, which is a handy metric for comparing different cohorts.

The lifetime value of a user is the total amount of revenue that a user contributes through their entire lifetime in the app. We can’t actually know the lifetime value until we are completely certain that a user will never use the app again - which we usually can’t be certain about. We can only make either a projection (which is a very interesting topic in itself), or we can look at the picture as it stands today.

To do this, we define Lifetime Value as the Revenue Total In Cohort divided by the Cohort Size. Let’s write the table explicitly:

Tracker \ DAI	0	1	2	3	4	5	6	7
Last week’s users	(20/3)$	(20/3)$	(32/2)$	(32/2)$	(10/1)$	(11/1)$	(11/1)$	(0/0)$

or with the division performed:

Tracker \ DAI	0	1	2	3	4	5	6	7
Last week’s users	6.66$	6.66$	16.00$	16.00$	10.00$	11.00$	11.00$	n/a

Lifetime Value for last week's cohort

For the days when this cohort is complete, this metric effectively shows us the total aggregate revenue per user, allowing us to easily compare the revenue development between different cohorts. When it’s incomplete, it gives us a very early indication of the trend that we can expect from the cohort.

Note that although Revenue Total is always a non-decreasing metric, Revenue Total In Cohort and Lifetime Value might decrease, but only for incomplete cohorts. This is due to possibly excluded contributions of some users in the right-hand side columns.

Lifetime Value is an important KPI because it gives you an indication of how much time it would take before a cohort’s average user reaches a certain revenue level. In essence, it will allow you to estimate how much time it takes for you to start making returns on investments made in user acquisition campaigns for specific channels.

Paying Users Lifetime Value

Although we’ll talk about Paying Users based KPIs in a separate article, the Paying Users Lifetime Value KPI is worth mentioning while we are at Lifetime Value. The derivation is simply the same as the above, but differs in that instead of the full Cohort Size, only the portion of users who triggered a revenue event - the Paying Users - is used as a denominator. So the calculation follows as revenue_total_in_cohort / paying_user_size.

In summary

With the LTV calculated, we now have a whole set of revenue KPIs that we can use to understand exactly how users monetize in your app. A quick recap:

• Start by segmenting the user base into cohorts and break out their actions - in particular, the revenue they generate - into individual days-after-install.
• To compare different cohorts to each other, we frequently compute the revenue per user by dividing the revenues of each day-after-install over the Cohort Size.
• To understand cumulative revenue patterns, we sum the revenues across the days-after-install, resulting in the revenue total.
• The revenue total in cohort sums the same cumulation but taking the Cohort Size into account, so as to more clearly separate the revenue trends.
• Finally, we’ll construct the current lifetime value by dividing the Revenue Total In Cohort by the Cohort Size.

This hopefully allows you to gain a deeper understanding of revenue KPIs, how they work, and how you can use them. These KPIs are calculated in adjust’s cohort analysis tool, among a few others.

Speaking of those other metrics - we still have a few more to work on. Remember to keep an eye out next week for the third part of Demystifying Cohort KPIs. In our third and final post, we’ll be looking at Paying Users, Events and Event Conversion KPIs.