We continue our series of posts on key metrics in analytics for mobile applications. The previous article was dedicated to the main metrics of usage and user acquisition, and today we will focus on how to measure the profitability of the application and evaluate the quality of the chosen model of monetization.
Payment validation
Speaking of financial metrics, it is important to mention the need to validate all the payments before sending data to the analytical system server. The accuracy of data on transactions affect not only the monetization metrics and the number of transactions, but the average check, ARPU, ARPPU and LTV.
That means that if you rely on data on transactions, which actually did not go through the app store (for example, transactions from the players who cheat), all the financial metrics would be distorted and almost useless.
devtodev has its own tools for payment validation:
- In the core SDK, developer can flag a user as cheater, then the transactions from that user would not be counted. This is useful if you have your own tracking mechanism for so-called "cheats".
- Additional "anti-cheat SDK» verifies all payments by sending a request with the details of the transaction to the server of the app store, as well as tracks so-called "time-cheats."
- Filtering mechanism for sandbox payments in "anti-cheat SDK» allows to exclude test transactions from statistics.
To all developers we highly recommend to use payment validation when collecting financial stats.
Now let's talk about the kind of statistics that can be useful to collect.
Read more: A/B Testing in LiveOps
Gross & Revenue
Gross metric shows the total income received from users for a certain period, and revenue only shows income that the developer gets.
In general, the revenue is equal to 70% of Gross - because 30% takes the app store, but you can change that percentage in the project settings in case you have any other agreements. For example, when working with the publisher, it is easy to calculate income excluding the share of the publisher.
Tips&tricks:
The price of the purchase is sent in the same currency as users payment was made, and the statistics display gross in dollars (or other currencies, if this option is available).
Each transaction is transmitted with several parameters: transaction ID, purchasing price, the name of the purchased items and the currency in which the purchase was made. Then the server transforms the cost to a single currency, in accordance with the currency code.
Sometimes developers forget about the currency codes when transaction data is sent, and eventually get the amount of dollars, yens, euro, and any other currencies which users used for purchases.
Be careful and make sure that the transaction data is sent considering the currency of payment!
Read more: How to switch to a new analytics system
Transactions & Transactions by User
Transactions - the number of transactions made in the chosen period.
Transactions by User - the average number of transactions per user.
Transactions by User = Transactions / N,
where N - the number of paying users in the chosen period.
Example:
50 users made 100 transactions per day.
Transactions = 100
Transactions by User = 100/50 = 2
Average Check
Average Check - shows the average amount of the transaction.
Average Check = Gross/Transactions
Example:
Gross from in-app purchases per day was $100, the users made 25 transactions.
Gross = $100
Transactions = 25
Average Check = $100/25 = $4.
Paying users
Paying users - the number of unique paying users for the selected period. The user is considered as a paying user if they made at least one transaction for the selected period.
Example:
From the 1st to the 10th of May an application was opened by three people.
User1 made one transaction, user2 — two transactions. Total number of paying users for the period May 1-10 will be equal to two.
Transactions
Paying users
User1
1
+
User2
2
+
User3
-
-
Total
3
2
Read more: Churn rate
Paying Conversion
Paying Conversion - share of the paying users of the total audience for the selected period.
Paying Conversion = (Paying users / Active users)
The ratio of paying users to the total number of unique active users for the selected period.
Example:
During the period from the 1st to the 10th of May, 100 users logged in the application, two of them made a purchase.
Active users = 100
Paying users = 2
Paying Conversion = 2/100 = 0,2
Tips&tricks
Analytical systems often give the opportunity to segment users based on the quality of paying /non-paying users. It is important to understand that the user who paid at least once, would appear in this segment regardless of the date of payment.
So, when you build a graph by the number of active users and by the segment of "paying users", for example, from the 1st to the 15th of May, all the people who were active at this period and made purchases at any period of time of usage of the application would appear in the report.
If you build a graph for the "paying users" metric excluding segments, only people who made payments at the selected time period would appear in the report.
* The user made a payment once on the 2nd of May. The user logged in the app on May, 1,2,3 and December, 16:
|
Date of visit* |
“Paying users” metric |
“Paying users” segment |
|
1 may |
- |
- |
|
2 may (payment) |
+ |
+ |
|
3 may |
- |
+ |
|
16 december |
- |
+ |
Read more: Game Analytics Metrics Glossary
ARPU and ARPPU
ARPU - Average Revenue Per User.
ARPPU - Average Revenue Per Paying User.
By these indicators you can evaluate if existing monetization meets financial goals of the project, or track whether an update led to an increase in revenue per user or not.
For example, if the users spend more money after your marketing campaign.
Lifetime value
Lifetime value (LTV) - average income per user for their whole lifetime in the application.
By itself, this metric deserves a separate article, but as a part of our list, I will describe how it is counted in the devtodev analytical platform.
LTV = lifetime*ARPU*k,
where k is the correction factor that takes into account the proportion of new users from the total number of users.
Of course, the metrics listed above are not all the existing metrics, but this set is enough to evaluate how things are going within your app.
Next time we will take a closer look at the custom events, and what events are usful to track in different types of applications, describe the conversion funnels, segmentation of audiences and cohort analysis.
