To begin working with analytics, you need to start sending events (information about user activity in the project) to the analytics system.

devtodev provides basic events that drive the majority of the reports.

Sessions

Users start with opening the app, and this process we call "starting a session". For your convenience, in the majority of devtodev SDKs this event is integrated automatically.

We use two events that we can use to examine the duration of the sessions. The first event captures the start date of a new session and the second captures the duration of each application activity (time when application is in focus). In our experience, this is the most reliable solution at the moment.

At the moment when application receives focus (this may be the moment the SDK is initialized / the application is opened / the device wakes up from the sleep mode with the focus on the application), we begin to assume that the application becomes active and begin to count the duration of the activity.

If the application loses focus (minimizing the application / device is going into the sleep mode / switching to another application / exiting the application), we consider that the activity is completed and we send its duration to the devtodev server. This is an application activity event.

We consider the start of a new session to be the moment when the application receives focus (see the description above), but at the same time we take into account that more than 10 minutes have passed since the last activity of the application. Otherwise, we count that the previously launched session continues.

Reports based on a Session event :

• ​Engagement Dashboard​

• ​Sessions​

• ​Retention​

• ​Audience structure​

• ​Churn Rate​

• ​App Version Analysis​

Payment

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

​How to integrate Payment event.​

Reports based on a Payment event :

• ​Monetization Dashboard​

• ​Gross Structure​

• ​Conversion to Payments​

• ​RFM Analysis​

• ​Transactions Number​

• ​Transactions​

Tutorial Step

Using this event you can evaluate the effectiveness of the tutorial steps system, analyze how users complete the tutorial, find bottlenecks, and measure the time it takes for users to complete the tutorial. The event should be sent at the end of each tutorial step indicating the number of completed steps as a parameter.

Here are some predefined values for the Tutorial Step event parameter:

• 0 - the user skipped the tutorial

• -1 - the user started the tutorial

• -2 - the user finished the tutorial

​How to integrate Tutorial Step event​

Reports based on a Tutorial Step event:

• ​Tutorial Analysis​

LevelUp

You can analyze the distribution of the players over the levels. 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. 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 evaluating the average amount of in-game currency that players have on a particular level.

The event should be sent right after the player reaches the next level.

​How to integrate LevelUp event​

Reports based on a LevelUp event:

• ​In-game Analysis Dashboard​

• ​Economy Balance​

• ​Virtual Goods & Purchases​

• ​Game Structure (Player levels tab)​

CurrencyAccrual

This specific event is a part of the LevelUp event and does not require a separate dispatch. Send this event to track the average amount of in-game currency earned or purchased during a level after each time an in-game account is replenished.

​How to integrate CurrencyAccrual event​

Reports based on a Currency Accrual event:

• ​In-game Analysis Dashboard​

• ​Economy Balance​

Progression Event

There are many projects (for example, Match-3 games), where players make an attempt to complete 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, devtodev provides a basic Progression event. In the Progression event you send information about how players pass a particular game location, whether their attempt is successful, and how numerical indicators change.

​How to integrate Progression Event​

Report based on a Progression event:

• ​Game Structure (Locations tab)

In-App Purchase

Many games, especially f2p, have in-game currency. Players can spend it on virtual goods. To work with virtual currency purchases, devtodev has developed an InAppPurchase event.

​How to integrate InAppPurchase Event​

Reports based on an In-App Purchase event:

• ​In-game Analysis Dashboard​

• ​Economy Balance​

• ​Virtual Goods & Purchases​

Custom Events

devtodev is a universal analytics system, and our structure of basic events is designed for game projects specifically. However, there may be situations when your project requires events that are not provided by the devtodev basic events. Such events can still be sent and analyzed in our system - as custom events.

Here are some examples of users' 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 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 20 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.

Here is some expert advice to avoid problems with limits in 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).

​How to integrate Custom events​

Reports based on Custom events:

• ​Conversion Funnels​

• ​User Flow​

• ​Custom Events​