Here you can see the example of the game analysis. Additionally we will see the reports on what you should pay attention when analyzing a game of the Match-3 genre.

Match-3 game has the following features:

1. The game consists of many levels, which are gradually unlocked. Unlocked levels can be completed several times. For example, if the player has access to 20 levels, after the 19th level they can go to the 5th or 10th level, and then return to the 20th level. In devtodev interface such levels are called locations.

2. Players have different resources, the balance of which can be changed when completing the level.

3. There are different bonuses / items in the game, which make it easier for the player to pass the game. These bonuses can be received for good results or bought using the in-game currency.

4. The in-game currency can be bought using the real money.

Event structure example

In addition to analyzing data in the main reports, you can integrate custom events to track and analyze specific user actions. You can use custom events to get an insight into how users use the application, which quests they accept, how often they interact with each other, which offers they open, and so on. You can also analyze custom event data in the Custom event report.

You can build a funnel and analyze conversion rates at each stage. For example, you send an event every time a user enters an in-game shop, clicks on an item, buys an item. Based on these events, you can build a funnel and check the conversion rate at each stage in the Conversion funnel report. Below you can find examples of events that may be useful to you.

Case example

Integration tips can be found in the integration section.

In the Game structure report we can see the current distribution by levels, income from each level and the share of paying users.

To begin with, let's see the distribution of users by levels in order to assess how many users have visited the level and at what levels the players are stuck. This will help us assess the complexity of the levels.

On the Player levels tab add these metrics to the report: Passed the level, Remaining on the level and % of remaining users.

At each of the first three levels we lose from 8.6% to 14.4% of users, most likely this is due to the fact that users were not interested in the game, not with the complexity of the level.

Now let's compare the distribution by level of two cohorts of the users who registered in the project at a different time. Let’s take users who registered a week ago and two weeks ago. We will track the dynamics of their flow by levels and predict where users who registered a week ago will be in a week.

It can be seen that users who registered two weeks ago are already distributed at all levels. Users who came in the previous week are focused on level 5. It is also clear that none of the players has reached level 10.

Now let's see monetization metrics by levels, in order to understand how much money each level bring to us. After analyzing the report, we understand the distribution of users by levels, the income that each level brings and the share of paying users:

The main income goes from level 9, this means that we should interest users who are at the entry levels. It is also clear that there is a peak in payments at level 6, most likely this is due to the fact that users see and buy a special offer.

Now we’ll build a report not in the terms of levels, but in the game locations (Locations tab). During a certain attempt to complete a level, the users may change various numerical indicators: resources, game currency, etc. The report will show the distribution of players by locations and user flow in these sections. We can track the change in any numerical parameter of the location in terms of successful or unsuccessful attempt (these can be steps, health units, boosters, etc.).

Analysing monetization

Conversion to payments

The goal is to have paying users who will return to the game as often as possible. To do this, we must analyze Retention. We will analyze it a little bit later, but for now let's see what is our Conversion to the first payment. The Conversion to payments report will help us with this.

We can compare the conversion to the first payment by applying to the report the segments of users who pass the tutorial and those who missed it. It is possible that users whom we brought to the store during the tutorial pay us more and more often than users who refused to study.

Segmentation can be applied to all reports, see the data in the context of various events and in the context of users. Using user segmentation allows you to get more insights from reports.

Let's see how quickly users begin to pay: at the first day or a few days after installation when they better understand the game. So we can determine which day it is worth planning marketing activities to increase the likelihood of payment.

The graph shows that the majority of the first payments are made in the early days, which means we can show users a special offer almost immediately.

It is clear with the first payment, but it’s also important to ensure that users who make the first payment do not stop there. Let's see if the users continue to make subsequent payments, because often repeated payments bring more income, which we could see in the table above. In the same Conversion to payments report, we analyze the conversion to subsequent payments:

RFM analysis

After that, we should look at the structure of paying users to evaluate how often, how long and how much users have paid us, we can see it in the RFM analysis report.

