October 4, 2013 at 15:00ARPU, or a few tenths of a dollar
- Tutorial
ARPU - average revenue per user, or "average revenue per user." If you think that this indicator is calculated by dividing all revenue by all installs in the period from the date of release to today, then this article is for you.
Many, due to lack of knowledge, or perhaps because of a desire to simplify their work, try to calculate one of the most important parameters of the game according to the above scheme. And this is wrong. Especially when LifeTime (the player’s lifetime in the project) of the user is less than the considered period by 2 times or less.
For clarity, I suggest that you familiarize yourself with the table:
Look more readably here
The first column- cohorts of users, united by a common attribute “registration date” (downloading the application and its launch by the user). Registration dates were broken down by week.
The second column is the number of registrations for a given period. It is very important: take registration from your database or from a statistical system that registers a user’s entry into the game as registration, and not just downloading an application from the market (in the article, I mean only Google Play or Apple AppStore by market). Keep in mind that the “download” at the market is considered to be installing the application on the device, and not launching it.
And also with a certain error, we are forced to limit the user to one device (1 device is 1 user); Thus, the user can install and run the offer from two devices, and we will assume that these are two users. Unless, of course, we use the services of our own database and force the user to somehow create an account (or login on social networks) in the game and attach the device to it.
1 - 10 weeks - weekly earnings.
On the first day of the ninth week, we were given the task of calculating how much the user brought us in the first eight weeks.
Let's imagine that the average life time of a user (average LifeTime) in our application is exactly three weeks. Well, let's go along a simple path, we will solve the problem “head on”.
For the weeks from the first to the eighth inclusive, 68 thousand users have registered in our application. We earned $ 51,680 in eight weeks. Divide the earnings by the number of registered users and get ARPU = $ 0.76.
BUT! Our main mistake is that, knowing the average user lifetime of three weeks, we did not give the opportunity to pay users who registered from the second day of the sixth week to the last day of the eighth. Users from the first to the fifth week had more than 21 days to make a payment, while these users had 20 or less.
Therefore, we can get the correct data for miscalculation from registrations for 1-5 weeks.
So, let's try to calculate ARPU more precisely. We take earnings from installations that came in the first five weeks, to this day, and the number of installations that came in these five weeks. We divide one into another ($ 32,150 / 35,000), we get ARPU ~ $ 0.92. This is $ 0.16 or 21% more than the first option ARPU! And consequently, with the same volumes of installations, our revenue will be 21% more. With large volumes of advertising campaigns, this 21% can seriously affect the marketing strategy.
Imagine that the project was available for download only 10 weeks. Considering the lifetime of the users and the fact that each subsequent week each group of users paid the same part from the first day (the coefficient decreased by weeks), the final ARPU after the project “died” would be $ 0.93. This ARPU is the most correct. On the first path, we received an intermediate value, which is equal to $ 0.76, on the second - $ 0.92.
For such parameters, an error of more than 10% is unacceptable. A living example - PopCap with their Plants vs Zombies 2 in two weeks gained 25 million users. Revenues with ARPU $ 0.76 = $ 19,000,000. Revenues with ARPU $ 0.92 = $ 23,000,000. Some lost 16 cents turned into unaccounted $ 4 million. Not bad, right?
In conclusion, I’ll add that we can consider LT as a separately paying user (ARPPU), however for this we need to know Paying Conversion, which strongly depends on the sources (quality) of traffic and monetization methods.
ARPPU - Average Revenue Per Paying User. Average revenue from a paying user. It can be expressed through ARPPU = ARPU / PC. For example, Candy Crush Saga has ARPPU = $ 40, Paying Conversion = 8%, therefore, ARPU = $ 40 * 8% / 100% = $ 3.2.
PC - Paying Conversion. Conversion to a paying user. If the game was installed by 100 users, and the conversion is 2%, then we have two users in the game who paid at least once.
That's all, thanks for watching! Ready to answer your questions in the comments.
PS: If you suddenly decided to publish data on average earnings per user - forget about the commission of the markets! Competitors must be jealous!
Many, due to lack of knowledge, or perhaps because of a desire to simplify their work, try to calculate one of the most important parameters of the game according to the above scheme. And this is wrong. Especially when LifeTime (the player’s lifetime in the project) of the user is less than the considered period by 2 times or less.
For clarity, I suggest that you familiarize yourself with the table:
Look more readably here
The first column- cohorts of users, united by a common attribute “registration date” (downloading the application and its launch by the user). Registration dates were broken down by week.
The second column is the number of registrations for a given period. It is very important: take registration from your database or from a statistical system that registers a user’s entry into the game as registration, and not just downloading an application from the market (in the article, I mean only Google Play or Apple AppStore by market). Keep in mind that the “download” at the market is considered to be installing the application on the device, and not launching it.
And also with a certain error, we are forced to limit the user to one device (1 device is 1 user); Thus, the user can install and run the offer from two devices, and we will assume that these are two users. Unless, of course, we use the services of our own database and force the user to somehow create an account (or login on social networks) in the game and attach the device to it.
1 - 10 weeks - weekly earnings.
On the first day of the ninth week, we were given the task of calculating how much the user brought us in the first eight weeks.
Let's imagine that the average life time of a user (average LifeTime) in our application is exactly three weeks. Well, let's go along a simple path, we will solve the problem “head on”.
For the weeks from the first to the eighth inclusive, 68 thousand users have registered in our application. We earned $ 51,680 in eight weeks. Divide the earnings by the number of registered users and get ARPU = $ 0.76.
BUT! Our main mistake is that, knowing the average user lifetime of three weeks, we did not give the opportunity to pay users who registered from the second day of the sixth week to the last day of the eighth. Users from the first to the fifth week had more than 21 days to make a payment, while these users had 20 or less.
Therefore, we can get the correct data for miscalculation from registrations for 1-5 weeks.
So, let's try to calculate ARPU more precisely. We take earnings from installations that came in the first five weeks, to this day, and the number of installations that came in these five weeks. We divide one into another ($ 32,150 / 35,000), we get ARPU ~ $ 0.92. This is $ 0.16 or 21% more than the first option ARPU! And consequently, with the same volumes of installations, our revenue will be 21% more. With large volumes of advertising campaigns, this 21% can seriously affect the marketing strategy.
Imagine that the project was available for download only 10 weeks. Considering the lifetime of the users and the fact that each subsequent week each group of users paid the same part from the first day (the coefficient decreased by weeks), the final ARPU after the project “died” would be $ 0.93. This ARPU is the most correct. On the first path, we received an intermediate value, which is equal to $ 0.76, on the second - $ 0.92.
For such parameters, an error of more than 10% is unacceptable. A living example - PopCap with their Plants vs Zombies 2 in two weeks gained 25 million users. Revenues with ARPU $ 0.76 = $ 19,000,000. Revenues with ARPU $ 0.92 = $ 23,000,000. Some lost 16 cents turned into unaccounted $ 4 million. Not bad, right?
In conclusion, I’ll add that we can consider LT as a separately paying user (ARPPU), however for this we need to know Paying Conversion, which strongly depends on the sources (quality) of traffic and monetization methods.
ARPPU - Average Revenue Per Paying User. Average revenue from a paying user. It can be expressed through ARPPU = ARPU / PC. For example, Candy Crush Saga has ARPPU = $ 40, Paying Conversion = 8%, therefore, ARPU = $ 40 * 8% / 100% = $ 3.2.
PC - Paying Conversion. Conversion to a paying user. If the game was installed by 100 users, and the conversion is 2%, then we have two users in the game who paid at least once.
That's all, thanks for watching! Ready to answer your questions in the comments.
PS: If you suddenly decided to publish data on average earnings per user - forget about the commission of the markets! Competitors must be jealous!
