Tuning section includes:


This page shows an overview of created users’ segments. You can customize them, delete or add new ones. These segments can help you target a specific group of users, separating them by any action they make (e.g. skip tutorial, pay for a subscription) or any property.

There are two types of segments: static and dynamic. Static segment consists of a specific list of users, who perform a distinct number of events. Moreover, it cannot be supplemented. A static segment can be created using the reports that show the number of users (for example, Conversion funnel). You can also upload a CSV file with a list of user identifiers manually. To do that, create a Static segment and follow the instructions. In the dynamic segment such list of users will be updated any time whenever new users will perform a specific event listed in the segment parameters.

Once segments are identified, they can be used in your reports and dashboards the same way as filters.

Each segment has five parameters: name, type, current audience, date of creation, expiration date. Click on existing segment to adjust it.

You can filter your segments in ascending or descending order by any parameter.

You can also create a new dynamic segment by clicking “Add dynamic segment” button in the upper right corner. Then you should fill in:

  • Name

  • Segment filter

  • Here you can add customized conditions describing in details those users who will be in new segment

  • You can also specify triggering event which will filter all users for your new segment

The Expiration date is calculated automatically and cannot be changed manually. If the dynamic segment is not used in the reports, then the segment will be deleted when you reach the Expiration date. Otherwise, the Expiration date is prolonged. Also, if you change the settings for the dynamic segment, all the previously collected data resets and we start collecting data in accordance with the new settings. Static segments have the Expiration date as well, but still, segments of this type are not being cleared or terminated.

Paying capacity

In devtodev all paying users are divided into 5 segments by their payment amounts: minnows, dolphins, grand dolphins, whales and grand whales. These segments can be applied to the reports and dashboards and used as filters in order to analyze metrics of app performance for each user segment.

Also, such division might be helpful to see the distribution of your users by segments.

This page helps you specify payment intervals for each segment of users separately. Payments are measured in US dollars.


Labels section allows you to manage time labels by adding marks on a timeline. These marks can be one-day or long-term events which can be specified as duration of in-game events, sales, update of app version, etc.

Labels can help you to monitor abnormal changes and identify the cause of it in a specific time period.

All specified labels can be presented in two ways:

  • Calendar view

  • Table view

You can create new labels by clicking “Add label” button in the top right corner. Each label can be customized using preset or your own categories.


By setting up alerts, you will always stay tuned and you will be able to monitor game metrics changes without getting into the system. You will be notified automatically in case of any changes in your main metrics, so you can act on them quickly.

This page will help you to set up alerts in 4 steps.

Firstly, you should specify a metric, its condition type and sensitivity. Conditions can be: comparison with confidence interval (the previous day value will be compared to the confidence interval), comparison with threshold (the previous day value will be compared to the specific value).

Secondly, you should customize preferable notification channels. You can choose to notify via e-mail, devtodev notification or Slack messages. It is important to add at least one addressee or webhook.

Thirdly, you should choose notifications’ delivery time (based on Europe/Moscow time zone). You can customize the start date and decide whether alert campaign will expire or not on a particular date.

Finally, you need to give a name to your alert to be able to differentiate it from the other ones.

The Finish button will complete the configuration of your devtodev notifications.


Integration Status

The correctness and completeness of the integration affects the effectiveness of the system dramatically. That's why we add this section with gamification where you can check the effectiveness of usage of our service.

Account, Sessions and Payments

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. Along with sessions the information about payments is essential. 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.

Game events

All reports from In-game Analysis section are based only on 5 devtodev basic events: Currency accrual, Tutorial steps, Leveling up, In-app purchases, User progress. Do not miss to integrate them all.

Additional features

Sure, devtodev game events cannot cover all functionality of any game as all games are unique. Custom events can solve this problem together with custom user properties. Push notifications can help retaining users. And information about traffic sources can make the analysis deeper and richer.


There are different customization tools for your convenience: labels, segments, alerts, custom dashboards and reports. Use them all to make the analysis deeper and more targeted and reports easier to read.

Custom events management

In this section, you can rename the event and parameters without changing them in code. It will allow you to save time for bug fixing if there are some mistakes in naming.

Also, you can ‘block’ some events to stop collecting and storing their data. This functionality you can find in the “Tuning” section of the top menu, Integration subsection.

Please note, only space administrators or a space owner can edit custom events. The rest of the roles have only access to viewing. At the top of the report you can see the custom events overview:

  • Active custom events - events we are tracking and recording at the moment. These events are available for all reports.

  • Events blocked by customer - events which were implemented in the code but were blocked by the space administrator or space owner. We are not collecting and recording data for these events at the moment. You won’t be seeing these events when building reports.

  • Events blocked by system - events that were blocked by devtodev because of exceeding the limit by the number of tracked unique event names.

Under this overview block, you can see the list of active custom events.

You can do the following actions here:

  • Block the event to stop collecting its data

  • Rename the event

  • Rename the parameter of the event

When you rename the event, be attentive to the alias - it can’t repeat other aliases or event names. If you scroll down, you will see the list of blocked events which contains events that were blocked by the system or a customer. There is a limit of 300 unique event names that we can track simultaneously. If you reach the limit, you can block those active custom events that are currently irrelevant. To block or unblock the event you need to tap the lock icon.

We’ll start collecting data for this event only after it is unblocked.

Please note that you can unblock events from this list if you have less than 300 active custom events.

System alerts

In order to provide you with the correct data in the reports and make them insightful for you, we will keep you informed about different errors and issues in the data such as achieving the events or parameters limit and errors connected to the integration or tracked data. These notifications could contain information about the following issues:

  • transactions exceed the limit by the amount of payment;

  • events with the same name but different register are tracked;

  • number of currency types are about to reach the limit;

  • some transactions are doubled;

  • and more.

Notifications about errors and different warnings are displayed in the Notification section in the right upper corner.

More details about each of them are available under the “Read more” button. After you tap it, you will be redirected to the “System alerts” sections where you can find the following:

  • list of all errors and warnings of the current application version;

  • a detailed description of the errors and documentation links with information about the limits and integration best practices.

You can also postpone the notifications for 7 days by using the "Remind later" button in the Notification section. After 7 days we resume sending notifications if the error or the warning persists.

By default, error notifications are sent to users with owner or admin rights. They can subscribe to notifications users with different permissions or unsubscribe them. To do this, at the top of the System alerts page in the Tuning - Integration section you need to click on the pencil icon, select a user from the list and click Apply: