What to track?

Where to start?

To begin working with analytics, besides creating a space and a project inside it, you need to start sending events (information about user activity in the project) to the analytics system.

First of all, users open an app, which means they start a session. Information about sessions (when users open and close the app) is very important, because the biggest part of integration is based on it. Sessions allow to calculate such metrics as audience (DAU, WAU, MAU), users online, retention, average session length, etc. For your convenience, in the majority of devtodev SDKs this event is integrated automatically.

Secondly, if users can make purchases for real money in your project, you need to integrate the Payment event. When devtodev receives data about sessions and payments in your app, it can calculate all financial metrics (gross, revenue, average check) and metrics of project’s financial efficiency (ARPU, ARPPU, paying share, LTV).

Integration of data about sessions and payments makes up to 20% of time spent for integration, but in future it will give answers to 80% of questions about user behavior in the project.


If your project has a tutorial

Tutorial is a very important part of the project, because during the first session the foundations of future retention and monetization indicators are laid.

devtodev allows to analyze how users pass the tutorial, find bottlenecks, and measure how much time it takes for users to complete the tutorial. These questions can be answered with the help of the "Tutorial steps" and "Tutorial dynamics" reports.


To be able to build these reports, you need to integrate the Tutorial Step event. This event should be sent at the end of each tutorial step indicating the number of a completed step as a parameter.

Here are some constant values:

  •  0 - the user skipped the tutorial
  • -1 - the user started the tutorial
  • -2 - the user finished the tutorial





Tutorial steps

Tutorial Step

What percentage of users started the tutorial but haven't completed it


Churn rate on each step of the tutorial

Tutorial dynamics

Tutorial Step

The percentage of users who haven't completed the tutorial


Time spent to complete the tutorial

NB! The "Tutorial steps" report is based on users who started the tutorial, whereas the"Tutorial dynamics" report is based on all users. This means that the 'not completed' segment in the "Tutorial dynamics" includes not only users who haven't completed the tutorial but also users who haven't started it. This may lead to the situation when the churn rate in the "Tutorial steps" and 'not completed' segment in the "Tutorial dynamicsare not equal.


If users in your project become more experienced and raise their level

devtodev is an analytics system designed specifically for game projects. Many game projects have levels, which means users become more experienced and gradually increase their level. In this case levels have linear structure: the level N is followed by the level N+1.

When players move to the next level, you need to use the LevelUp event. All our reports that are built by levels are based on this event: "Currency balances by level""Users by level", etc. Also, if your project has an in-game currency, with the LevelUp event you can send information about the current amount of in-game currency players have. This data allows to identify the average amount of in-game currency that players have on a particular level.

For example, this is how the "Users by level" report looks like (see pic below). It shows how users are distributed among levels, the percentage of users who remain on a particular level, revenue of a particular level, etc.


If it is possible to pass / fail a level in your game

There are many projects (for example, Match-3 games), where players make an attempt to pass a level. Their attempts may be either successful or unsuccessful. In addition, during a certain attempt different numerical indicators can be changed: the number of stars, resources, in-game currency.

To analyze such attempts, we've created a basic Progression event. In the ProgressionEvent you send information about how players pass a particular game location, whether their attempt is successful, and how numerical indicators change.

Based on the ProgressionEvent, we build the "User progress" report, where all indicators are calculated by game locations, for successful and unsuccessful attempt.

NB! The sequence in which locations are passed is not important in this case: after the location N players can go to any location M.


If there is a virtual currency in your project

Many games, especially f2p, have in-game currency. Players can accumulate currency, or buy it for real money. They can then spend it on virtual goods. To work with virtual currency, devtodev has developed the following events:

  • inAppPurchase – to send information about purchases made by players (pay attention to the fact that these are purchases made with virtual currency, purchases for real money are send with the Payment event);

  • currencyAccrual – to show information about movements of virtual currency (for example, if a player earns currency or receives it for some actions, you can use currencyAccrual to see this information).

Based on these events all reports about game economy are built.

With the help of the "Currency balances by level" report (this one also requires the levelUp event) you can see how users spend, earn and accumulate currency on each game level.

The "Bestsellers" report allows to analyze the structure of the consumer basket and identify items, which are the most popular among different categories of players.


Custom events

devtodev is a universal analytics system, the basic events structure of which is designed for game projects. However, there may be situations when your project requires events that are not provided by devtodev as basic events. That's alright, such events can still be sent and analyzed in our system - as custom events. It is possible to specify parameter values of custom events. Here are some examples of user actions that can be sent as custom events: when users open a shop, click on items, buy items. Based on these events, you can then build a funnel and see the conversion on each step.

Some limits for custom events:

  1. The number of different event types sent from one project shouldn't exceed 300;    

  2. The event name must not exceed 72 characters;    

  3. One event can contain up to 10 parameters, which must have unique names of up to 32 symbols;

  4. Parameters can be string and numeric:

  • the maximum length of parameter values is 255 characters;

  • the number of string parameter values cannot exceed 50 000 (when it exceeds 50 000, the further sending of information about the parameter and possibilities to work with it will be blocked);

  • if the parameter is numeric and the number of its variations per day exceeds 5 000, this parameter stops getting into the "Custom events" report, but you can still see it when working with conversion funnels, SQL wizard and exporting raw data.

Here is some expert advice to avoid problems with limits on custom events:

  • there is no need to send user IDs in parameters (they are collected by default);

  • do not send time in the timestamp format (it is also collected by default).


If you want to check transactions for validity

To exclude transactions made by cheaters from statistics, you can use devtodev Anticheat service. By using this method, you will be able to check payments for validity before sending them to devtodev. The verification process is the following:

  1. When a user makes a transaction, the anticheat method must be called. The integration of this method is described in the documentation for a specific platform (the Anticheat methods section);

  2. After this, the transaction will be checked for validity by devtodev;    

  3. If the transaction is not valid, the Payment event shouldn't be sent. If the transaction is valid, the Payment event should be sent and it will later get into statistics.

NB! We don't recommend to use results of the devtodev Anticheat service as a condition for giving or not giving users currency or items they have bought. One of the reasons is that in case there are some problems with the devtodev server, there will be no answer about the validity of transactions and users will not get what they've bought.

And here are two specific examples of integration:
  1. match3 game;
  2. game where levels go in sequence.
What to start with?
Case: Match-3 games