• The segment Can’t Lose Them. These customers made the biggest purchases, and made them often. But they haven’t returned for a long time. Try to win them back by offering them renewals or newer offers, features. There is a chance to lose them to competition, try talking to them.

• Loyal Customers. Customers who spend often good amounts of money. They are responsive to promo activities. Try to upsell higher value products. Ask for reviews and think how you can engage them.

• Сhampions. Customers who bought recently, buy often and spend the most money. Try to reward them. These customers can be early adopters for new offers and features. They will promote your app.

• At Risk. These customers spent big sums of money and made purchases often but a long time ago. You need to bring them back. Try to reconnect with customers by sending them personalized push notifications, offering renewals, and providing helpful resources.

• Need Attention. Customers in this segment have above average recency, frequency and monetary values. They may not have made purchases very recently though. Try making time limited offers, recommend based on past purchases, and reactivate them.

• Potential Loyalists. These are recent customers who spent a good amount and made purchases more than once. Try offering membership or loyalty programs, and recommend other products.

• Hibernating. Last purchase by these customers was a long time ago. They are low spenders and have a low number of orders. Try offering them other relevant products and special discounts. You can also promote new features and modes.

• About To Sleep. Customers have below average recency, frequency and monetary values. You will lose them if they remain not reactivated. Try sharing valuable resources, recommend popular products, renewals at discount, and reconnect with them.

• Promising. These customers are recent payers but they haven’t spent much. Try making time limited offers and persuade them to use the app more frequently.

• New Payers. These users have just converted to payers. Try engaging them to use the app more frequently and give them bigger discounts.

Gross structure

Now let's look at the structure of our audience in the Gross structure report, segmenting it into beginners and oldies. Our audience is divided into six segments by the registration time:

It can be seen that we are dominated by old users. Perhaps, it’s worth attracting new traffic to our game. With an increase in traffic, the number of paying audience also increase.

If there were more new users, it would be worth thinking about retaining new users.

We figured out the structure of the audience. Let's see what happens with the dynamics of paying users:

The graphs show that users who register 1 months ago and earlier pay less and less. This may indicate an oversupply of currency. You can also notice the uneven distribution of income from beginners, most likely, at the peak there was a campaign for beginners. Perhaps it is worth concentrating marketing communications specifically on new users.

And at what level do users start paying us? Let's go back to the Conversion to payments report and see at what level the user most often makes the first and the second purchases:

Thanks to this information, we understand when to motivate the user to buy.

Economy balance

Let’s evaluate how the game economy is balanced at each level. Let's go to the Economy balance report, it will show the average and total accumulations, purchases, expenses and earnings for each game’s level.

Analysing retention

Now let's see check retention:

We will check the traffic to see if we buy that users that we need. The Basic Metrics will help us with the traffic analysis.

The report shows that traffic from google adwords has a downward trend line, on the contrary, organics are growing. Users from different sources perceive our game differently.

It is also worth to segment reports when analyzing by platform, traffic sources, country, version and other criteria, as the behavior of different categories of users may differ.

We will check what is our game’s retention, whether it’s always been at this level. Let’s go to the Engagement dashboard or Basic Metrics.

We see that retention has begun to decline, but maybe the problem is not in all versions of the game. Cohort analysis and App versions analysis will help with this. In the App versions analysis, we will see the audience, the distribution of users across all versions of the game, how they go through the tutorial, users’ deduction and the amount of payments by game’s version.

In the Cohort analysis we compare the behavior of different cohorts with different registration dates. Let's see how cohort / segment retention rates change, what is the average check and other metrics:

What kind of retention do we need to check?

Short-term retention

If the problem is with short-term retention, the Tutorial analysis reports will help us.

Medium-term retention

How are things going with medium-term retention? Let’s take a look at the report on levels’ difficulty. We should go to the Game structure report:

Long-term retention

What about long-term retention? First, let’s take a look at the Cohort analysis report:

