ARPU, or a few tenths of a dollar
ARPU - average revenue per user, or “average user revenue”. If you think that this indicator is calculated by dividing the entire revenue into all installations in time from the moment of release and for today, then this article is for you.
Many, due to lack of knowledge, and perhaps because of the 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 the LifeTime (the player’s lifetime in the project) of the user is less than the period under consideration 2 times or less.
For clarity, I suggest to get acquainted with the table:
')
More readable here
The first column is the cohorts of users, united by the common feature “registration date” (the application is loaded and launched by the user). Registration dates are broken by week.
The second bar is the number of registrations for a given period. Very important: take registrations from your database or from the statistical system, which regards the registration as the user’s entry into the game, and not just downloading an application from the market (in the article, I mean only Google Play or Apple AppStore under the market). Keep in mind that the market “loading” is considered to be the installation of the application on the device, and not its launch.
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. If, of course, we do not use the services of our own database and do not force the user to somehow create an account (or log in on social networks) in the game and link the device to it.
1 - 10 weeks - weekly earnings.
On the first day of the ninth week we were given the task - to calculate how much the user brought us in the first eight weeks.
Let's imagine that the average user lifetime (average LifeTime) in our application is exactly three weeks. Well, let's go on a simple path, solve the problem "in the forehead."
In the weeks from the first to the eighth, inclusive, 68 thousand users have registered in our application. In eight weeks we earned $ 51,680. We divide the earnings for the number of registered users and get ARPU = $ 0.76.
BUT! Our main mistake is that, knowing the average lifetime of the user in the amount of three weeks, we did not give the opportunity to pay to 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 have 20 or less.
Therefore, we can get the correct data for rendering with registrations for 1-5 weeks.
So, let's try to calculate ARPU more precisely. We take the earnings from the installations that came in the first five weeks, until today, and the number of installations that came in during these five weeks. We divide one into another ($ 32,150 / 35,000), we get ARPU ~ $ 0.92. This is $ 0.16 or 21% more ARPU from the first option! Consequently, with the same installation volumes, 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 for only 10 weeks. Considering the users' lifetime and the fact that each subsequent week each user group paid the same amount from the first day (the ratio with weeks decreased), the final ARPU after the project “died” will 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 greater than 10% is unacceptable. A living example - PopCap with their Plants vs Zombies 2 in two weeks gained 25 million users. Revenue from ARPU $ 0.76 = $ 19,000,000. Revenue from ARPU $ 0.92 = $ 23,000,000. Some lost 16 cents turned into an unaccounted $ 4 million. Not bad, right?
In conclusion, I can add that LT can be considered as a separately paying user (ARPPU), but for this we also need to know Paying Conversion, which strongly depends on the sources (quality) of traffic and how to monetize.
ARPPU - Average Revenue Per Paying User. Average revenue per paying user. Can be expressed via ARPPU = ARPU / PC. For example, Candy Crush Saga ARPPU = $ 40, Paying Conversion = 8%, therefore, ARPU = $ 40 * 8% / 100% = $ 3.2.
PC - Paying Conversion. Conversion to a paying user. If the game has installed 100 users, and the conversion is 2%, then we have two users in the game who have paid at least once.
That's all, thank you for your attention! Ready to answer your questions in the comments.
PS: If you suddenly decided to publish data on the average earnings from the user - forget about the commission of the market! Competitors must be jealous!
Many, due to lack of knowledge, and perhaps because of the 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 the LifeTime (the player’s lifetime in the project) of the user is less than the period under consideration 2 times or less.
For clarity, I suggest to get acquainted with the table:
')
More readable here
The first column is the cohorts of users, united by the common feature “registration date” (the application is loaded and launched by the user). Registration dates are broken by week.
The second bar is the number of registrations for a given period. Very important: take registrations from your database or from the statistical system, which regards the registration as the user’s entry into the game, and not just downloading an application from the market (in the article, I mean only Google Play or Apple AppStore under the market). Keep in mind that the market “loading” is considered to be the installation of the application on the device, and not its launch.
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. If, of course, we do not use the services of our own database and do not force the user to somehow create an account (or log in on social networks) in the game and link the device to it.
1 - 10 weeks - weekly earnings.
On the first day of the ninth week we were given the task - to calculate how much the user brought us in the first eight weeks.
Let's imagine that the average user lifetime (average LifeTime) in our application is exactly three weeks. Well, let's go on a simple path, solve the problem "in the forehead."
In the weeks from the first to the eighth, inclusive, 68 thousand users have registered in our application. In eight weeks we earned $ 51,680. We divide the earnings for the number of registered users and get ARPU = $ 0.76.
BUT! Our main mistake is that, knowing the average lifetime of the user in the amount of three weeks, we did not give the opportunity to pay to 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 have 20 or less.
Therefore, we can get the correct data for rendering with registrations for 1-5 weeks.
So, let's try to calculate ARPU more precisely. We take the earnings from the installations that came in the first five weeks, until today, and the number of installations that came in during these five weeks. We divide one into another ($ 32,150 / 35,000), we get ARPU ~ $ 0.92. This is $ 0.16 or 21% more ARPU from the first option! Consequently, with the same installation volumes, 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 for only 10 weeks. Considering the users' lifetime and the fact that each subsequent week each user group paid the same amount from the first day (the ratio with weeks decreased), the final ARPU after the project “died” will 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 greater than 10% is unacceptable. A living example - PopCap with their Plants vs Zombies 2 in two weeks gained 25 million users. Revenue from ARPU $ 0.76 = $ 19,000,000. Revenue from ARPU $ 0.92 = $ 23,000,000. Some lost 16 cents turned into an unaccounted $ 4 million. Not bad, right?
In conclusion, I can add that LT can be considered as a separately paying user (ARPPU), but for this we also need to know Paying Conversion, which strongly depends on the sources (quality) of traffic and how to monetize.
ARPPU - Average Revenue Per Paying User. Average revenue per paying user. Can be expressed via ARPPU = ARPU / PC. For example, Candy Crush Saga ARPPU = $ 40, Paying Conversion = 8%, therefore, ARPU = $ 40 * 8% / 100% = $ 3.2.
PC - Paying Conversion. Conversion to a paying user. If the game has installed 100 users, and the conversion is 2%, then we have two users in the game who have paid at least once.
That's all, thank you for your attention! Ready to answer your questions in the comments.
PS: If you suddenly decided to publish data on the average earnings from the user - forget about the commission of the market! Competitors must be jealous!
Source: https://habr.com/ru/post/196352/
All Articles