My AppsLive demoNewsEducation
Search…
Introduction
Getting Started
Basic Events & Custom Events
Integration
3rd Party Sources
Reports and Functionality
Metrics and Glossary
Space Management
Limits
Scenarios and Best Practices
FAQ
Slack
On the go
Powered By GitBook
Basic Events & Custom Events
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.

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.
There is no separate event in devtodev that describes a session by its duration and start or end date.
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.
To calculate the average session length per day, the sum of all durations of application activity is divided by the number of session starts.

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).
Integration of data about sessions and payments takes up to 20% of the time spent on integration, but in the future it will give answers to 80% of questions about user behavior in the project.

Tutorial is a very important part of any project because the first session lays the foundation for future retention and monetization indicators.
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

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.

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.

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.
The sequence in which locations are passed 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 spend it on virtual goods. To work with virtual currency purchases, devtodev has developed an InAppPurchase event.

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.
Each custom event can have up to 20 parameters to identify more detailed info about users' behavior.
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. 1.
    The number of different event types sent from one project shouldn't exceed 300.
  2. 2.
    The event name must not exceed 72 characters.
  3. 3.
    One event can contain up to 20 parameters, which must have unique names of up to 32 symbols.
  4. 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).

Previous
Adding an app to the space
Next
Integration
Last modified 7mo ago
Export as PDF
Copy link
On this page
Sessions
Payment (Real-World Currency Payment)
Tutorial Step
LevelUp
CurrencyAccrual
Progression Event
In-App Purchase (Virtual Currency Payment)
Custom Events