What to track
Last updated
Last updated
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.
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. Reports such as Economy balance and Player levels are built by levels and are based on this event.
Also, if your project has in-game currency, you can send information about the current amount of in-game currency players have using the LevelUp event. This data allows to evaluate the average amount of in-game currency that players have on a particular level.
For example, this is the Player levels report. 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. With Progression event you can send information about how players pass a particular game location, whether their attempt was successful, and how numerical indicators change.
Based on the Progression event, 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:
Virtual Currency Payment – 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.
Currency Accrual – to show information about movements of virtual currency. For example, if a player earns currency or receives it for some actions, you can use Currency Accrual 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 Virtual goods & Purchases report allows you to analyze the structure of the consumer basket and identify the most popular items among different categories of players.
There may be situations when your project requires events that cannot be tracked by devtodev basic events. 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: opening an in-game store, clicking on items, buying 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 should not 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 or numeric:
The maximum length of string parameter values is 255 characters.
The number of unique string parameter values cannot exceed 50000. When it exceeds 50000, the system will block the parameter.
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 Anticheat method. By using this method, you will be able to check payments for validity before sending them to devtodev.
The verification process is the following:
Get response about a completed transaction from the payment system.
Either send data about the received transaction for verification by calling devtodev anti-cheat methods or use your own tools for transaction verification.
If the transaction has successfully passed verification, perform the Payment event.
If the transaction hasn’t passed verification, do not perform the Payment event and mark the user as a cheater if necessary.
We do not recommend to use devtodev Anticheat method as the only tool to validate transactions.
