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 application 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 - to make 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 devtodev SDK.
So, one day users have installed the application 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 the new users (or 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 be increased 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, there is becoming more and more of the new users, and at some point you will want to know how many users have sampled your application. For this purpose there is a metric Total Users, it shows how many users of your application are in the database to the chosen date.
Users who have launched your application for the first time either like it or not. If the user does not like the app, he most likely leave it and not come back the next day.
If the user returns to the application 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 1-day retention. This indicator should be followed in the dynamics 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 next day 1-day retention react and rise. Users are not acquired easy nor cheap, and it is wrong to lose them the next day, so always optimize this indicator.
The percentage of users who returned in 7 days after the first visit, is called 7-day retention. Finally, if the users returned in 28 days after the first visit, the percentage of such users is called 28-days retention. And there it gets serious. You may assume that users are really interested in your application, if they remain faithful even after 28 days.
In an ideal situation, all three indicators of retention 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 he may leave and optimize these bottlenecks. You may get assisted by the user segments, events and funnels. All these tools help to identify the stages where the user is making decision about leaving.
To calculate the retention period of the other time frames (and 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 understand 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: advertising 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 accumulated. The number of the unique users that logged into your application 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, WAU - it is not the sum of DAU for 7 days, 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 he 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.
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 1000 users in the project, and each of them logs every day, then DAU, and MAU are equal to 1000, and the indicator of Sticky Factor equals 100%. If every user logged only once within a month, Sticky Factor equals only to 3.3%. The higher the number of this indicator, the more regular users log into your application.
It often happens that the indicators DAU, WAU and MAU vary considerably due to the unstable flow of new users. In order not to take 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 1-day 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. Firstly, it will point out for you the peak load of the server. Secondly, it will help to identify the optimum time when the application has the maximum number of users (for example, to send push-notifications). Thirdly, it's a well-known indicator to compare the popularity of several applications.
Every visit of the application by the user is called session, and Sessions metric indicates how many sessions were in the app within a period.
And if you divide the total length of all sessions by their number, you get the Average Session Length indicator, showing the average session length. Thus it is impossible say that the longer duration of the session is better than the short one. In applications for Taxi service, 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 applications for reading, the sessions are usually much longer.
The Lifetime metric shows how many days in an average user apply to the application from the first to the last launch. It is recommended to use this metric for the 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 user something that he is 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 (eg advertising 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 is 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.
So, the users decide to pay money for the purchase of the content within the application. The number of the unique users who pay per day (or per longer period) is shown in the Paying Users metrics.
The Paying Share metric shows the percentage of users from all unique users active over the period, who made the payments. Ideally, each user - paying and the Paying Share equals to 100%. In fact, this indicator is much less, and its growth by at least 1% is a great achievement for the project. According to Newzoo, in 2014 32% of all mobile game users made payments. 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 with sales.
The Paying Conversion metric, in turn, shows for each day (or a longer period), what percentage of paying users is among all those who have logged that day (period). As is the case with the Rolling Retention, try to find the leaps in the behavior of this indicator. Quite possibly, it will point out for you 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 repeated payments, then the Transactions by User equals to one.
The total amount of all payments of the users for the period is shown in 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 how much money in the average is gained by one player, while both are taken into account: paying and non-paying users. 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 for the "core". ARPU for 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 periods since the first launch. Generally, the longer a user in the project and the higher his level is, the higher is 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.
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 for these purposes the introduction of the new attractive content gets the most: more players begin to pay, and those who paid before start paying more to buy more attractive weapons. As a result, both the percentage of paying users and the average amount of payments increases for the period. In other words, Paying Share, ARPU, ARPPU grows.
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 repeated payments from the same paying user. If we assume that each paying user paid only once for the period, Average Check will be equal to ARPPU.
Finally, the last (but not the least) is the Lifetime Value (LTV) indicator. It shows how much money is spend by the average user at all time of the 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 his payments.
Lifetime Value is useful to determine the price of user acquisition. The rule is simple: Lifetime Value must be greater than the price of user acquisition, otherwise the business is not effective.
To maximize the 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 him is, the higher the LTV. The project must be liked by the user, then the lifetime, ARPU and after them LTV increases.
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 be truth, they are not only suitable for mobile applications, but also for online games, online shopping, elsewhere.
Follow the dynamics of indicators, 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 the most 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 the 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 payments 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:
- 7-day retention;
- DAU 08.02.2015;
- Paying Share с 01.02.2015 по 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.