Sponsored By

5 cases of using the “Users by level” report

In March 2016, we, in devtodev, launched a new report called Users by level. The users liked it immediately, and I would like to talk about it in detail. This report will be useful for projects where each user has a level.

Eugene Matveev, Blogger

May 31, 2016

6 Min Read

In March 2016, we, in devtodev, launched a new report called Users by level. The users liked it immediately, and I would like to talk about it in detail.

As the name implies, this report will be useful for projects where each user has a level. It is basically games, but it's also great for those services, where the user passes some levels - for example, educational projects.
The report is based on the last date of user activity. For greater precision, you may add one more criteria - the date of the first login in application. Then you select the metrics to display - a total of nine, and in one report, you may select up to three most interesting:

  • Passed the level – the number of users who visited and passed the level;

  • Remaining on the level – the number of users who visited and didn’t pass the level;

  • Remaining + passed the level – the number of users who visited the level;

  • % of remaining users – percentage of users (from all who visited the level) that didn’t pass the level;

  • % of users passed the level – percentage of users (from all who visited the level) that passed the level;

  • Paid at level – the number of users who made at least one payment while visiting the level;

  • Paying share, % – the share of users who made at least one payment while visiting the level (from all who visited the level);

  • Gross, $ – total revenue from user payments, committed at this level;

  • ARPU – average revenue per user who visited the level.

How to use this report in practice? Below there are five possible scenarios.

The funnel of progress through the levels

Let’s choose the metrics Passed the level, Remaining on the level and % of remaining users. You will receive a funnel, where you can estimate the total number of people stuck at the level in absolute terms and as a percentage. It also shows how many users visited the level for the period reviewed. You will see how users react to the difficulty of the level in your project, where they prefer to stop and what is the levels distribution at the moment.

Do you see it? 14% of users do not even pass the first level - it seems to be not the difficulty of the level, but that the user didn't understand what is required of him, and not interested in the application.

But those who reach level 2, are almost certainly to pass it (the share of remaining on the level is less than one percent). The high share of remaining on the 4th and 5th levels is also very interesting.

Monetization efficiency of the levels

Let’s choose the metrics  Remaining on the level, Paying share, Gross.

This version of the report shows the current distribution of users through the levels, as well as revenue from each level and share of paying users. Knowing where the higher share of paying users is, you can better understand the behavior of users who bring you money. When do they decide to pay? What do they pay for? How much money does each level bring? These are the questions to be answered with the help of the report.

As seen on the screenshot,  levels 1 and 2 do not make money at all, and it is logical as most likely the user doesn't need to pay the project yet.

The main revenue is brought from levels 7 to 17, and the task of the developer is to ensure the maximum flow of users at these levels. For example, a lot of players remain on 3-4 levels and it is necessary to force them pass on to the further levels to increase the revenue.

Cohort analysis by the levels

Changing the filter of Install date in the report, we may select the users registered in the project at different times.

For example, it is necessary to compare the distribution of levels for the two cohorts of users registered a week ago and two weeks ago. Thus, we will be able to track the dynamics of flow through levels and predict where will remain the users registered a week ago.

See how distribution of levels differ for users registered two weeks ago and a week ago. The older users are already distributed through the levels from 3 to 10, while the newcomers still remain on levels 1 to 4.

You can build a model of flow of users from level to level and, with the knowledge of ARPU for each level, be able to predict the flow of money into the project for a week (or more) in advance.

Efficiency of devices / countries / languages

Clicking on the "All users" button allows to filter users by various parameters and build a report not for all users, but for the selected segments.

For example, you may select the users of Galaxy versions S3 and S4 (and their modifications) and compare them with the users of Galaxy versions S5 and S7. Thus it is possible to estimate the number of users from different devices (to know what devices to give priority while optimization), and efficiency - for example, what devices have higher ARPU.

Updating the application versions

Apply filters to the Install date, choose user level distribution metrics, build the report on two versions of the application for one and the same period:

Have all users updated from version 2 to version 3? Let's build a report on version 2:

Now on version 3:

We see that 452 users are on version 3, and 35 users are on version 2 (7% of the total audience). This means that 93% of the audience has already updated the version of the application. Besides, perhaps, you should also take care of the users of version 2, as they didn't forget about your application and continue to pass the levels.

Game levels are important in the game analysis and player behavior analysis. In a sense, the presence of level in the project gives a significant advantage for the analysis - it is possible to study in detail the behavior of the players, their dynamics in the project, the factors affecting the monetization. And this means - you are able to make more accurate, effective and balanced decisions for the development of the project.

 

 

Read more about:

2016Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like