Main Metrics. Average Revenue Per Paying User

EN
Let's find out how this metric can help you understand the reaction of your paying users.
Main Metrics. Average Revenue Per Paying User
Published
29.03.2019
|
devtodev

We at devtodev continue writing about important monetization metrics which you can use when analying your games.

This article will focus on the metric that describes a reaction of paying users to a project's value, which at the same time is a very important and useful monetization metric.

This metric is called ARPPU, or Average Revenue Per Paying User, where a paying user is  a user who made at least one purchase for a certain time period.

ARPPU is calculated as revenue for a selected time period divided by a number of users who made a purchase (Paying Users):

ARPPU = Revenue / Paying Users

While calculating ARPPU, it's also important to be aware of a period considered. Users can reissue payments during the month, but monthly ARPPU won't be equal to a sum of daily ARPPUs, as the divisor, or paying users per month, will be a number of unique users who paid this month, and not a total sum of paying users per day.

Unlike ARPU, this metric doesn't take into account non-paying users, only paying users are counted. It means that ARPPU will always be bigger or equal to ARPU. In fact, they would be equal only if all your active users made a purchase. Usually, ARPPU far exceeds ARPU.

Read more: Main Metrics. ARPU and ARPPU: What's the Difference?

Here is a small example for comparing these two metrics.

Let's assume that 1,000 out of 5,000 active users have made certain in-app purchases worth $3,000. Now we can calculate ARPU and ARPPU basing on this data.

ARPU = $3,000 / 5,000 = $0.6 — that’s an average sum that an active user pays
ARPPU = $3,000 / 1,000 = $3 —  that’s an average sum that a paying user pays

ARPPU, in turn, is directly related to the revenue.

Revenue = ARPPU * Paying Users

In other words, by increasing ARPPU or Paying Users, you can increase your Revenue.

However, while increasing ARPPU, it's important to keep an eye on other metrics, as its increasing may be followed by a decrease of other indexes.

devtodev free demo

Let's find out why it can happen.

For example, 100 users out of 1,000 make purchases worth $2.

In this case:

Revenue = $200
Paying users = 100
Paying Share (percentage of users who made a payment, calculated from the total amount of users) = 100 / 1,000 = 10%
ARPU = $200 / 1,000 = $0.2

ARPPU = $200 / 100 = $2

The easiest way to increase ARPPU is to raise prices.

Let's see how can this turn out.

Now the product costs $10 instead of $2, but only 20 users instead of 100 will buy it.

The metrics will change as follows:

Revenue = $200
Paying Users = 20
Paying Share = 20 / 1,000 = 2%
ARPU = $200 / 1,000 = $0.2

ARPPU = $200 / 20 = $10

Read more: devtodev’s Map of Key Analytics Metrics in Games

As we can see,  Paying Share dropped from 10% to 2%. At the same time, ARPPU increased from $2 to 10$, which did not affect the revenue and ARPU. These metrics remained unchanged.

What if there were fewer payers? For example, 10 instead of 20.

Revenue = $100
Paying Users = 10
Paying Share = 10 / 1,000 = 1%

ARPU = $100 / 1,000 = $0.1
ARPPU = $100 / 10 = $10

It’s clear that the revenue, paying share and ARPU decreased significantly. However, ARPPU still remains the same as before -  $10.

Here is a comparative table of these 3 cases:

Metric Source Data Option 1 Option 2
Active Users 1,000 1,000 1,000
Paying Users 100 20 10
Price $2 $10 $10
Revenue $200 $200 $100
Paying Share 10% 2% 1%
ARPU $0.2 $0.2 $0.1
ARPPU $2 $10 $10

In this regard, we need to ask ourselves: why we should calculate and control ARPPU and how we can use this index.

WHERE YOU CAN USE ARPPU

ARPPU is extremely good at describing repeated payments, as they do not increase the amount of paying users but increase your revenue.

Perhaps, this is the most proper way to increase ARPPU without compromising other indexes.

devtodev pricing

Let's check an example.

10 users out of 100 made purchases, each of them worth $2.

Revenue = $20, Paying Share = 10%, ARPU = $0.2, ARPPU = $2.

Then 3 users out of these 10 made a repeated payment worth $3.

Here we have:

Revenue = $29, Paying Share = 10%, ARPU = $0.3, ARPPU = $3.

Thus, repeated payments lead to an increase in all the major metrics.

By the way, according to devtodev's research of a number of online games, the more payments user makes, the greater their next payment amount will be.

Read more: How to Launch a Promo Campaign and Increase Product Revenue

There's another similar metric to ARPPU - Average Check, or Revenue Per Transaction. Although it has a slightly different meaning and another way of calculation, it can also be used only for paying users to assess their payments.

Summarizing all the above, the Average Check is the average cost of the transaction, an arithmetic average of all the payments, excluding the number of users who made these payments.

Average Check = Revenue / Transactions

It’s different from ARPPU: if one paying user makes a repeated payment, then the denominator in ARPPU - the number of paying users - will not change, but the number of transactions will increase, and it will affect the average check.

Let's compare ARPPU and Average Check.

For example, 10 users made payments, each worth $5. Then two of them made a second purchase, each of them worth $3.

In this case, ARPPU will be equal to (10 * $5 + 2 * $3) / 10 = $5.6.

To calculate the Average Check, we should divide the total revenue not by the number of paying users but by the number of payments made by them: (10 * $5 + 2 * $3) / 12 = $4.7.

It might be interesting to find out which ARPPUs successful projects have. Here's one of them: for the Game of War the annual ARPPU was $550. You can read more about this project and check the indexes of other apps here.

ARPPU is another indicator of user loyalty which at the same time allows you to evaluate the attitude of your users towards the prices on the product. By the way, you can read about other user loyalty metrics here.

ARPPU is also highly sensitive to their changes. This metric shows the satisfaction of users with your game because the higher it is, the more they will eventually pay.

Read more devtodev articles

Read more