Minimum viability indicators for mobile applications

Original author: Eric Benjamin Soyfert
  • Transfer
One of the most popular ideas that has appeared in the development industry in recent years is the concept of Minimum Viable Product, abbreviated MVP. In a nutshell, this is a strategy for developing a minimum product functionality that allows you to get feedback from users. But is it possible to transfer this concept to the sphere of mobile applications and if not, is there an alternative? We at Alconost have translated an excellent article that answers this question. Everyone who deals with mobile development is a must-read. My experience shows that in the world of mobile freemium applications, the strategy of a minimum viable product



not always applicable - this concept is not well ported to mobile platforms. After all, it was developed for a web platform that allows instant and universal distribution of product versions. On mobile platforms, this is not possible. In addition, due to the different quality of mobile devices, “iron” is stronger than on the web and affects the user experience of the application on mobile platforms (especially in the gaming field).

Mobile application developers should not waste time studying the effects of each change in a product individually. Why? Due to the variety of devices, due to the need to download new versions (which leads to a large number of active versions at the same time), due to the delay between downloading and publishing in some stores. It’s unreasonable to introduce changes into the product one at a time - users will simply scatter due to constant downloads of newer and newer updates. And in order to measure the impact of such changes, get ready for many days to wait for the publication of a new release.

In order for the minimum viable product methodology to work for mobile, developers should be familiar with a portfolio of indicators that provide a more true picture of the product. itminimum viable metrics - the minimum set of priority indicators that are monitored since the launch of MVP and are constantly improved with each strategic, albeit not quick, iteration. The model of minimum performance indicators embeds analytics in the concept and strategy of product development, and also includes minimal analytics in the requirements for launch.

For mobile applications, there are four groups of indicators, including those that show minimal effectiveness: user retention, monetization, engagement and virality. As for me, user retention is the most important group of indicators. The priority of the remaining may vary depending on the type of application being developed. I am sure that the prioritization of what is planned to be done within the iteration should be flexible and based on current indicators. Priority should be given to issues that provide the best ROI (return on investment).

User retention rates


1.1. Retention for days 1–7, day 14, day 28, day 90, and day 365
When I say “N day”, I mean the percentage of users who returned to the application on the N day. For example, keeping on the 1st day at 50% means that 50% of users returned to the application the day after its installation.

As I already wrote, I consider user retention to be the most important indicator (more precisely, a group of indicators) for tracking by mobile developers for two reasons:

1) user retention allows you to calculate the approximate duration of using the application to calculate user revenue, and understanding this indicator (or at least trying to competently realistic estimate it) is the only way to attract users while maintaining a positive financial result;

2) user retention reflects their “satisfaction”: this is an indicator of how well your application fulfills its main usage scenario. It makes no sense to try to improve other indicators with low user retention.



I expect retention of users on a retrospective basis, that is, the ratio of retention on the N-th day with the day of registration of users. Thus, if 100 users joined today, 50 returned tomorrow and 40 the day after tomorrow, the retention rates on the 1st day and on the 2nd day will be, respectively, 50% and 40%. In this sense, the indicator is "looking back." This approach makes it easier to track improvements in connection with new versions (or launches of new features), because the developer can see how specifically the user retention rates by day after a certain point are improved.

I track user retention on the 28th day, and not on the 30th, because the 28th day takes into account the weekly use cycle, which sometimes allows me to identify interesting features of individual days of the week. I place all the user retention indicators on one chart in the form of line charts with the ability to control the display of each of them. I arrange today's indicators so that with movement along the X axis to the current date from left to right, the indicators fall to 0 (because counting user retention by 7 days for yesterday is not possible).

The strategy for improving user retention rates was discussed in this article., but I believe that in general, confident retention rates are achieved by delivering quality and depth in the early stages of using the app, harnessing repeat engagement in the main cycle in subsequent stages, and providing enough content to satisfy the most enthusiastic users in the later stages.

1.2. Daily Active Users (DAU) The
number of people who use the application on a particular day.

1.3. New Daily Users (DNU) The
number of people who installed and opened the application on a specific day.

2. Monetization rates


2.1. Income
I track income on a daily basis and share by source: in-app sales and advertising. As a result, I get a composite line chart.

2.2. Average user revenue (ARPU)
I monitor this indicator daily and calculate it as the total revenue for the day, divided by the number of users using the application on that day (DAU). If you track it for a day, ARPU will coincide with another widely used indicator ARPDAU, but they diverge if you calculate ARPU for a longer period.

2.3. Average revenue per gaming user (ARPPU)
I follow him as well as ARPU, and I calculate it as the total revenue divided by the number of users who made in-game purchases.



2.4. Conversion
Tracked daily. This is the percentage of users who have made in-game purchases. I don’t track the advertising “conversion”, the conversion rate takes into account only in-game purchases.

3. Engagement rates


3.1. Average and
Median Session Duration I track the median session duration because I prefer not to remove sigma values> 3 from the dataset. Shorter or growing session duration is a good indicator of changes in the engagement of experienced users. This metric is tracked by day.

3.2. The average and median number of sessions is
tracked and visualized in the same way as the duration of sessions.

4. Indicators of virality


4.1. K-factor
This is the average number of additional users that each user leads. For applications, this is very difficult to calculate, since mobile platforms do not take into account almost any data on the sources of access to the application store. But it seems to me that the assessment of the K-factor is important, because virality increases the return on paid user acquisition .

If the application is integrated into a social platform like Twitter or Facebook (as, probably, it should be in appropriate cases), tracking “social” invitations is a simple task. In this article we describe some of the missed opportunities at the start and in the early development of the strategy Vine, which should not miss any one manager of mobile application development projects.

How to "sell" minimum performance indicators


The most time-consuming part of implementing these metrics in the MVP development environment may be the internal “sale” of the idea. It can be an unpopular offer in small teams that fear a corporate bureaucracy that impedes the creative process and erodes the vision of the most breakthrough applications.

But I still believe: the best answer is that the methods can (and should) be destroyed, as well as the product verticals. The lean startup methodology is effective in the case of the web, but needs refinement for use on mobile platforms, given the fundamental differences between the platforms. Mobile app development requires more relying on data and less on intuition in design.

The point of this post is to provide a starting point for developing an analytics initiative for a minimally viable mobile product. For this, I also created a control panel template (source code here ), which will give some visual representation of the layout and formatting of the tables. All data is randomized, but technical indicators can be used by editing the function that calculates the data in the template.


About the translator

Translation of the article was done in Alconost.

Alconost localizes applications, games and sites in 60 languages. Native translators, linguistic testing, cloud platform with API, continuous localization, project managers 24/7, any format of string resources.

We also make advertising and training videos - for sites that sell, image, advertising, training, teasers, expliner, trailers for Google Play and the App Store.

Read more: https://alconost.com


Also popular now: