Key Monetization Metrics

Let's talk about the main metrics for your app that will lead to monetization.
Key Monetization Metrics

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.

Payments 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 payments validation:

  • In the core SDK developer can mark the user as a 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.

We highly recommend to use payments validation when collecting financial stats to all developers.

Now let's talk about the kind of statistics useful to collect.

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.


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 the opportunity is available).

Each transaction is transmitted with several parameters: the ID of the transaction itself, the purchase price, the name of the purchased goods 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, rubles 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!

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

N - the number of paying users in the chosen period.


50 users per day made 100 transactions.
Transactions = 100
Transactions by User = 100/50 = 2

Average Check

Average Check - shows the average amount of the transaction.

Average Check = Gross/Transactions


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 he made at least one transaction for the selected period.


From the 1st to the 10th of May application was opened by 3 people.
User1 made ​​one transaction, user2 — two transactions. Total number of paying users for the period May 1-10 will be equal to two.



Paying users













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.


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


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 payments at any period of time of usage of the application would appear in the report.

If you build a graph on the metric "paying users" excluding segments, only people who have made ​​payments at the selected 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




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 any updates led to an increase of revenue per user.

For example, if the users spend more money after your marketing campaign.

Lifetime value

Lifetime value (LTV)  - average income per user for his 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 our analytical system.

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 application.

If you feel that we have missed some really important metrics, you are very welcome to comment.

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.

Read more