We can also build a sequence of users’ actions, for example to see what they do after a push about a new event in the game. To do this, go to the User flow report and set the event from which we want to build the analysis:

To analyze whether users enter events, watch ads, interact with other users, add friends and etc., you should go to the Custom events report:

Last actions before churn

The goal of each game developer is to keep users in the app as long as possible and try to understand the reasons why they churn to prevent it.

That is why we try to find out which actions users do before they leave the app. For an analytical platform, it can’t be calculated because when the user stops using the app, the connection with SDK is lost and it can’t send any events to the platform.

But still, you can use several ways to learn about the actions of these users.

To see which events prevented churn:

1. Choose Churn in the Event dropdown menu.

2. Choose Flow direction – to the event.

3. Select basic and custom events for the report.

After you build the report, you will see the most recent event that leads to the Churn. If you want to see more previous events, just tap the event to expand it.

Raw data export

Export Custom events and Sessions there.

After that, do the following:

1. Using the Sessions data, find the time of the last session of the user and select only users who churned (e.g. whose last session was 3 days ago).

2. Merge information about all custom and basic events and find the last event of the user.

3. Link both tables by the devtodev ID field to find out what was the last event.

SQL Wizard

1. Select in one query the Last_Seen parameter in the Users table and Date parameter in each event table.

2. Find the most recent event for each user and filter the list by the Last_Seen date to choose only users who churned.

Users

1. Filter users by the Last seen parameter which is calculated automatically. You can also add more filters to specify those users you want to explore.

2. After you apply the filter, you will see the list of users. Open their card to see the Last user activity tab. There will be the latest events that were performed by the user.

50-100 users will be enough to find patterns in their behavior.

Using these ways you can explore the last user's activity in the game. All of them have advantages and disadvantages, but please note that sometimes the last event alone is not enough to understand the reasons for churn. Especially if you use a lot of custom events in research. As a result, you can get meaningless events, such as Open the Settings tab, View the chat, etc. That is why it is better to check more events at once to see the whole picture.

A/B Tests

It is necessary to take A/B tests during the development stage. So how is it possible to make A/B tests on the devtodev platform?

Here you can find the manual on how to run A/B tests in devtodev:

Here you can see the example of the game analysis. Additionally we will see the reports on what you should pay attention when analyzing a game of the MMO genre.

Event structure example

In addition to analyzing data in the main reports, you can integrate custom events to track and analyze specific user actions. You can use custom events to get an insight into how users use the application, which quests they accept, how often they interact with each other, which offers they open, and so on. You can also analyze custom event data in the Custom event report.

You can build a funnel and analyze conversion rates at each stage. For example, you send an event every time a user enters an in-game shop, clicks on an item, buys an item. Based on these events, you can build a funnel and check the conversion rate at each stage in the Conversion funnel report. Below you can find examples of events that may be useful to you.

Case example

User level is the main indicator of the user's progress in the game. The player constantly raises his level, improves and achieves new skills and currency. Therefore, we should look at the all in-game economy reports in the context of levels.

First of all, it is worth analyzing the in-game currency, the dynamics of its spendings and savings. Let’s go to the Virtual goods & purchases report. We can see the most popular products in terms of levels and time.

It is also important to know what the players’ shopping basket consists of and how it changes depending on the level. We will go to the Purchases structure report.

Let's see how the demand for certain products varies at the given levels or in time:

Let’s analyze which products’ prices we can change. Let's move on to the ABC/XYZ-analysis for our virtual goods, it allows us to identify categories of goods where we can easily change the price (sub-segments BY, CY, BZ, CZ).

The report shows that the goods bomb, picker, XBomb are bringing to the game the most money and they have the most stable demand, it is better not to experiment with them. On the other hand, you can experiment with pricing and stocks on products from the CZ segment.

The gameplay of this genre revolves around developing your farm/land/city, etc. A player has to gather various resources and then use them to build and expand his territory. They can also buy new buildings and complete tasks to level up. Often the game has a mechanic that allows for spending currency on speeding up the production of certain items.

