Developing an app is always a challenge, especially when you think of the things that you need to keep an eye on at the same time. Then it gets more complicated when the app is released and you need to track its perfromance somehow.
Here is an overview of the key metrics in mobile applications. If someone were to ask you, what is the difference between ARPU and ARPPU, or Lifetime and Lifetime Value, just give them a link to this article.
Usually applications are created with one simple goal - making money. As you may know, nobody is willing to give you money for nothing. So, to make money you need to take pains and go through many stages. Here is how the majority of mobile applications work:
- people download the app from the app store to their mobile device, then launch the application (and this is where we are beginning to use the word "users" instead of "people");
- if the application is liked by users, they start to use it from time to time, and if it is not - they do not use it, or even remove it from their devices;
- if users really like the app, they use it again and again, and some especially loyal users make purchases within the app for real money, bringing joy to both themselves and the developer.
Each stage has its own metrics that should help you to understand if your application works successfully and get the feedback on the users behavior.
All metrics discussed are available for integrating through the devtodev SDK.
Read more: Game Analytics Metrics Glossary
So, one day users have installed the app on their devices and launched it for the first time - after the first launch of the application an individual turns into the user. Everybody who launched the application on a certain day for the first time, called 'new users' of that day. How many new users should be there? Of course, the more the better, but in the fact it depends on your project. Most importantly, the number of new users must cover the outflow from the project, then the project will grow. The number of new users may increase due to the advertising campaigns or by the introduction of viral mechanisms to the project, then the existing users will bring new ones.
After a while, more and more new users, accumulate in the project and at some point you may wish to find out the number of users who have sampled your application. For this purpose there is a metric called 'total users', it shows how many users of your application are in the database to the chosen date.
Read more: Top 10 Youtube channels for data analysts
Users who have launched your application for the first time will either like it or not. If the user does not like the app, they will most likely leave it and not come back the next day.
If the user returns to the app the next day after the first launch, it means that judgement on "how nice'" went well (first you judge "how nice", then you judge "how wise").
The percentage of users who returned the next day after the first visit, is called day one retention. This indicator should be followed over time and constantly improved - there is no limit to perfection. If the user does not return the next day after the first visit, it means that something did not suit him, though it is most likely the interface part. Try changing the interface for new users (add or change the tutorial; enter a hint, telling new users about the benefits of the application). If you did everything right - the following day one retention rate will rise. Users are not acquired easy nor cheap, and it is wrong to lose them the next day, so always optimize this indicator.
Read more: How to switch to a new analytics system
The percentage of users who returned 7 days after the first visit, is called day 7 retention. Finally, if the users returned 28 days after the first visit, the percentage of such users is called day 28 retention. And there it gets more serious. You may assume that if the users remain faithful even 28 days later, they will be really interested in your application.
In an ideal situation, all three retention indicators will be equal to 100% (the user stays with you after 1 day, 7 days, and 28 days). But this is hardly achievable. Think about what the user has to face for the first week, in the first month, because of what they may leave and optimize these bottlenecks. You may get assisted by the user segments, events and funnels. All these tools help identify the stages where the user is making decision about leaving.
To calculate the retention period of the other time frames (not only for 1, 7 or 28 days), there is a metric called rolling retention. It shows how many users (as a percentage) first launch the application on the selected date, still remain active (here under the active users, we mean all users who opened the application at least once in the last 7 days). As approaching the current day, this indicator grows. In this case, it is likely that at the Rolling Retention graph you'll find the leaps (higher percentage of users who still remain active), and then you will have to deal with each of these leaps. These leaps may be caused by various reasons: ad campaign settings or simple seasonality. In particular, we have to deal with the fact that people came on Friday, become a little bit more loyal, as they have spare time on Saturday and Sunday to further explore your application.
User Activity Indicators
So, your application is already running, new users appear, audience gets accumulated. The number of the unique users that logged into your app on a particular day is called DAU (Daily Active Users) of that day.
The number of the unique users that logged into your application within a week is called WAU (Weekly Active Users).
Please note that WAU - it is not the sum of seven DAU, it is the unique users who visited your application within a week. The same user may visit your app every day for a week, and then they will increase DAU of each day by 1, but WAU will be also increased only by 1, as in WAU the repeated visits are not considered.
Similarly, the MAU (Monthly Active Users) indicator is calculated - the number of unique users who logged into the application within a month.
Indicators DAU, WAU, MAU determine the scale of your project. And it is about them you will be asked in the first place when entering into partnership agreements. Of course, all the indicators should grow over time. In order to ensure their growth, you need to maximize the flow of new users and the percentage of retention rate.
It is also interesting to calculate the ratio, for example, DAU to MAU. This indicator is sometimes called 'sticky factor', it shows the regularity of the users logs. If it is assumed that there are 1,000 users in the project, and each of them logs every day, then DAU, and MAU are equal to 1,000, and the sticky factor indicator equals to 100%. If every user logged only once within a month, Sticky Factor will equal to only 3.3%. The higher the number of this indicator, the more regular users log into your application.
Read more: Game analyst: job, career and how to start
It often happens that the indicators DAU, WAU and MAU vary considerably due to the unstable flow of new users. In order to avoid taking into account these variations there are LDAU (Loyal Daily Active Users), LWAU and LMAU metrics.
LDAU – the number of unique loyal users run the application on a particular day. In this case, the loyal user is the one who runs application at least once a day after the first visit. Similarly LWAU and LMAU are calculated.
It turns out that the closer to each other the indicators of DAU and LDAU are, the less there is so-called "one-day" - users in the application (users who do not return to the application the next day after the first visit). So, the closer to each other are DAU and LDAU, the higher is the day one retention.
Sometimes you may need to know how many users are in the application at a particular moment. To do this, there is the users online metric, which estimates the number of users simultaneously playing at a particular point and is updated every five minutes. This metric is especially relevant for online games, where the interest to the game depends on the number of simultaneously playing users.
Also pay attention to the maximum 'users online' within a day. First, it points out the peak load of the server. Second, it helps to identify the optimum time when the application has the maximum number of users (for example, to send push notifications). Third, it's a well-known indicator to compare the popularity of several applications.
Every visit of the application by the user is called a 'session', and sessions metric indicates the number of sessions made in the app within a period.
If you divide the total length of all sessions by their number, you get the average session length indicator. Thus it is impossible to say that the longer the duration of the session is better than the short one. In taxi applications the session is short: the only thing required is to reserve a car, so the shorter the session, the more convenient the service is. And, for example, in reading applications the sessions are usually much longer.
The lifetime metric shows the average number of days the user uses the application. It is recommended to use this metric to narrow custom segments: for paying and non-paying users, for the users reached a certain level. In this case, you will know the most probable lifetimes of the users from each segment and would be able to offer them something that they are going to be interested in at the right time: push-notification, discounts and special offers, gifts, new quizzes, etc. In addition, the lifetime indicator may be used in the planning of any regular activities in your project (e.g. ad campaigns). By knowing the average time a user spends in the project, you may set up events in such a way that for the most users, these events were a novelty.
It is necessary to increase the lifetime indicator as the longer the user stays with you, the more loyal he is, and the greater the probability of his payment is. Think of what would encourage players to stay with you for a longer period. In online games, lifetime is easily increased by introducing the regular (daily, weekly) tasks for the users.
Read more: SQL for Beginners: In-App Purchase Structure
So, the users decide to pay money for the purchase of the content within the application. The number of unique users who pay per day (or per longer period) is shown by the paying users metrics.
The paying share metric shows the percentage of paying users from all unique users active over the period. Ideally, each user is a payer and the paying share equals to 100%. In fact, this indicator is much lower, and its growth even by 1% is a great achievement for the project. According to Newzoo, in 2014 32% of all mobile game users made in-game purchases. And this figure can be considered too high, as we are talking about the percentage of people who made at least one payment at least in one game within the year.
The increase of the share of paying players may be extended by adding new content for buying, by changes in prices, by advertising campaigns promoting sales.
The paying conversion metric, in turn, shows daily (or a longer period) percentage of paying users among all those who have logged that day (period). As is the case with rolling retention, try to find the leaps in the behavior of this indicator. Quite possibly, it will point out some of the conditions in which the percentage of paying users from the number of logged users is maximal (advertising campaigns, banner ads, etc.).
Each payment by the user is a separate transaction in the database, while one user may make a number of transactions within a period (you most likely would be happy for that).
The total number of transactions for the period is shown in the transactions metric. And the transactions by user metric shows the average number of transactions made by one paying user for a selected period. If no user made repeat payments, then the transactions by user metric equals to one.
The total amount of all payments of the users for the period is shown by the gross metric. However, the developer would not get that money in full: app store takes its commission. As a rule, the commission is 30%, so 70% of the gross comes to the developer and is shown in the revenue metric. If the commission is not equal to 30%, it can be easily changed in the settings of devtodev account.
In fact, it is for the revenue indicator you started the development of your application.
One more important indicator is the measure of monetization, ARPU (Average Revenue Per User). It is calculated as the sum of payments for the period (gross) divided by the number of unique players within the period (DAU, MAU, WAU). ARPU shows the average amount of money gained from one player, while both paying and free users are taken into account. ARPU is perfect for measuring business performance and comparison of several projects.
ARPU is useful to be considered as a whole (at least to compare the efficacy of several projects), and separately for each user segment. In particular, it is possible to calculate ARPU for new users and ARPU of the core users. ARPU of the new users will be significantly lower, but its comparison with the "core" ARPU will show you how important it is, that new users become the "core".
Compare ARPU for different user levels, for different time periods since the first launch. Generally, the longer a user stays in the project and the higher their level, the higher their ARPU.
The ARPPU (Average Revenue Per Paying User) metric is calculated as the sum of payments for the period (gross) divided by the number of unique paying players (paying users). ARPPU shows the level of prices in the application and how these prices influence the paying users, how much money they are willing to spend for the period.
Read more: ARPU and ARPPU: What's the Difference?
If each player is paying, then the ARPU equals to ARPPU by the definition.
To increase ARPPU, simply raise prices in the project. The most paying users will continue to pay, but the ARPU (which is more important to measure the effectiveness of business) risks falling.
So all the steps to change the monetization of the project should be taken in the way to increase both ARPU and ARPPU. In online games introduction of new appealing content works for these purposes best: more players begin to pay, and those who paid before start paying more to buy more powerful weapons. As a result, both the percentage of paying users and the average amount of payments increase for the period. In other words, paying share, ARPU, ARPPU grow.
Also we should mention the average check metric, which is calculated as gross divided by the number of payments (transactions). It is very similar to the ARPPU metric, however ARPPU, unlike average check, ignores the recurring payments from the same paying user. If we assume that each paying user paid only once for the period, the average check will equal to ARPPU.
Finally, the last (but not least) is the Lifetime Value (LTV) indicator. It shows the amount of money spend by the average user over the entire petiod of application usage. There are lots of articles written about LTV, it is truly one of the most important indicators of the effectiveness of the application, it combines both the duration of user activity and their payments.
Lifetime value is useful to determine the price of user acquisition. The rule is simple: the lifetime value must be greater than the price of user acquisition, otherwise the business is not effective.
To maximize LTV, understand that lifetime value is both lifetime and value (in this case, ARPU). In other words, the longer the user is with you and the higher the average income from them is, the higher the LTV. The project must be liked by the user, then the lifetime, ARPU and after them LTV will increase.
Monitor the changes of this indicator to understand the reasons, identify the factors that maximize LTV, and plan all the changes to your project based on this.
It is also useful to consider LTV in the context of different custom segments: by the country or language, by the registration date.
So we looked up all the key metrics for the applications. To tell you the truth, they are not only suitable for mobile applications, but also for online games, online shopping, elsewhere.
Follow the these indicators over time, understand the reasons for their change in one direction or another, identify and apply the most effective factors.
We also recommend to make your analysis more detailed. Key metrics: ARPU, lifetime, retention, etc. give the idea of the general state of the project, and the deeper understanding of their behavior requires in-depth analysis. You may use custom segments for this, then you get a chance to take a look at every metric for each user segment separately.
We wish you the highest ARPU and extended Lifetime.
And here's an exercise to make sure that you're ready go apply your new knowledge.
And now, to see how you have learned the material, we suggest you to solve the problem.
February 1, 2015 110 people have downloaded the application Test_application. It was launched by 100 of them. We assume that on other days users have not downloaded nor launched the application.
A week later, on February 8, 2015, only 30 unique users remained active in the app. Three users made purchases that day: user_A paid $10, user_B paid $15, and user_C paid $30 first, and then another $5.
You need to calculate the following indicators:
- D7 retention;
- DAU 08.02.2015;
- Paying share from 01.02.2015 to 08.02.2015;
- Paying share 08.02.2015;
- Paying conversion 01.02.2015;
- Gross 08.02.2015;
- ARPU 08.02.2015;
- ARPPU 08.02.2015;
- Average Check 08.02.2015.