What to track
Last updated
Last updated
A tutorial is a very important part of any project because the first session lays the foundation for future retention and monetization indicators.
devtodev allows to analyze how users complete the tutorial, find bottlenecks, and measure the time it takes for users to complete the tutorial. These questions can be answered with the help of the Tutorial analysis report.
devtodev is an analytics system designed specifically for game projects. Many game projects have levels, which means that as users become more experienced, they gradually increase their level. In this case levels have a 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, e.g. Currency balances by level, Player levels, etc. Also, if your project has in-game currency, using the LevelUp event you can send information about the current amount of in-game currency players have. This data allows to evaluate the average amount of in-game currency that players have on a particular level.
For example, this is how the Player levels report looks like (see the pic below). It shows how users are distributed among levels, the percentage of users who remain on a particular level, the revenue of a particular level, etc.
There are many projects (for example, Match-3 games), where players attempt to pass a level. Their attempts may be either successful or unsuccessful. In addition, during a certain attempt some numerical indicators can change: the number of stars, resources, in-game currency.
To analyze these 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 was successful, and how numerical indicators change.
Based on the ProgressionEvent, we build the Locations report, where all indicators are calculated by game locations, for successful and unsuccessful attempts.
The sequence of locations passing is not important in this case: after the location N, players can go to any location M.
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 (please note that these are only purchases made with virtual currency, while information about purchases for real money is sent 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).
All the game economy reports are based on these events.
With the help of the Currency Balances by Level tab in the Economy Balance report (this one also requires a LevelUp event), you can see how users spend, earn and accumulate currency on each game level.
The Top Purchases tab in the Economy Balance report allows you to analyze the structure of the consumer basket and identify items, which are the most popular among different categories of players.
devtodev is a universal analytics system with basic events structure designed specifically for game projects. However, there may be situations when your project requires events that are not provided by devtodev as basic. 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 an in-game store, 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:
The number of different event types sent from one project shouldn't exceed 300.
The event name must not exceed 72 characters.
One event can contain up to 20 parameters, each of them with unique names of up to 32 symbols.
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;
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).
To exclude from statistics transactions made by cheaters, you can use devtodev Anti-cheat 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:
When a user makes a transaction, the anti-cheat method must be called. The integration of this method is described in the documentation for a specific platform (the Anti-cheat methods section).
After this, the transaction will be checked for validity by devtodev.
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.
We don't recommend to use devtodev Anti-cheat service as a standard tool to validate transactions.