Necessary Basic events

Basic events allow you to analyze your game as described in this example.

To make the analysis more smooth and productive, we recommend you to use the following basic events:

LevelUp and CurrencyAccrual for analyzing distribution of players among levels and balance as well as movement of in-game currency among levels.

Tutorial Step for tracking tutorial completion to find stages where users drop off of the app or skip tutorial altogether because he is familiar with all the mechanics of farming games.

Real Payment for building financial reports and calculating basic financial metrics: revenue, ARPU, ARPPU, paying share, transactions, etc.

Virtual Currency Payment for tracking in-app purchases made with virtual currency and evaluation of in-game economy. In this event, as a purchasing vehicle you can use not only hard currency, but also energy that the player spends on resource collection. Then you can open the In-game analysis section and analyze energy collection and spending by levels as well as the most popular sources and sinks of energy:

Important reports needed for analysing a farm game.

We should analyze the in-game currency, the dynamics of its spending and saving. Go to the Virtual goods & purchases report. Let's see which products are the most popular in terms of levels and time.

It is also important to know what a player’s shopping basket is composed of and how it changes depending on the level. For this we open the Purchases structure report:

Let's see how the demand for certain items changes at the given levels or over time:

Custom event structure example

Besides out-of-the-box reports based on basic events, you can use custom events to analyze how users are using your app – the most desirable actions, quests, live ops events, whether or not users invite friends, interact with new mechanics, etc. You can also analyze custom event data in the Custom event report.

You can build a funnel and analyze conversion rates at each stage. For example, you send an event every time a user enters an in-game shop, clicks on an item, buys an item. Based on these events, you can build a funnel and check the conversion rate at each stage in the Conversion funnel report. Below you can find examples of events that may be useful to you.

In the table below you can find examples of custom events that can be useful for you:

Let’s look at a case of an RPG game (role-playing game) where players control one or more characters that have their own characteristics and peculiarities. During the gameplay parameters of characteristics change that lead to leveling up of the player account. You can use the LevelUp event with CurrencyAccrual to track changes in currency amount and player character levels. Level tracking allows you to analyze the number of players as well as amount and movements of in-game currency on each level. We also recommend you to integrate other basic system events. See the game analysis example to find some application methods.

Event structure example

Besides using out-of-the-box reports that are based on basic events, you can use custom events that will help you get an idea of how users use the application. For example, you can find out how and where gamers acquire new player characters, with which characters they engage into combat, how often their characters level up, what quests they finish, whether or not they engage in live ops events, invite friends, use new game mechanics, etc.

After that you can use the Custom Events and Conversion Funnels reports to analyze custom event data. Build a funnel and analyze conversion rates at every stage, e.g. you dispatch an event every time a user opens an in-game shop, clicks on an item and buys the item. Below you can find examples of custom events that can be useful for you:

Here you can see the example of the game analysis. Additionally we will see the reports on what you should pay attention when analyzing a game of the hyper-casual genre.

Event structure example

In addition to analyzing data in the main reports, you can integrate custom events to track and analyze specific user actions. You can use custom events to get an insight into how users use the application, which quests they accept, how often they interact with each other, which offers they open, and so on. You can also analyze custom event data in the Custom event report.

You can build a funnel and analyze conversion rates at each stage. For example, you send an event every time a user enters an in-game shop, clicks on an item, buys an item. Based on these events, you can build a funnel and check the conversion rate at each stage in the Conversion funnel report. Below you can find examples of events that may be useful to you.

Case example

There are often many levels in hyper-casual games that gradually unlock. An attempt to pass the level can be both successful and unsuccessful. Moreover, it can affect on the player’s numerical indicators: currency, number of boosters, etc. Therefore, firstly we analyze the distribution of users by levels. So we will understand how many users visited the level, how many of them got stuck and at which level.

In-game analysis reports

On the Player levels tab add these metrics to the report: Passed the level, Remaining on the level and % of remaining users.

