Minimal viability for mobile applications
One of the most popular ideas that has emerged 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 product with a minimum functionality that allows users to receive feedback. But is it possible to transfer this concept to the sphere of mobile applications, and if not, is there an alternative? We in Alconost have translated an excellent article that answers this question. Anyone who deals with mobile development is a must-read.
My experience shows that, in the world of mobile freemium applications, the strategy of a minimally viable product is not always applicable - this concept is not best transferred 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, hardware more strongly than on the web, 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 separately. 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 sites. It is unreasonable to introduce changes into the product one by one - users will simply run away due to constant downloads of new and new updates. And to measure the impact of such changes, get ready for many days to wait for the publication of a new release.
')
In order for a minimally viable product methodology to work for a mobile, developers must be familiar with a portfolio of indicators that provide a more accurate view of the product. These are minimum performance indicators (minimum viable metrics) - the minimum set of priority indicators that are monitored since the launch of MVP and are constantly improving with each strategic, albeit slow, iteration. The model of minimum performance indicators integrates analytics into the concept and strategy of product development, and also includes minimum analytics into launch requirements.
For mobile applications, there are four groups of indicators, including those that speak of minimal efficiency: user retention, monetization, involvement, and virality. As for me, user retention is the most important group of indicators. The priority of the remaining ones may vary depending on the type of application being developed. I am confident that the prioritization of what is planned to be done within the iteration must be flexible and based on current indicators. Priority is given to issues that provide the best ROI (return on investment).
1.1. Hold on days 1–7, day 14, day 28, day 90 and day 365
When I say "N-th day", I mean the percentage of users who returned to the application on the N-th day. For example, a 50% hold on day 1 means that 50% of users returned to the application the day after it was installed.
As I wrote, I consider user retention to be the most important indicator (more precisely, a group of indicators) for mobile developers to track for two reasons:
1) retention of users allows you to calculate the approximate duration of use of the application for calculating the income from the user, and an understanding of this indicator (or, at least, an attempt to make it competently realistic) 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 is fulfilling its main usage scenario. It makes no sense to try to improve other indicators with low user retention.
I expect to keep 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, then retention rates on the 1st day and on the 2nd day will be, respectively, 50% and 40%. In this sense, the indicator looks 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 user retention rates specifically improve on days after a certain point.
I monitor user retention on the 28th day, not on the 30th, because the 28th day takes into account the weekly cycle of use, which sometimes allows us to reveal interesting features of individual days of the week. I place all indicators of user retention on one graph in the form of line diagrams with the ability to control the display of each of them. I place today's indicators in such a way that, with movement along the X axis to the current date from left to right, the indicators would drop to 0 (because counting users' retention on day 7 for yesterday is impossible).
I discussed a strategy for improving user retention in this article , but I believe that, in general, confident retention rates are achieved by conveying quality and depth in the early stages of using the application, mastering repeated engagement in the main loop at subsequent stages and providing sufficient 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 users per day (DNU)
The number of people who installed and opened the application on a particular day.
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 follow this indicator daily and calculate it as total revenue per day divided by the number of users who used the application on that day (DAU). If you track it for the day, ARPU will coincide with another widely used indicator ARPDAU, but they diverge if you calculate ARPU for a longer period.
2.3. Average income per player (ARPPU)
I follow him the same way as for ARPU, and calculate it as a total income divided by the number of users who have made in-game purchases.
2.4. Conversion
Tracked daily. This is the percentage of users who have made in-game purchases. I do not track advertising "conversion", the conversion rate takes into account only in-game purchases.
3.1. Average and median duration of sessions
I track the median session length, as I prefer not to remove sigma values> 3 from the data set. Shorter or longer session lengths are a good indicator of changes in advanced user engagement. This indicator is tracked by day.
3.2. Average and median number of sessions
Tracked and visualized in the same way as the duration of the sessions.
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 about the sources of entry into the application store. But it seems to me that the assessment of the K-factor is important, because virality increases the payback of paid user engagement .
If an application is integrated into a social platform like Twitter or Facebook (as probably should be the case, if appropriate), tracking “social” invitations is a simple task. This article describes some of the lost opportunities at startup and in the Vine early development strategy that no single mobile application development project manager should miss.
The most time-consuming part of implementing these metrics in the MVP development environment can be an internal “sale” of an idea. It can be an unpopular proposition in small teams that fear corporate bureaucracy, which slows down the creative process and blurred the vision of the most breakthrough applications.
But I still believe: the best answer is that methods can (and should) be destroyed, as well as product verticals. The “lean startup” methodology is effective in the case of the web, but needs some work to be done on mobile platforms, given the fundamental differences between the platforms. Developing applications for mobile devices requires more reliance on data and less on intuition when designing.
The point of this post is to give a starting point for the development of 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 idea of ​​the layout and formatting of 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
The article is translated in Alconost.
Alconost is engaged in the localization of applications, games and websites in 60 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.
We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.
Read more: https://alconost.com
My experience shows that, in the world of mobile freemium applications, the strategy of a minimally viable product is not always applicable - this concept is not best transferred 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, hardware more strongly than on the web, 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 separately. 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 sites. It is unreasonable to introduce changes into the product one by one - users will simply run away due to constant downloads of new and new updates. And to measure the impact of such changes, get ready for many days to wait for the publication of a new release.
')
In order for a minimally viable product methodology to work for a mobile, developers must be familiar with a portfolio of indicators that provide a more accurate view of the product. These are minimum performance indicators (minimum viable metrics) - the minimum set of priority indicators that are monitored since the launch of MVP and are constantly improving with each strategic, albeit slow, iteration. The model of minimum performance indicators integrates analytics into the concept and strategy of product development, and also includes minimum analytics into launch requirements.
For mobile applications, there are four groups of indicators, including those that speak of minimal efficiency: user retention, monetization, involvement, and virality. As for me, user retention is the most important group of indicators. The priority of the remaining ones may vary depending on the type of application being developed. I am confident that the prioritization of what is planned to be done within the iteration must be flexible and based on current indicators. Priority is given to issues that provide the best ROI (return on investment).
User retention rates
1.1. Hold on days 1–7, day 14, day 28, day 90 and day 365
When I say "N-th day", I mean the percentage of users who returned to the application on the N-th day. For example, a 50% hold on day 1 means that 50% of users returned to the application the day after it was installed.
As I wrote, I consider user retention to be the most important indicator (more precisely, a group of indicators) for mobile developers to track for two reasons:
1) retention of users allows you to calculate the approximate duration of use of the application for calculating the income from the user, and an understanding of this indicator (or, at least, an attempt to make it competently realistic) 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 is fulfilling its main usage scenario. It makes no sense to try to improve other indicators with low user retention.
I expect to keep 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, then retention rates on the 1st day and on the 2nd day will be, respectively, 50% and 40%. In this sense, the indicator looks 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 user retention rates specifically improve on days after a certain point.
I monitor user retention on the 28th day, not on the 30th, because the 28th day takes into account the weekly cycle of use, which sometimes allows us to reveal interesting features of individual days of the week. I place all indicators of user retention on one graph in the form of line diagrams with the ability to control the display of each of them. I place today's indicators in such a way that, with movement along the X axis to the current date from left to right, the indicators would drop to 0 (because counting users' retention on day 7 for yesterday is impossible).
I discussed a strategy for improving user retention in this article , but I believe that, in general, confident retention rates are achieved by conveying quality and depth in the early stages of using the application, mastering repeated engagement in the main loop at subsequent stages and providing sufficient 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 users per day (DNU)
The number of people who installed and opened the application on a particular day.
2. Monetization indicators
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 follow this indicator daily and calculate it as total revenue per day divided by the number of users who used the application on that day (DAU). If you track it for the day, ARPU will coincide with another widely used indicator ARPDAU, but they diverge if you calculate ARPU for a longer period.
2.3. Average income per player (ARPPU)
I follow him the same way as for ARPU, and calculate it as a total income divided by the number of users who have made in-game purchases.
2.4. Conversion
Tracked daily. This is the percentage of users who have made in-game purchases. I do not track advertising "conversion", the conversion rate takes into account only in-game purchases.
3. Indicators of engagement
3.1. Average and median duration of sessions
I track the median session length, as I prefer not to remove sigma values> 3 from the data set. Shorter or longer session lengths are a good indicator of changes in advanced user engagement. This indicator is tracked by day.
3.2. Average and median number of sessions
Tracked and visualized in the same way as the duration of the 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 about the sources of entry into the application store. But it seems to me that the assessment of the K-factor is important, because virality increases the payback of paid user engagement .
If an application is integrated into a social platform like Twitter or Facebook (as probably should be the case, if appropriate), tracking “social” invitations is a simple task. This article describes some of the lost opportunities at startup and in the Vine early development strategy that no single mobile application development project manager should miss.
How to "sell" minimum performance indicators
The most time-consuming part of implementing these metrics in the MVP development environment can be an internal “sale” of an idea. It can be an unpopular proposition in small teams that fear corporate bureaucracy, which slows down the creative process and blurred the vision of the most breakthrough applications.
But I still believe: the best answer is that methods can (and should) be destroyed, as well as product verticals. The “lean startup” methodology is effective in the case of the web, but needs some work to be done on mobile platforms, given the fundamental differences between the platforms. Developing applications for mobile devices requires more reliance on data and less on intuition when designing.
The point of this post is to give a starting point for the development of 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 idea of ​​the layout and formatting of 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
The article is translated in Alconost.
Alconost is engaged in the localization of applications, games and websites in 60 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.
We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.
Read more: https://alconost.com
Source: https://habr.com/ru/post/249445/
All Articles