At each of the first three levels we lose from 15,6% to 45.41% of users, most likely this is due to the fact that the user was not interested in the game and not with the complexity of the level.

Now we’ll build a report not in the terms of levels, but game locations (Locations tab). During a certain attempt to complete a level, the users may change various numerical indicators: resources, game currency, etc. The report will show the distribution of players by locations and user flow in these sections. We can track the change in any numerical parameter of the location in terms of successful or unsuccessful attempt (these can be steps, health units, boosters, etc.).

Remember to apply segmentation to the reports. It is possible that users who come from different sources go through levels differently. Most likely, user payments are also differ. Segmentation can give new insights for your game.

Engagement reports

It will also be useful to monitor the users’ flow. Go to the Churn Rate report in the Engagement section. We can take actions to reduce the users’ flow to a minimum after analyzing at what day the majority of players fall off.

Games of this genre often have short game sessions, that means we should pay attention to the frequency of sessions. The frequency of sessions can tell us about the user’s interest and the habit of using the game. We’ll go to the Sessions report. We’ll evaluate the frequency of sessions using the Number of sessions metric.

If necessary, we can also evaluate the length of sessions by selecting the Session duration metric.

Here you can see the example of the game analysis. Additionally we will see the reports on what you should pay attention when analyzing a game of the social casino genre.

Event structure example

In addition to analyzing data, in the main reports, you can integrate custom events to track and analyze specific user actions. You can use custom events to get an insight into how users use the application, which quests they accept, how often they interact with each other, which offers they open, and so on. You can also analyze custom event data in the Custom event report.

You can build a funnel and analyze conversion rates at each stage. For example, you send an event every time a user enters an in-game shop, clicks on an item, buys an item. Based on these events, you can build a funnel and check the conversion rate at each stage in the Conversion funnel report. Below you can find examples of events that may be useful to you.

Case example

First of all, we must evaluate the movement of currency among players in order to understand the demand for virtual goods. After that we will be able to maximizing the income of the game: balance and optimize the demand, organize discounts, promotions and events.

We’ll go to the Economy balance report to see at what levels players buy, earn, spend and how the game’s balance generally changes. We can track the number of spins and coins, both in absolute numbers and on average by players.

We should analyze the in-game currency, the dynamics of its spendings and savings. Go to the Virtual goods & purchases report. Let's see which products are the most popular in terms of levels and time.

It is also important to know what the players’ shopping basket consists of and how it changes depending on the level. We will go to the Purchases structure report.

Let's see how the demand for certain products varies at the given levels or in time:

Let's take as an example the case of two projects: A and B, each of which has just been released to the market and acquires new users.

Project A has attracted 100 users, while the project B has attracted 60 users. Which of the projects is better? Far it seems that A (and so far this is true), but let's also take a look at more acquisition metrics, and not make final conclusions yet.

Let’s add another sentence to our example. Project A received from its users $300, and their acquisition cost was $200 (Installs cost). Project B received from its users $200, and the acquisition cost was $100.

Let’s calculate the CPI for both projects:

А: CPI = Installs cost / Installs = $200/100 = $2 - this is the average price project A acquired one person for.

B: CPI = $100/60 = $1,67. For Project B one user is less expensive than for the project A.

Now let’s calculate ARPU. For project А: ARPU = Gross / Installs = $300/100 = $3 - this is the average revenue from one user for project A. For project B: ARPU = $200/60 = $3,33.

Finally, let’s calculate the ROI for both projects. ROI = Gross / Installs cost.

For A: ROI = $300/$200 = 150%.

For B: ROI = $200/$100 = 200%.

It turns out that project B, although it attracted fewer users, they brought more money on the average, the buying costs paid off twice while project B acquired users at a lower price.

Let’s add one more sentence to our example.

Let's say, from the first entry in project A 30 days passed, and in Project B - 90 days. Recall, ROI (A) = ROI (A) = 30 to 150%, ROI (B) = ROI (B) = 90 to 200%. This explains the fact that project B looks more successful for now. To compare the quality of traffic, let's compare ROI for the same period of time.

Assume, ROI (B) = 30 to 100%, while the ROI (A) = 30 to 150%.

We conclude that traffic from project A has all chances to become more efficient than traffic from Project B, if the dynamics of ROI continue.

But in any case, it should be said that traffic in both projects is good enough and effective as in both cases, the ROI is more than 100%.

Basic metrics

The reports in the devtodev system are universal and suitable not only for games but also for detailed analysis of non-gaming applications. The system enables you to analyze both the main project metrics: DAU / MAU / WAU, retention, and monetization metrics like income, ARPU, ARPPU, as well as to conduct a more detailed analysis of user behavior.

The Real-time dashboard shows key metrics of the current day compared to the previous day. It helps you to keep track of your app’s performance in real time. The report allows you to quickly track changes in the application audience: New users, Cumulative new users, Sessions, Cumulative sessions, Users online. It also allows you to compare today’s indicators of Gross, Cumulative gross, Top countries (by new users or by gross) with yesterday’s.

Thus, you can get live data reports and observe the performance of important project indicators. The information in the report is updated every five minutes.

Acquisition reports

You can analyze the effectiveness of user acquisition. Acquisition reports answer the following questions: how many users each channel brought, which one is the most profitable, how many users keep using the application after a day, a week, two, etc. and when will this traffic pay off. You can integrate traffic attribution services such as Adjust, Appsflyer, Tune, Branch, Kochava, and Tenjin to get install information.

Monetization

The reports in the Monetization section give information about the key monetization metrics of your project. For example, you can monitor the dynamics of ARPU, Paying share, ARPPU, Gross. You can also find useful information about users’ repeated purchases and the time between purchases. You can find out on which day users make purchases in your application more often and use an offer to nudge them to buy on that day.

You can also study the structure of your paying audience and income from a perspective of the time that has passed since the installation.

Using the RFM analysis report, you can segment your paying audience by their purchasing patterns. This way you can improve retention and increase revenue by re-engaging inactive paying users.

In-App Purchases

In order to view the data in the Monetization Dashboard, Gross Structure, Conversion to Payments, RFM Analysis, Transactions Number, Transactions reports, you need to integrate Payment event transmission. You must send this event immediately after the platform confirms that the payment went through successfully. Learn more about the Payment event integration here.

Ad revenue

If your app uses the ad monetization model, you can integrate ad networks to get access to the Ad monetization report. The report will help you evaluate how users interact with ads in your app, analyze the most in-demand metrics of ad performance such as ad revenue, eCPM, ad impressions, average number of ad impressions per user and the number of ad clicks per user.

In case you use IronSource or Applovin MAX, you will get access to more detailed statistics. You can find out more about the report here.

Subscriptions

If your app uses a subscription monetization model or a mixed monetization model, you can choose the exact income source to calculate the financial metrics: subscriptions, ads or one-time purchases. You will also have access to a subscription monetization report:

The report includes widgets that display the number of new users, new trial users, subscribers and their daily conversions, conversions from trial version to subscription, subscription retention rates, the structure of purchased subscriptions, income, etc.

You can also filter users or metrics by the current status of their subscription – Subscription state. For example, you can select the users who canceled their subscription and send them a push notification with an engaging offer to drive them to renew their subscription.

Segmentation

User segmentation is an important and useful process in mobile application analysis. Sometimes, hypotheses based on information about all users can lead to incorrect conclusions. The larger the audience of your project, the less homogeneous it is. Therefore, using user segmentation, you can analyze the segments in comparison with each other. For example, you can compare the rates of authorization conversion funnels for different countries.

Static segments

There are two types of segments: static and dynamic. A static segment consists of a specific list of users who perform a specific number of events. A static segment can be created using the conversion funnels section, and the list of users will not be updated:

Dynamic segments

It is also possible to create a dynamic segment; this list of users will be updated every time new users perform an event specified in the segment parameters. You can create it by going to the Users & Segments tab, and then to the Segments section:

Once segments have been created, they can be used in reports and dashboards in the same way as filters. For example, you can compare the behavior and metrics of users who completed a tutorial with those who skipped it.

Engagement

The Engagement section enables you to analyze user behavior, retention, and engagement.

Tutorial Analysis shows a tutorial steps funnel, as well as the number of users who successfully completed, did not complete, or skipped the tutorial. Using this report, you can identify bottlenecks in your tutorial.

In order to build a funnel of tutorial progression steps, you need to integrate the basic Tutorial step event. This event should be sent at the end of each tutorial step with the number of each completed step as a parameter. You can learn more about integration here.

The Retention report shows you the percentage of users who opened your app on a selected day after the first launch. This way you can gauge the loyalty to your product and understand when users stop using it.

In the Audience structure report, you can analyze the structure of your audience divided into different groups according to the following parameters: App versions, Country, Devices, Paying capacity (free / minnows / dolphins / grand dolphins / whales / grand whales), Paying status (paying / free), Returning users (new users / returning users).

You can also compare application versions – this is useful in the first days after the release of a new version of the application to make sure that in the updated version the main user action funnels have not been worsened or made more complex. You can compare the metrics of users going through the tutorial, their retention, and income across product versions.

Push notifications

One of the methods of re-engaging users and boosting retention in your application is sending them push notifications. You can use this built-in functionality and compare the metrics of users who received a notification with those who did not.

To implement the push notification service, you need to:

1. Integrate devtodev SDK and activate push notifications during integration execution.

2. Fill in the required information in the push notifications panel in the Integration section of the application settings. You can get more detailed information here:

Custom events

In addition to analyzing data using the main reports, which are based on basic events, you can integrate custom events to track and analyze specific user actions. By using custom events, you can find out what users do in the application, what functions are most popular, how they use various filters, change settings, which buttons press, whether they communicate with other users, whether they share your application with friends, and much more.

For example, an event that gives you information about the most preferred login methods used in your application: Event name authorization Parameters method, e.g., fb, method (string) – authorization method: social networks, email.

You can analyze custom event data in the Custom events report. You can also build a funnel and analyze the conversion at each stage, for example, you send the steps of purchasing goods in your application. Based on these events, you can build a funnel and use the Conversion funnel report to see the conversion at each stage. This will allow you to find the stages where you are losing potential customers.

Cohorts

To assess the dynamics of product quality, you can use Cohort analysis report that allows you to compare the behavior of different user cohorts (segments with different registration dates): how they are converted into purchase for the same period, how their retention rates change, how much they pay.

Users

The report allows you to get information about users. For each user you can see: basic properties, custom properties that are sent to the system, and information about user actions performed in the application.

For example, if you build a conversion funnel for user actions, you will see how users move through the selected stages, but you will not see interim optional steps. Users may not be able to find the right button at once. Thus, by eliminating needless steps, you can optimize and streamline the user's path to the desired action.

Levels

Reports with grouping by levels or information about levels are rarely used for non-gaming applications, but still, you can divide user progress in your application into several levels by prioritizing the application functions, and send them to us.

If your project has a virtual currency, by using the LevelUp event you can send information about the current amount of virtual currency in users’ possession.

To track virtual currency consumption and item popularity, add a Virtual Currency Payment event transmission immediately after purchase. These events help you estimate the average amount of virtual currency that users have at a certain level. The event should be sent as soon as the user moves to the next level.

For example, if a user has registered, send information that they got to the first level, then after they have used filters when choosing an item, they earn some activity points, but don’t get to a new level. Or if the user made the first purchase, they are moved to another level, etc. ... This provides an opportunity to build reports and create new hypotheses to boost your metrics. Level transmission gives you access to the In-game Analysis Dashboard, Economy Balance, Virtual Goods & Purchases, and Game Structure reports (Player levels tab).