These reports present information about user behavior related to retention and engagement.

Engagement reports are:

• Dashboard

• Tutorial Analysis

• Sessions

• Retention

• Audience Structure

• Churn Rate

• App Versions Analysis

• New user path

• User Flow

Engagement Dashboard

This report represents key information about users' behavior related to retention and engagement for the last 30 days (by default):

• Active users (divided into 4 groups: 1 day, 2-7 days, 8-30 days, 1-3 months)

• User chart by country (chart shows top 5 countries by users)

• Tutorial (shows how new users pass the tutorial)

• Average session length (shows the average session length per day in seconds)

• Retention (shows day 1, day 7, day 14 retention)

• Retention chart (shows the percentage of users returning to the application by the number of days since installation)

• Churn (shows the number of users who were inactive for 7 days and so we assume that they stopped using the application)

• Version Audience (shows active users by application versions)

To change the period use calendar control at the top:

Click a 🔎 to open a more detailed report.

Tutorial Analysis

The first chart “How users pass tutorial” shows the number/percentage of users who have successfully completed, not completed or skipped the tutorial. You can select absolute or percentage values by selecting a view type in the top right corner.

Next charts show basic information about the tutorial: the total number of users who performed the same actions, top 5 steps with the highest churn and distribution by spent time.

The final chart allows to identify tutorial steps with the highest churn rate. This report shows the number of users who have successfully completed each step of the tutorial during a chosen time period, and it also calculates user churn rate from step to step in absolute and percentage values.

By tapping on each step in the report, you can assign a name that describes the action, facilitating seamless collaboration among all team members working on the app.

Click Filters to apply additional filters or segment.

Sessions

This report contains 2 sections: General, Cohort Playtime.

General

On the ‘General’ tab, there are several metrics:

• Session duration - shows the average session length of one user. It is calculated as an average value (Total Sessions Length / Number of sessions) by users

• Number of sessions - shows the average number of sessions per user. It is calculated as Number of sessions / Number of users

• Frequency of use - allows to estimate the regularity of visits. Sessions are segmented by the frequency of visits: time since install is shown in rows, the median number of sessions per week - in columns.

• Length distribution - shows the general distribution of all sessions depending on their duration

• Session frequency - shows the general distribution of users depending on the number of sessions over a selected period

• Total daily time spent - shows the amount of time that an average user spends on the app. It is calculated as Total Sessions Length / Active Users

You can group the data by:

• All users (no grouping)

• Country

• Device

• New or returning users

• Paying capacity (non-paying / minnows / dolphins / grand dolphins / whales / grand whales)

• Paying status (paying / non-paying)

• Traffic sources

• Version

Application of certain groupings unlocks one more setting - ‘Top by’. You can select a variable (session duration, audience, number of sessions, gross) to be used for displaying the top groups on the graph. For example, you can display the number of sessions with grouping by the device. And on this graph, we see the devices that generate the most revenue:

Use the slider under the chart for changing date range and move it to see different ranges more precisely.

Cohort timespent

This is cohort analysis by timespent that shows the average amount of time spent by users on the product at a certain day after the installation.

It is calculated as the average of all session lengths per user. The metric is displayed as a value at a certain date but not as a cumulative value for all previous days.

In this report, you can select Session length unit (seconds, minutes, hours)

Retention

The Retention report shows how users return to the app. It allows you to measure customer loyalty and keep track of when users stop using it. This report allows you to see different types of retention and apply several settings for them.

The report includes two tabs: Table and Trends. The same install date period is used on both tabs; you can change it in the top right corner. You can configure a filter in the report: use an existing filter template or a custom segment to get more detailed data. To apply changes click the “Refresh” button.

Use Table tab to see averages, medians, the table view of retention statistics and to compare daily cohorts against one another.

Now let’s take a look at the types of Retention and their settings.

First, choose the Retention method: either “From installation to any event” or “Custom”. Usually, the Retention rate is calculated as the percentage of users who return to the app on a specific day after installation, divided by the total number of users in the cohort. If you select Retention method -> From install to any event, this calculation method will be used.

This report serves not only for evaluating engagement but also for assessing demand and user interest in a particular feature. In such cases, you should opt for Retention method -> Custom. This allows you to configure the following additional settings and calculate the metric:

First event - all users who perform this event will be added to the cohort (in the classic retention calculation, this event is either installation or first launch of the app).

Return event - these are the events that users need to complete to be considered “returned”. Unlike the classic retention calculation, simply opening the app on a certain day is not enough to be considered "returned." Users must take a specific action specified as the Return event for inclusion in the calculation.

Let’s consider an example. Suppose we have a web product where many people visit our website, but they are not our target audience, making our retention values non-representative. We want to calculate this metric for registered users only, as they are our primary audience. In this case, we select the registration or authorisation event as the First event and leave the Return event as it is (“Any event”). This ensures that the metric is calculated for the entire target audience who logged in and performed any action.

Here’s another example. We have recently introduced a new feature and want to understand how frequently and actively people are using it. Let’s say it’s a Like or Dislike button under a video. In this case, we select Like or Dislike events as both First event and Return event. This allows us to evaluate the retention rate specifically for the audience that utilized this feature.

Afterward, customize the Retention type (applicable only when Retention method -> From install to any event).

Classic retention - the percentage of users returning to your app (or performed specific action) on a specific day after the first launch (or any other action). For example, we calculate Day 7 classic retention as the number of users who had a session on the 7th day after the install day divided by the number of users in the cohort (who installed the app 7 days ago).

Rolling retention - the percentage of users returning to your app on a specific day after the first launch or any day later. For example, if we calculate Day 7 rolling retention, it will be the number of users who had a session on the 7th day and later, maybe on the 9th day or 25th day, etc.

Customize the “Calculated by” setting.

Calculated by 24 hour intervals - it means that “days” for this user will be calculated by 24 hour intervals starting from the first launch, and not by calendar days. For example, if the user installed the app at 23:50 then their 1st day will end at 23:50 next day.

Calculated by calendar days - it means that days for this user will be calculated by calendar days. For example, if the user installed the app at 23:50 then their 1st day will end in 10 minutes at midnight, according to the calendar.

It works the same for monthly grouping. Also you can notice the * sign in some cells of the table. It means that the calculation for this cell is not finished yet because the period is not over.

For example, you built a report for the last 30 days with weekly grouping but today is Wednesday, so the current week has not finished and the number in the appropriate cell will be recalculated until the end of Sunday. That is why it is marked with the *.

Also, you can check the box in the top right corner of the Retention table and enable trend data.

Trends tab shows retention on Day from 0 to 30 and also Day 45, 60, 75, 90, 105, 120, 135, 150, 165 and 180. The dates of the first launch are displayed on the horizontal axis of the chart. It means that you will see the dynamics of the selected metric (e.g. Day 7 retention) for several cohorts as a line chart

For all these types of Retention you can set the aggregation period to whatever timeframe you want: days, weeks, months. If you select weekly aggregation, then the cohorts will be grouped by calendar weeks and Retention will also be calculated by weeks from install date. So the grouping will be applied to rows and columns of the table.

The trend data are expected Retention values that are calculated based on the median value over the selected period.

In a table, these data look like light gray numbers in white cells. On a graph, the trend values are represented with a dotted line. They are not involved in the calculation of median and mean value.

You can apply the Events filter to all the reports. It filters report results based on users who performed the target event and shows the percentage of users who performed the specific action and then returned on Day N after registration.

For instance, let’s say we want to analyze the classic retention rate of users who added two items to their chart. To do this, we select Retention method -> From install to any event, and specify event completion in the filter.

Using this report allows you to define the actions that influence the loyalty of the users and engage them more than others.

Audience structure

The report shows the distribution of behavioral metrics (active users, number of sessions, total number of users and sessions, and sessions per user) by different grouping:

• All users (no grouping)

• App versions

• Country

• Devices

• Paying capacity (non-paying / minnows / dolphins / grand dolphins / whales / grand whales)

• Paying status (paying / non-paying)

• Returning users (new users / returning users)

Default report period shows the last 7 days, you can change it in the top right corner. You can configure a filter in the report or use already created filter template or custom segment to get more detailed data. To apply changes press “Refresh” button.

Please note, if you group by Returning users, the New users metric will show the number of active users who launched the app for the first time less than 24 hours ago.

Churn Rate

Churn rate allows to estimate when users leave the app.

Churn rate by days from install shows the percentage of users who has left the app on a particular day after the install date.

Users' churn day is calculated as a difference between the last seen date and the date of install. Churn rate is calculated for each day as the number of users (with the current churn day) divided by the number of users in the cohort.

Here you can compare an average and median churn with the particular daily cohort churn.

First of all we need to set the “Churn period” in the report settings. It could be 3, 5, 7, 14, 21 or 28 days. We count as “churned” all the users who have been inactive for the set period of time.

Let’s take 7 days “Churn Period” as an example. A user installed the app and was active every day for 5 days. Then he didn’t run the app for the next 7 days. We count this user as churned on the day when he was active last time (on the 5th day since install). If he launches the app later, for example after 10 days, then we will remove him from the report on churned users because he is active again, not churned.

If we talk about a new cohort of users that was created yesterday, before 7 days (the churn period) have passed, the churn rate value will be 0%, because we don’t know yet who churned and who didn’t. Then, on the 8th day, we will check who was inactive in the previous 7 days, and include them in the report as “churned”.

Default report period is the last 30 days by the install date, you can change it in the top right corner. You can configure a filter in the report or use already created filter template or custom segment to get more detailed data. To apply changes press “Refresh” button.

Lifetime chart shows the average number of days between the first and the last time the app was launched. The launch is considered to be the last if there has been no activity in the app during a period of inactivity. You can change the period of inactivity in the drop-down list at the top of the chart.

You can compare up to 3 periods of inactivity at the same time (press "Add metric" button to add a period of inactivity).

Default report period is the last 30 days, you can change it in the top right corner. You can configure a filter in the report, use already created filter template or custom segment to get more detailed data. To apply changes press “Refresh” button.

App Versions Analysis

This report is designed for a prompt analysis of released versions. It is very relevant during the first days after the release of a new app version. Here you can see the structure of your audience, statistics on how users pass the tutorial, retention and gross – by different product versions.

The report shows up to four app versions at the same time, which you can choose in the drop-down list (press “Add metric” button to add app version).

Realtime structure

The report is built for 48h and is updated every hour. It shows the structure of new and previously registered users by versions. The report allows you to monitor how users move from one version to another.

The rest of the reports are built for the first 14 days from the moment of version release. If more than 14 days have passed since the version release, the report window shifts to the right.

These 14 days are equal to calendar days, but as long as we compare different versions which were released on different days, the days on the X axis are shown as numbers.

Tutorial completion

You can choose any tutorial metrics you need and see how users finish the tutorial and compare different versions.

Retention

This chart is similar to the “Trends” report (in the “Retention” section) which is calculated for the first 14 days since the version release. It shows the average Retention for cohorts calculated in this report on a particular day. Cohorts are built from those users who registered using selected versions and they are included in calculations until they change the app version. Choose the retention you are interested in and compare different versions with each other.

N-day gross

The report shows the cumulative gross for the first 1, 2, ..., 14 days of user activity in the app (the average value for one user). Payment information gets into the report only when the payment has been made in the initially installed version.

Audience

The report shows how the audience of each version has been changing during the last 14 days. Define the structure of your audience by versions and track how they move from one version to another.

User Flow

This report shows the most popular sequences of events users complete.

There are two ways how this report can work:

1. It can show the sequence of events that go after a specific event (select “from the event” in the drop-down list of the “Flow direction” menu)

2. It can show the sequence of events preceding a specific event (select “to the event” in the drop-down list of the “Flow direction” menu)

After that, select one or several events to be taken into account for creating a user path. You can use both basic and custom events.

If you select several events, the first Start/Finish point on the diagram will be composed of the users who performed all specified events.

You can also check the ‘Allow events between selected’ box to allow for other events to happen between specified events. For example, you want to analyze actions of users after they viewed some items and completed the order, then you select the following: First event - item view, Next event - order completion. In this case, there can be other events between these two: add the item to the cart, select shipping method, etc. and they will also be taken into account while creating the user flow.

If you want to limit the flow of events performed by users, you need to specify this parameter in "Flow time limit".

• No (no limit by session) - in this case, devtodev uses all user sessions to build a user flow.

• Limit by first sessions - if you choose this option, devtodev will build a flow based on all events performed by users during the first session. This can come in handy if you want to analyze user actions during the first

• Limit by number of sessions - here we take the specified number of sessions performed during the selected period, then we consider the time when the first session started and the time when the last session ended, and build a flow based on the events performed during this period. You can use this option to analyze user actions during two sessions, to see if users perform the target actions that you set for them, or to find places from which they move to another app screen or quit the app altogether.

To see the distribution of events that were performed before the users closed your app, select ‘Event path ends with’ as the direction of the report and ‘User churn’ as the key event.

For this event, you can also select a parameter: a number of days related to churn. If you select that User churn >= 4 days, it means that the flow will be built for those users who are not active for 4 days or more. If you want to build a user flow report on specific events, you can exclude some or all basic events on the “Include basic events” and include any custom events in the “Include custom events” drop-down list.

This report also takes into account users’ churn (when users stop using the app). Churn here is the period of users’ inactivity after which they will most likely no longer open the app again.

This period should be set in the “Churn period” section. After the chart is built, you can click on each event to see the flow. Each branch of the flow consists of 5 event-points.

Click “View result” or “Refresh” to build the report. It will show top events that lead to or go after a chosen event.

Default report period is the last 30 days, you can change it in the top right corner. You can configure a filter in the report, use already created filter template or custom segment to get more detailed data. To apply changes press “Refresh” button.

New user path

This report shows the most popular actions (events) carried out by users during their first days in the app. The data is presented for two cohorts of users so that it’s convenient to compare them.

You can analyze the top 3 most popular events for every minute of the first in-app hour. You can also select the first in-app day or three in-app days in the “Period” drop-down list.

First of all, you need to define the “Primary Cohort” and “Comparative Cohort” by adding install dates and any additional filters (by default the system creates cohorts for the last 7 days with different paying capacity).

The list of the most popular events is created based on events carried out by users from the “Primary Cohort”. The same events are used for analyzing the “Comparative Cohort”.

If you want to see a report only for specific events, use the “Include events” drop-down list to include or exclude events.

If you need to know the exact parameter values of events, enable them in the “Include events with params distribution” menu. Then click on an event name and then “Show by parameters”. You will be able to see the parameters of selected events for users from both cohorts.

This report also takes into account users’ churn (when users stop using an app). Here churn is the period of users’ inactivity after which they will most likely never open the app again. This period should be set up in the “Churn period” section.

For the both cohorts we have the Total number of users that are taken for observation. Time since the first launch is a timeline of your new users activity. Each time period (0-1min, 1-2min … 22h-23h) shows maximum three events - these are the most common events of users from the Primary Cohort. Then the system calculates the proportion of users that perform this event to all users in each cohort.

For every time period on the given timeline the number of Active users is calculated (these are users that sent any event selected in the “Include events” section). The percentage of Active users is calculated from the number of Total users.

In addition to that, you can see how many users churn in each time period. The Churn users are users that were active for a certain time period on the timeline (i.e. sent at least one of the selected events) but then churned – were inactive during the selected Churn Period. The percentage of Churn users is calculated from the number of Total users.

For better understanding of the user lifecycle, the report provides you with milestones. You can see when the majority of users (75%) that haven’t churned before a particular period on the timeline complete the most important events in your app. The following milestones can be shown for your app:

• Tutorial completion

• Level up + Number of level

• First payment

This report shows the dynamics of quality metrics for different cohorts based on install date.

There are two pages available:

1. Custom cohorts

2. Weekly cohorts

The Custom cohorts report presents quality metrics data grouped by 3 cohorts.

Default cohorts are calculated based on install dates only, but additional filters can also be used.

If you have data for the period of more than 3 days and less than the period of 28 days, the following cohorts are shown:

• Cohort 1 – users who installed the app yesterday

• Cohort 2 – users who installed the app 2 days ago

• Cohort 3 – users who installed the app 3 days ago

If you have data for the period less than 3 days, you will need to wait for cohorts to appear.

It is also possible to create custom cohorts that are based on a certain period of install date. Also, you can add available filters to them. Use the "+ Cohort" button to create a custom cohort.

There are 3 main widgets on this page:

• Table

• Retention line chart

• Cumulative ARPU line chart

With the table widget you can select and track up to 5 quality metrics. The following metrics are shown by default:

• Tutorial Conversion

• Retention Day 1

• Retention Day 7

• Paying Conversion

• Cumulative ARPU for 7 days

To build the report, click the “View result” button. If you would like to build the report after changing settings, use the “Refresh” button.

The Weekly cohorts page shows the audience and gross structure grouped by the week when the app was installed. It is possible to select the type of data display – in absolute or percentage values.

Let's have a look how can you add the message on Step5 for Windows.

Firstly, you need to select the notification type. For Windows you can make a choice between Toast, Tile and Raw notification.

Toast notification

Languages

It is possible to sent notifications in several languages to make them more accessible to users from different countries. When the language used on a device is specified among languages of the campaign, the notification will be sent in this language. In case there is no device language among languages of the campaign, the message will be sent in the language that is specified as a default language.

To add or remove a language press the button with a ‘+’ sign.

Firstly, you need to choose a language that will be used by default. In most cases it is English.

Each language is presented in a form of a tab. When switching between tabs, please fill the required fields with translations. Translations are necessary for such fields as ‘Title’, ‘Text’ and ‘Share text’ (if it is used). The rest of notification settings are general and do not depend on translations.

Title

Heading that appears above the notification text in Windows notification area. Optional.

Text

The main message that is displayed in your push notification.

Icon

To replace the application icon (that shows up in the top left corner of the toast), use the URL or the resource name.

In Windows 10 the image is expressed using the URI of the image source, using one of the following protocol handlers:

• A web-based image: http:// or https://

• An image included in the app package: ms-appx:///

• An image saved to local storage: ms-appdata:///local/

• A local image (Only supported for desktop apps.): file://

Sound

A media file to be played instead of a default sound. If the option is not used, a notification comes silently. This property can have one of the following string values:

On a mobile platform, this property can also contain the path to a local audio file, with one of the following prefixes:

• ms-appx:///

• ms-appdata:///

Parameters

You can pass custom parameters with messages and use them within an app. For instance, you can activate advertising campaign or any other functionality for a user who has received this message.

With this function you will be able to send any data, the processing of which can be pre-programmed, in a key-value format to the app. For example, it is possible to activate a promotion or perform any other activity within the app.

Interaction

Available only for Windows 10 and WP 10.

Actions and Buttons options are available in devtodev SDK version 1.9 or higher.

Action

The action after a click on the body of a notification. By default, a click opens an app. It is possible to perform the following actions:

• Home screen - this is the default behavior when a user taps on a push notification. Opens app’s home screen

• Deep link - directs the user to a specific resource either within your app or on the web

• Web page - opens a web page in a mobile browser or any valid device-level URL, such as Windows Store or app protocol links

• Share - the ‘Share’ action drives users to share your message when they interact with your push notification. In case of selecting this action, don’t forget to specify the translations of share texts into all languages used in your push campaign.

Buttons

Before choosing the template of notification buttons, it is necessary to select the language of the message, which will be used by default (usually it is English).

Accessible button templates can be found in the table with button templates or directly in the interface.

After you have selected a template, you need to set an action of the button. We do not recommend to use actions that contradict the text on the button. Also, the action of the button should not duplicate the action that is used after tapping on the notification body.

In case you are not satisfied with the template you have chosen, you can replace (‘Set another template’ button) or delete it.

The set of accessible actions:

• Home screen - this is the default behavior when a user taps on a push notification. Opens app’s home screen

• Deep link - directs a user to a specific resource either within your app or on the web

• Web page - opens a web page in a mobile browser or any valid device-level URI, such as Google Play or app protocol links

• Share - the ‘Share’ action drives users to share your message when they interact with the push notification. In case of selecting this action, don’t forget to specify translations of share texts into all languages used in your push campaign

• Dismiss message - dismiss the message, without taking the user into the app

Raw notification

RAW notifications are available on devtodev SDK version 1.9 or higher.

Raw notifications can be used in case you need to send some command to an app and make it invisible to users. Users will not see the message and will not be notified by a special notification signal. This kind of notification is aimed at the app, not users.

Parameters used for sending the data to the app are the same as described in the section about toast notifications.

Tile

The tile template is selected automatically based on the content specified in tile settings.

Text 1

The first line of your tile.

Header

Check ‘Header’ attribute to mark the ‘Text 1’ field as a heading to show it larger.

Text 2, Text 3, Text 4

The second, the third and the fourth lines of the tile.

Image

Application-relative or Internet URI of the image.

Example:

• "red.jpg" (if the image is stored in the app’s installation directory or local storage folder)

• "http://my.domain.com/img/red.jpg" (for Internet URIs)

Important Note:

If you need to use remote Internet URIs for Tile images, you must take the following steps:

• Ensure the remote image file size is less than 150 KB

• Ensure the image can be downloaded in 60 seconds or less

Visible notifications

Visible notifications is the most common type of notifications. Users receive a message, which is displayed in the notification center of their devices.

Languages

It is possible to sent notifications in several languages to make them more accessible to users from different countries. When the language used on a device is specified among languages of the campaign, the notification is sent in this language. In case there is no device language among languages of the campaign, the message is sent in the language that is specified as a default language.

To add or remove a language press the button with a ‘+’ sign.

First, you need to choose the language that will be used by default. In most cases it is English.

Each language is presented in a form of a tab. When switching between tabs, please fill the required fields with translations. Translations are necessary for such fields as ‘Title’, ‘Text’ and ‘Share text’ (if it is used). The rest of notification settings are general and do not depend on translations.

Title

A short line that describes the purpose of notification.

Notification titles should:

• Be under 30 characters long

• Contain the most important information

• Exclude the app's name, which already appears in the header

Text

The main message that is presented in a push notification.

The text of notification should:

• Not exceed 40 characters

• Avoid repeating the title

App icon / small icon

The app icon is a small two-dimensional representation of your app's identity. It appears in monochrome in the status bar. If your app sends a wide range of notifications, you may replace your app's identity icon with a symbol that reflects the type of content. For example, Google now uses a cloud icon for notifications about weather.

The source of image can only be the resource of application (its name).

Small icon background

Depending on the version of Android, this function either fills the background, on which the small icon is displayed, with the specified color (Android M), or colors the small icon, app’s name and texts of actions displayed in notifications (Android N).

Large icon

In Android N, the large icon is meant only for specific situations, in which the image meaningfully reinforces the notification's content, including:

• Communication from another person, such as the image of someone sending a message

• The source of content if it's different from the app that sends the notification, such as the logo from a YouTube channel to which the user is subscribed

• Meaningful symbols about the notification, such as an arrow symbol for driving directions

• Large icons should have a round shape when showing a person and square in all other cases

The source of image can be the resource of app (its name) and the URL to the file on the web.

Android allows to use images of large size as large icons. However, in case the image will have to be uploaded by the device from the internet, it is better to use images with resolution that provides a good quality of image, but is as small in size as possible.

We recommend to use square images that don’t exceed 192x192 resolution.

Big picture

Use this template when your notification contains a picture. The large icon offers a thumbnail of the picture, and the user can get a bigger preview by expanding the notification.

The source of image can only be the URL to the file on the web.

Android allows to use images of large size as a big picture. However the device will have to upload the file from the internet, therefore it is better to use images with resolution that provides a good quality of image, but is as small in size as possible.

We recommend to use images with 2:1 ratio that don’t exceed 768х384 resolution.

Sound

Тhe name of a sound file in the application bundle (resource name). The sound in this file is played as an alert. If the sound file doesn’t exist or “default” is specified as a value, the default alert sound is played. The audio must be in one of the audio data formats that are compatible with the system sounds. If the option is switched off, the notification comes silently.

LED color

You can specify the color of LED that will notify users about an unread message. The device will display the color as close as possible to the one you specified. Unfortunately, not all Android devices have LED. Also, users can block the use of LED.

Collapse key

Notifications are not collapsible by default.

If multiple messages are sent with this key, the most recent message will suppress all previous unread messages with the same key.

Collapsible messages are a better choice from a performance standpoint provided your application doesn't need to use non-collapsible messages. However, if you use collapsible messages, remember that GCM only allows a maximum of 4 different collapse keys to be used by the GCM connection server per registration token at any given time. You must not exceed this number, or it can cause unpredictable consequences.

Parameters

You can pass custom parameters with messages and use them within the app. For instance, you can activate advertising campaign or any other functionality for a user who has received this message.

With this function you will be able to send any data, the processing of which can be pre-programmed, in a key-value format to the app. For example, it is possible to activate a promotion or perform any other activity within the app.

Interaction

Action

The action after a click on the body of a notification. By default, the click opens an app.

It is possible to perform the following actions:

• Home screen - this is the default behavior when a user taps on a push notification. It opens app’s home screen

• Deep link - directs a user to a specific resource either within your app or on the web

• Web page - opens a web page in a mobile browser or any valid device-level URL, such as Google Play or app protocol links

• Share - the ‘Share’ action drives users to share your message when they interact with the push notification. In case of selecting this action, don’t forget to specify translations of share texts into all languages used in your push campaign

Buttons

Before choosing the template of notification buttons, it is necessary to select the language of the message, which will be used by default (usually it is English).

Accessible button templates can be found in the table with button templates or directly in the interface.

After you have selected the template, you need to set the action of the button. We do not recommend to use actions that contradict the text on the button. Also, the action of the button should not duplicate the action that is used after tapping on the notification body.

In case you are not satisfied with the template you have chosen, you can replace (‘Set another template’ button) or delete it.

The set of accessible actions:

• Home screen - this is the default behavior when a user taps on a push notification. It opens app’s home screen

• Deep link - directs the user to a specific resource either within your app or on the web

• Web page - opens a web page in a mobile browser, or any valid device-level URL, such as Google Play or app protocol links

• Share - the ‘Share’ action drives users to share your message when they interact with the push notification. In case of selecting this action, don’t forget to specify translations of share texts into all languages used in your push campaign.

• Dismiss message - dismiss the message, without taking the user into the app

Invisible notifications

Invisible notifications can be used in case you need to send some command to an app and make it invisible to users. Users will not see the message and will not be notified by a special notification signal. This kind of notification is aimed at the app, not users.

Parameters used for sending the data to the app are the same as described in the section about visible notifications.

Invisible notifications can use ‘Collapse key’ and ‘Delay while idle’ settings.

Integration Status

The correctness and completeness of the integration affect 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, 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).

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.

Customization

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.

General Settings

This section contains general information about your integration.

In the General Data form you can:

• Check the state of analytics, push notifications and 3rd party sources

• Change the application name

• Upload the application picture

• Change the market link

Press the "Edit" button to start changing the settings.

SDK

Integration

Here you can find integration status, SDK version and credentials: App ID, Secret key and devtodev API key. App ID and Secret key are needed to authorize devtodev SDK, excluding Web SDK. Devtodev API key is needed while using devtodev data API, initializing Web SDK, and setting up the 3rd party sources.

One more important thing here - Event log. It shows you events from raw data that we receive. Note that it takes up to 15 minutes for events to appear in the log.

Test Devices

Test devices section allows you to mark devices as test devices. If you do not want data from some of your devices with installed app get into reports, you can add ID of those devices to the list. Data from test devices are shown only in SDK logs and Real-time dashboard.

To add test device into the list, click "+" button in the upper right corner. You also need to know your devtodev UDID (you can find it in SDK -> Integration section) or device advertising ID. You can even add several devices using "," (comma) as a separator.

To remove a device from the list, mark it and click on the delete button.

If the app is in the test mode all devices with this app are added automatically to the list of test devices.

Payments

Here you can change the revenue rate settings (i.e., specify which share of total revenue a developer gets; usually it’s 70% or 0.7) and set transaction checking terms .

Push Notifications

Here you can find and change push notifications settings and check its' status.

3rd Party Sources

App Marketplace Connect

Attribution Trackers

Here you can find the information about integration status with different attribution trackers.

Ad Spendings

devtodev provides integration with the most popular Ad networks to allow you to track Ad spendings: AdColony, Unity Ads, Chartboost , Iron Source.

AdColony

To turn on the integration with AdColony you need to specify read-only API key and App Store ID. The API key can be found in the AdColony account settings. You can find App Store ID in the app URL on iTunes after “app/”.

Unity Ads

Game ID is located in Unity Ads ad network. To find it, select “Games” from the left-hand side of the Unity Ads dashboard.

Chartboost

Iron Source

To integrate IronSource you need to specify Username, Secret key and App Store ID. Username is the login/email that is used to log in to Iron Source system. To retrieve Secret key, click on your username at the top right corner of the Iron Source dashboard, and select My Account. You will find the Secret key in the Reporting API section. You can find an iTunes App ID in app URL on iTunes after “app/”.

Ad Revenue

To track revenue from advertisement devtodev provides integration with the following Ad networks: Vungle, Unity Ads, HyprMX, Fyber, Facebook, MoPub, AdMob, AdColony, My target, Applovin and Yandex . The integration is very easy - you just need to fill in several fields. You can find information about required fields by pressing "?" button in the top right corner of a network panel.

GDPR Settings

According to GDPR that came into effect on May 25, 2018, every user has right to be forgotten and their personal data must be stored for a limited amount of time. According to it, personal data can be retained no longer than its processing requires. In this section you can specify the period after which your users’ personal data can be erased from devtodev. The check is being performed once a week.

Custom Settings

Custom settings section allows you to group applications in reports by definite custom attribute.

For instance, it can be project manager name or creation date. Any type of grouping the application can be set right here. Press the "Add custom settings" to add the data.

This block of reports allows to analyze users acquisition in your application. To start analysing user acquisition in your app, you need to:

• Integrate an attribution platform (we support Adjust, AppsFlyer, Tune, Branch, Kochava and Tenjin) using postback URL's from the Integration section (Settings > 3rd party sources > Attribution tracking). Please note that to do it you must be in Admin or Owner role.

• Integrate devtodev SDK into your application and you will be able to evaluate the quality of your traffic in devtodev. Learn more on the page below:

Acquisition reports:

• Acquisition Dashboard

• Monitoring

• Detailed stats

• LTV Prediction

Acquisition Dashboard

This dashboard contains acquisition data overview by traffic sources:

• General ratio between paid and organic traffic

• Distribution of new users by countries

• Cumulative ARPU for top 5 traffic sources (top is based on the number of users)

• More detailed information about top sources in a table view

Click a 🔎 to open a more detailed report.

Monitoring

This report allows to measure the efficiency of incoming traffic.

Select up to 5 different sources, campaigns or countries (depending on the tab) and click “View result” to monitor key metrics: Installs, Gross, ARPU, Paying conversion, etc.

Also, you can compare some financial and behavioral metrics for selected sources, such as Cumulative ARPU, Retention, ROI, Payback period, etc.

Detailed Stats

This table contains all basic info about traffic sources. You can add any metrics to compare by clicking the “Metrics” button.

If you are using the Custom Postback API or install referrer (SDK), you can select the necessary trafic sources in the filters.

Conversion in Event

You can also add a specific custom event to determine conversion into action. It allows you to assess the quality of traffic acquired from different sources because if users perform key actions in the app, it could be an indicator that they are interested in the app and the product is clear for them.

For example, you can examine the following conversion rates:

• To passing N levels in the game

• Registration in the app, especially if it is recommended to continue working with the product

• Entering body characteristics for a fitness app

• Completion of the first lesson in an educational app

Data can be grouped by country / campaign / publisher, moreover sub categories can be applied.

Click Filters to apply additional filters or segment.

LTV Prediction

Check out the Predictions section to learn more about LTV Prediction!

The Real-time dashboard shows key metrics on a current day in comparison to the previous day. It allows you to keep track of your app’s performance in real time. The information in this report is updated every 5 minutes. Here is the full list of real-time widgets in this dashboard:

• Gross

• Cumulative gross

• New users

• Cumulative new users

• Sessions

• Cumulative sessions

• Users online

• Top countries (by new users or by gross)

Overview

This is a list of all custom events with general statistics for each of them:

• The total number of events for a selected time period

• The number of users who completed these events

• The average number of events by user (calculated as the total number of events divided by the number of unique users)

The default time period for the overview is last 7 days, you can change it with a calendar button.

Reports in this section cover key monetization metrics.

Monetization reports:

• Monetization Dashboard

• Subscription monetization

• Ad monetization

• Gross Structure

• Conversion to Payments

• Cumulative ARPU

• RFM Analysis

• Payment amounts

• Transactions

Monetization Dashboard

This dashboard contains an overview of key monetization metrics. All data is shown for a selected period of time (you can change it in the top right corner), default period is the last 7days.

The top two widgets show the dynamics of Gross & ARPU and Paying share & ARPPU metrics.

Three pie charts below show Gross, Paying users and ARPPU for top 5 countries and the “other” group (includes all countries that didn’t get in the top by certain metric).

The following widgets show more detailed info about repeated payments:

• Repeated payments share in the total revenue

• Users grouped by the number of transactions

• User conversion funnel based on the number of purchases made

• Users grouped by a period within which the first purchase is made

Click a 🔎 to open a more detailed report.

Subscriptions

These reports focus only on subscription analysis and don’t cover any other app monetization models. The reports contain information on the essential app metrics, which are built on the subscription data received from devtodev SDK and app stores. Integration with stores allows you to receive information about subscription purchases even if the user doesn’t open the app (auto-renewable subscriptions).

Overview

The report includes several widgets with information on different aspects of the essential metrics of the app’s subscription monetization model.

List of metrics found in this report:

• Subscription gross - revenue received from subscriptions over a selected time period.

• Recurring gross - revenue from all active subscriptions adjusted for a specific time period. Different widgets use different groupings, therefore the metric would get adjusted to different periods (daily, weekly, monthly - Monthly Recurring Revenue). For example, one user has a $30 active monthly subscription, plus two other users have $60 annual subscriptions, then the monthly adjusted Recurring gross (MRR) = $30/1 + 2*($60/12) = $40.

• New trial users - users who activated the trial version for the first time during the selected period.

• New subscribers - users who made their first subscription payment within a given period.

• Activated subscribers - users who made a payment within a given period.

• Churned subscribers - users with Expired/Refunded subscription status over a selected period (these users had paid subscription, but did not renew their subscription during the Grace period).

• New user to trial conversion - the percentage of new users that have converted to trial over the selected time period.

• Trial to subscriber conversion - the percentage of users that have converted to a paid account from a trial period.

• New user to subscriber conversion - the percentage of users registered within a given time period who made at least one subscription payment afterward. The percentage is taken of all users registered over the given time period.

• Active subscriptions - the number of active subscriptions by the end of the aggregation period.

• Active trials - the number of active trials by the end of the aggregation period.

All data is displayed for a selected period (you can change it in the top right corner), the default period is the last 7 days. You can also specify the country, install dates, or user sources in the filter next to the selection of the reporting period.

The first widget named ‘Overview for selected period’ contains general information about metrics that you can use to track several key subscription indicators at once.

The following two graphs show your daily income flow and recurring gross, as well as the dynamics of active subscriptions and active trials of your app. You can use them to track any changes in your app and respond to them quickly.

Next, you see a group of pie charts with information about Subscription gross, New subscribers, and the number of active subscriptions at the end of the selected period, broken down by the top-5 subscription bundles by gross.

The following widgets show daily dynamics of the number of new users, new trial users, subscribers, and their conversions.

Below them you can see a funnel with aggregated information for the selected period - the data on new users and their conversion to subscribers (light blue funnel and data signatures), as well as data on conversion of new users to trial, and then to subscription (blue funnel and signatures). It also contains information about the median time required to move through each stage of the funnels.

Structure

Use this report to run an in-depth analysis of the structure of subscriptions purchased by your users and the income earned from them.

Depending on the options selected in the ‘Group by’, the report will show you all the components of the metric of your choice:

• Subscriptions bundle - with a breakdown by top subscriptions.

• Subscription state - with a breakdown by subscription status. For example, the selected ‘Subscription gross’ metric is composed of:

+ New - the amount of income from users who bought the subscription for the first time.

+ Renewed - the amount of income from users who renewed their subscriptions for the next period.

+ Reactivated - the amount of income from users who bought the subscription after they were previously marked as Expired or Refunded (Churned).

+ Upgraded - the amount of additional income (the difference between the more expensive new subscription and the previous one) from users who bought a more expensive subscription.

− Downgraded - the amount of lost revenue (the difference between the cheaper new subscription and the previous one) from users who bought a cheaper subscription.

− Refunded - the amount of money spent on refunds.

Churn - the income lost because users didn’t renew their subscriptions that expired during this period. Churn is a purely informational metric that is not involved in the calculation of metrics - it can let you know how much income could be earned from 100% of renewed subscriptions.

In this report, you can also analyze other metrics. In the ‘Metrics’ selector choose:

• Number of subscriptions

• Subscriptions gross

• Subscriptions recurring gross

• Subscriptions refunded gross

• Refunded subscriptions

Here you can also analyze specific subscriptions, for example, monthly subscriptions only. To do this, click the ‘Subscriptions’ option and open a drop-down menu with all available subscriptions grouped by their duration.

The ‘Aggregation period’ option allows you to aggregate data to see the daily, weekly, and monthly dynamics.

By clicking on any of the chart columns, you will get information about this period. If you need to analyze all periods at the same time, click the button at the top right corner of the report to download a .csv file with the table containing a description of all periods presented below the chart.

Retention

This report shows the influence of subscriptions on user retention, on how often they renew their subscriptions (Subscription retention).

The first column in the table shows the time period and the number of users who purchased the subscription for the first time during this period. The report’s time frame (at the top right corner) limits the time of the first subscription purchase (the time of entering the cohort).

Each line contains information about a specific user cohort (the users who bought their first subscription during the corresponding time period). The columns contain the sequential numbers of renewed subscription purchases.

Let's look at an example of how users renew their subscriptions. Select the ‘Number of subscriptions’ metric:

Here we see that in the first week of August 2023 1486 users purchased the first subscription, then 400 of them renewed it (with a conversion rate from the first to the second subscription of about 27%), then 70 of them renewed the subscription again (4.7% of the initial cohort).

The following metrics are available for analysis in the ‘Metric’ selector:

• Number of subscriptions - the number of purchased subscriptions and the number of subsequent renewals.

• Subscription conversion - the conversion into purchasing the Nth subscription. It is 100% for the first period, and for each renewal period, it equals the ratio of users who activated the Nth subscription to the number of users who bought the first subscription.

• Subscriptions gross - the amount of income earned from the first and renewed subscriptions.

• Cumulative subscription gross - is calculated by cohort as the sum of income for all periods including the current period.

By using the ‘Aggregation period’ selector you can group users by the dates of their first payments - by days, weeks, months.

By using the ‘Periods since first subscription’ selector you can limit the time for collecting data on subscription renewals and including them in the report. For example, if you set the time frame as January 2023 and 11 subsequent months in this selector, then you will analyze data on all subscriptions purchased by these users during 2023.

In this report, just as in the ‘Subscriptions structure’ report, you have access to the ‘Subscriptions’ selector which allows you to analyze the specific subscriptions of your choice. We recommend analyzing subscriptions with the same duration in this report. In this case, the sequential numbers of subscription renewals can be interpreted as subscription lifetime - the number of periods that users resubscribe to certain subscriptions and continue using the app.

Filters and User Cards Updates

Each event performed by the user will be marked with additional parameters depending on the user's subscriber status at the time of these events. In most reports, these parameters will be available as filters:

Subscription state - the current state of the user's subscription, which can have the following values:

• None - the user does not have and never had a subscription

• Unsubscribed

  • Expired - the user's active subscription has expired, and they didn’t renew it during the Grace period.

  • Refunded - the user has refunded their subscription.

• Trial - the user is using a trial period of any subscription

• Subscribed

  • New - the user purchased a subscription for the first time.

  • Renewed - the user renewed their subscription (using the auto-renew option or manually during the Grace period)

  • Reactivated - the user purchased a subscription after being previously marked as Expired or Refunded.

  • Upgraded - the user purchased a more expensive subscription.

  • Downgraded - the user purchased a cheaper subscription.

Subscription prev state - the user's previous subscription status. You can use it to find those users who converted to the paid account from the trial period or to find those who activated other subscriptions after refunding.

Subscription bundle - the name of the subscription active at the time of the event (you can compare the behavior of users who purchased a subscription to one part of the functionality with those who purchased a subscription to another part).

Subscription sum - the income from all subscriptions purchased by the user (use it to range users by the amount of payments).

Subscription count - the number of subscriptions purchased by the user (use it to find out more about actions taken by users who purchased a subscription one time only)

The same parameters will be available in user cards - use them to analyze the user's current subscription status. Information about all payments and refunds related to subscriptions will be added to the ‘Payments’ tab.

If multiple subscriptions are available in the app (the situation where a single user has several active subscriptions from different groups at the same time), then in the ‘Subscription state’ you will see data on the aggregated state of the user's subscriptions. Aggregation occurs once the next subscription event is received. If the user already has an active subscription, the highest priority status of any active subscription is taken as the state (the list of statuses in the ‘Subscription state’ is sorted by priority in ascending order, none is the lowest priority state, downgraded - the highest priority).

Considerations

2-day delay: Markets may send us events with a 2-day delay. If you don't see the latest data, please wait a while.

Subscription prices: The app stores do not make individual transaction prices directly available to developers, so devtodev tracks prices at the time of purchase and assumes any subscriptions will renew at this purchase price. Therefore, if you ever raise the price of a product, devtodev reports will be accurate if you choose to grandfather existing subscriptions at the current price.

Partial refunds: If a user wants a refund, stores still will not give us information about the total amount of money they paid. Therefore, we calculate the refund based on how many days are left on the subscription.

Non-existent user: In case we see a transaction from the store but we don’t have any information about the user who made it, we will wait for the information about the user for two days. If the user opens the product within two days, we can correlate them with the transaction, otherwise, we leave it anonymous. Read more about subscriptionHistoryWithTransactions here.

Ad monetization

The report helps you evaluate how users interact with ads in your application.

General Report

The report contains the most common ad performance metrics that we get from Ad networks: ad revenue, ECPM, impressions, average impressions per user, average impressions per session, ad clicks per user.

All data is shown for a selected period (you can change it in the top right corner), the default period is the last 30 days. You can also specify the country or ad network in the filter next to the selection of the report period:

• by adding a country filter, you can measure the effectiveness of ad monetization adjusted for geographic location;

• by adding an ad source filter, you can analyze the effectiveness of a specific ad network.

The report consists of several widgets:

The first widget named Total info for selected period contains general information about metrics that you can use to track several key indicators at once. Metrics are summarized by the ad networks integrated to the project:

• The Ad impressions metric shows how many times ads have been displayed over the selected period.

• Average impressions per user - the average number of ad impressions per user.

• Average impressions per session - the average number of ad impressions per session.

• Ad CTR - the number of clicks on ads divided by the number of their impressions in the application.

• Ad clicks - the number of clicks on ads for the selected period.

• Ad revenue - advertising revenue.

• ARPU by Ad - the average ad revenue per active user for the specified reporting interval. The indicator is calculated by summing the total revenue of the application and dividing it by the number of active users for the specified reporting interval.

You can use this widget to quickly assess the advertising revenue status and other metrics.

The Ad Revenue by network chart depicts ad revenue by ad networks. It shows the percentage of revenue from each ad network:

Ad Revenue by country chart shows ad revenue by country. You can see the percentage of ad revenue in country breakdown:

The Ad metrics per user graph depicts ad revenue, impressions, and clicks per user by days.

The Ad metrics graph displays the following metrics: Ad impressions, Ad revenue, Active users. Thus, you can see the relationship between the number of active users and the advertising income and promptly respond to changes in the number of ad impressions in your application.

Below the charts you can find a table with information about the following metrics:

• Ad revenue.

• Ad click - the total number of times users click or tap on ads shown on your application.

• Ad impressions.

• Ad CTR - the number of times users click on ads shown divided by the number of times ads are shown.

• Ad ECPM - effective cost per thousand impressions. eCPM is an estimate of the revenue you receive for every thousand ad impressions. The higher the eCPM rate is, the better, because it means that the ads shown in the application are doing their job and converting users. You can use this metric to compare ad revenue across ad networks and countries. Therefore, you can select the desired grouping above the table.

Using the Detailed stats chart, you can analyze the following metrics: Ad revenue, Ad clicks, Ad CTR, Ad ECPM, Ad impressions, and ARPU by Ad by weeks. You can also group them by ad network or country.

Advanced report

This section is available only for the accounts linked to the ironSource ad mediation platform. The platform allows you to run an in-depth analysis of your ads and user feedback on it.

To the data in the table, you can apply different groupings as well as double grouping by any of the following parameters: Country, Ad source, Ad unit, Ad Placement, Ad network, etc.

The metrics applicable here are the ones available for the ‘General report’ and others:

• Users saw ad - The total number of unique users who saw an ad over a given time period.

• % of users saw ad - The percentage of users who saw an ad out of all active users. The indicator is calculated by dividing the number of unique users who saw the ad by the number of active users.

• Impressions per user saw ad - The average number of ad impressions per user who saw an ad over the time period. The indicator is calculated by dividing the total number of ad impressions by the number of users who saw the ad.

• Ad revenue per user saw ad - The average ad revenue per user who saw an ad. The indicator is calculated as total ad revenue divided by the number of users who saw the ad.

• Ad impressions per user - The average number of ad impressions per active user over the time period.

If a part of your users fell into the Unknown category, it means that their ad ID was changed and we failed to match them with devtodev users. If you want to convey the trend of a metric over time, you can turn it into a graph that appears below the table.

In Funnels, Custom events, SQL, User flow, New user path, Last user activity (Users), Retention by event reports you can find an auto-created Ad_impression event with the following parameters: Ad network, Ad placement, Ad unit, Ad revenue, Ad Source/ In the user card in ‘Users’ and in the report filters, you can use the following two fields:

• Ad revenue - the ad view revenue generated by a specific user

• Ad impressions - the number of times ads were served to a specific user

Gross Structure

This report presents a set of charts with total stats and day-by-day dynamics for a selected period of time.

Default report period is the last 30 days, you can change it in the top right corner. You can configure a filter in the report or use already created filter template or custom segment to get more detailed data. To apply changes press “Refresh” button.

You can group data in the report with several options:

• Top 5 countries defined by a certain metric, and “other” group (data for all other countries)

• Paying capacity (non-paying / minnows / dolphins / grand dolphins / whales / grand whales)

• Days from app install

• Number of payments

Click a 🔎 to open a more detailed report in Basic Metrics.

Conversion to Payments

This report shows info about users' repeated purchases and time they spent in the application before 1st, 2nd, etc purchase.

The top part of the report shows the conversion funnel based on the number of purchases made and detailed info about each step of the funnel in the table: number of users, revenue, median number of payments, median period of time from the first launch until the payment is made.

The last chart shows the number of paying users grouped by two options:

• Days from install until the payment

• Users’ in-game level of experience

It is also possible to check the stats for users with certain number of purchases using a Payment number option on the widget. The right part of the last chart contains shares of paying users distributed by predefined groups. When you change widget settings, these numbers also change.

Default report period is the last 30 days, you can change it in the top right corner. You can configure a filter in the report, use already created filter template or custom segment to get more detailed data. Changes are applied automatically.

Top converting goods

This widget contains the information about the top 5 items that users bought as the first purchase. Also, you can expand this report by using the button in the top right corner to see which items were purchased as the second purchase for each of these items.

The report contains the following metrics:

• % of all purchases – a share of purchases for this item among all of the first purchases

• Conversion to 2nd payment after the purchase of the specific item

• Average number of payments by user

• ARPPU – an average revenue that paying users generate for items they purchased, including items that they purchased after they bought specific items as 1st and 2nd purchase

With this widget, you can define the most popular items that your users prefer to buy firstly after they start using your app. Also, you can see the most frequent sequence of purchases and find out which of them more likely lead to repeated payments and more profitable purchases.

For example, you could find out that after users buy item A they are more likely to buy item С and based on this information you could plan your offers strategy and show item С for such users.

Save to dashboard

You can save three charts as widgets and add them to the custom dashboard. Click on Save to dashboard button, select the chart name and the dashboard where you would like to add the report.

Available charts: Period until payments, Conversion to N payment and Top converting goods.

Cumulative ARPU

Cumulative N days ARPU is one of the most important metrics of any product. It shows how much money does one average user bring to the project within his/her first N days in the project.

By default devtodev calculates this report for first 30 days of user's lifetime in the project, but you can change the number of days above the chart.

Note that metric “Users, %” shows the calculation user base: how many users (in percentage of the total number of users from the report) were used to calculate the value. For example, if you set the "last 30 days" as install dates interval, and build report for 30 days, there is only one daily cohort which will be used to calculate the ARPU of day 30.

There are two different views in this report:

• Cumulative ARPU. In Cumulative ARPU view you can see the number of installs for each cohort, the total gross each cohort brings within the report time frame.

  The main part of the table shows the cumulative ARPU values for specific days and specific cohorts (cohort is the set of users who installed the project on some specific day(s); every string in the table represents some user cohort). 'Aggregated CARPU' above the table is calculated as weighted average cumulative ARPU (where the weights are the cohort sizes in "Install" column).

• Daily ARPU. In Daily ARPU view you can see how much money does average user from the cohort bring to the project on some specific day. There are two aggregated values above the table:

  • 'Aggregated CARPU' above the table is calculated as weighted average cumulative ARPU (where the weights are the cohort sizes in "Install" column).

  • 'Avg. daily ARPU' above the table is calculated as weighted average daily ARPU (where the weights are the cohort sizes in "Install" column).

By analyzing this report vertically you can track the changes of project quality: you compare the same metrics for different time cohorts. By analyzing this report horizontally you can track the payment behavior of each cohort.

You can filter users anyhow by selecting the filter under Add filter button.

This report can be saved to a custom dashboard as a widget. Click on Save to dashboard button and select the dashboard where you would like to add the report.

Aggregated Cumulative ARPU

Cumulative ARPU is one of the key product metrics as it becomes Lifetime Value overtime when it stops changing significantly. Using our new Aggregated CARPU metric in the Cumulative ARPU report, you can track how different cohorts of users spend money, compare those cohorts, and evaluate how different activities influence the metric.

Sometimes, when experiments happen rarely or influence finance metrics only slightly, there is no need to track CARPU every day and compare daily cohorts – that is why we recently added an option to group CARPU by days, weeks or months.

For example, when you select weekly aggregation, the cohorts will be grouped by calendar weeks and CARPU will also be calculated by weeks from the install date. The grouping will be applied to rows and columns of the table. It will allow you to see the dynamics of a bigger cohort of users that might be hardly noticed with daily aggregation.

Please note that the Aggregated cumulative ARPU graph is not cumulative over the entire period and the Cumulative ARPU values on certain days can be lower than the previous day. This is due to the fact that the Aggregated cumulative ARPU is calculated as a weighted mean of all the selected cohort values every day since the installation. The number of cohorts that are part of the calculation will slowly decline because they don’t meet the criteria of having enough days after the installation. Let’s look at an example:

Day 17 CARPU is calculated for all selected cohorts because they were built at least 17 days ago. Day 18 CARPU is calculated only for eight cohorts because the seventh (built on December 29th) hasn’t “lived” for 18 days.

The CARPU of the users from the seventh cohort is higher than that of the users from other cohorts. When we eliminate this cohort from the calculation, the weighted mean decreases because its high CARPU increased it.

RFM Analysis

This report shows the distribution of users into certain groups depending on the recency, frequency and total amount of their payments. The analysis of this type is aimed at studying user payment behavior in order to be able to create a relevant offer for each group.

How to apply it?

Use this report to influence the paying users who made their last payment a long time ago: send them a push notification with a discount or a promo code. Create segments of ‘lavish spenders’ and ‘lapsed payers’ and compare their behavior using different reports - User path, Cohort analysis, User flow, Basic metrics, etc. to identify their behavioral patterns.

What does RFM stand for?

RFM stands for Recency, Frequency, Monetary. Recency – time since the last purchase, i.e. the number of days that have passed since the last purchased. Frequency – frequency of user purchases, the number of payments over the entire period of user's engagement with the project; data is retrieved from the user card. Monetary – total amount of money a user spends in the project, a total amount of payments; data is retrieved from the user card

When building a report, each paying user is given three scores from one to five, where 1 - is the lowest value and 5 is the highest. For example, if the last transaction occurred a long time ago, then the user is given 1 point for Recency. If the user makes regular payments, he will get 5 points for Frequency. If his total amount of payments is higher than the average, he will get 4 points for Monetary, etc.

After all scores are assigned, users are divided into ten segments: Can’t Lose them, Hibernating, At Risk, Loyal Customers, Champions, Need Attention, Potential Loyalists, About To Sleep, Promising, New Payers.

The report can display data in two modes:

1. RFM diagram. Each user has three RFM scores. To make the interpretation of results more straightforward, we united Frequency and Monetary criteria so that you can see segments on a graph with two axes , where Y axis represents scores for (Frequency+Monetary)/2 and X axis represents scores for Recency. Therefore, user segments are presented by criteria: in the top right corner you can see frequent lavish spenders who made a purchase recently and in the top left corner frequent lavish spenders who made their last purchase a long time ago. The size and position of the blocks is fixed and does not depend on the number of users in the cohorts.

2. RFM audience share. The diagram depicts the same user segments distributed by the share of an RFM segment in the total number of users that were in the analysis. On the screenshot below you can see that the current project is dominated by the ‘Hibernating’ segment (last purchase was made long ago, low spenders, infrequent buyers) and its share is 33.88%.

For more information, click one of the segments: what audience it contains, the number of users, recommendations on interaction with the segment:

Each designated segment can be:

• exported to a CSV file,

• used to create a new segment for further use in other reports,

• used for sending push notifications to the entire audience,

• exported cohort to Ad network.

User segments

Range thresholds for RFM

The following values are set by default: if the user made his last purchase more than a month ago, then his Recency =1, if he made from 4 to 7 purchases, then his Frequency = 3, and if his total payment volume is more than $500, then his Monetary = 5. To change the point allocation criteria, click ‘Configure RFM scores’ in the drop-down menu in the top right corner. Click ‘apply’ to save the changes.

Payment amounts

This report shows the distribution of users by the number of payments they made and the total amount of money they paid. For example, in this report you can see how many users registered during a specified time period and made 5 payments with the overall sum of $0 - $5.

Default report period is the last 30 days, you can change it in the top right corner. You can configure a filter in the report, use already created filter template or custom segment to get more detailed data. Changes are applied automatically.

Transactions

This report shows the detailed list of transactions that are made in the app on a particular date. The current date is specified by default.

The following filters are available:

• Source of transaction

• Type of transaction (normal, test, invalid, cheat transactions)

If the list of transactions exceeds 1000, you will be suggested to export a full list as a .csv file. Moreover, you can initiate export manually by clicking the “Export” icon.

Key metrics forecast

This dashboard allows you to plan revenue and other main project metrics.

Уou can see widgets with the forecast for following metrics:

• Gross (Daily, Weekly and Monthly)

• Daily Active users

• Daily ARPU

• Retention Day 1 and Day 7 (Daily, Weekly, Monthly)

The forecast will be built for 7 days if there is data for more than 3 months available.

The forecast will be built for 14 days if there is data for more than 6 months available.

LTV Forecast

This tool gives you a fairly precise LTV forecast powered by Machine Learning. Training data for the machine learning algorithms are payments and other activities of users who use your app for at least 3 days. Later on, after we acquire more data about cohorts, the model is recalculated and the forecast accuracy improves even more. It happens on the 7th and 10th days of the cohort’s ‘life’ in the app. We calculate user LTV on their 7, 14, 30, and 60 days since app install.

Why use LTV:

• Traffic quality evaluation. When purchasing traffic, it should be considered that you need to keep the cost per install (CPI) less than LTV, otherwise purchasing such traffic will only lead to losses.

• Finding out the exact time when you will recoup acquisition costs.

• Finding out how much revenue you will earn from existing users and planning your budget

Requesting the report

By default, the functionality is available for all apps. If you would like to get a report, navigate to your project, click the ‘Forecast’ tab, open the ‘LTV Forecast’ report, and request model building. Notice that if you want us to build an accurate model, your app has to meet certain requirements:

• The app is integrated with devtodev for at least 90 days.

• The MAU is 30k or more

• Payment events are integrated.

• Custom events are integrated.

LTV forecast for day 360

After your D7, D14, D30 and D60 LTV models have been run for 390 days for a particular project, you will get access to an LTV forecast for day 360. The forecast results will be displayed on all report tabs automatically.

If you have just connected a new project to devtodev and would like to get a day 360 LTV forecast, you need to request us for building of a model as described above and wait for a year. This delay is due to the fact that we need to collect one year of data about the project for generating a more accurate yearly forecast.

Or, if you have historical data for more than 390 days, you can upload it to devtodev using this instruction. Then, we can use the data to train our LTV forecasting model (and to build a forecast for day 360).

Please note that if you choose to follow this path, you need to inform us about your wish to receive a day 360 forecast before completing the process of historical data import. Contact your manager using the ‘Contact Us’ form on the devtodev website or via email - info@devtodev.com

By days from install

In the top right corner, you need to specify a date range. It will limit the dates of users’ first visit to the app (keep in mind that we can calculate LTV only after three days since install, so the latest three calendar days will be unavailable). The chart below represents revenue per average active user after 1, 2, ..., N days from the first visit (Predicted LTV) and the amount of money they have brought in till now (Actual LTV). For the Actual LTV calculation, we take into account only the income earned for the number of days all the selected cohorts have ‘lived’ in the app. Therefore, when on the 31st day you build a report on users acquired from the 1st to the 10th day, you get the Actual LTV data for 20 days because the cohort that came to the project on the 10th day has ‘lived’ for 20 days only.

‘Overview’ above the graph and the table below it display the traffic sources, the amount of money spent on their acquisition, the income earned, and the expected total revenue from all the cohorts after 60 days in the project. In case you need to select only a specific user segment, you can apply a wide range of filters on each report page, and build the LTV forecast only for your target audience.

By calendar dates

The second page of the report shows how the Predicted LTV metrics are changing over time. Here for any selected N-days Predicted LTV metric you can see the deviation between the Predicted LTV and the Actual LTV for every cohort according to their install dates.

For the latest N-days, we can’t calculate the actual LTV, so we use gray candlesticks to show predicted data and the dashed blue line to show the actual data.

When you move the pointer over a cohort, you can see the intervals of predicted lifetime values (from min to max), and the actual LTV.

Detailed stats

The third ‘Detailed stats’ page is represented by a table that shows all the necessary information about your traffic and its profitability. For every group in the table, you can see the actual and predicted N-days LTV and the ROI for N-days. Data can be grouped using up to three levels by Countries, Sources, Channels, Campaigns, Platforms, and Languages. For example, if you want to see the progress of your Ad campaigns in terms of traffic sources and then examine how well it goes in every country, you can set Group by Campaigns, Sources, and then by Countries in the report settings. Keep in mind that the more groupings you choose, the fewer users you will have in each group and the less precise your forecast becomes.

The table can be exported as a .csv file by clicking the ‘Export’ button in the top right corner.

Payment prediction

devtodev uses Machine Learning algorithms to identify paying users before they make their first payment. We predict payment behavior of each individual user and assign them a value from 0 to 1, where 0 - the user will not pay, 1 - the user will make a payment sometime in the future. Based on these values, users are automatically divided into groups: - will pay - more likely to pay - more likely not to pay - won’t pay not yet defined (the user is completely new and the probability is still being calculated).

In the user card, you can find this information in the ‘Predicted paying status’ field.

The ‘Predicted paying status’ field can be used in reports as a filter, for creating segments, or for sending push notifications.

In the ‘Predictions’ section in the top menu you can find a ‘ Paying status prediction’ report that contains statistics on the probability of making a payment by new users.

The users who installed the app during a certain period of time are grouped by the probability of making a payment: will pay, more likely to pay, more likely not to pay, won’t pay.

The data for the same period may change over time because the predictive model is real-time and is regularly recalculated. The forecast on a user may be adjusted and the user gets moved into another segment.

Click a segment on the chart or in the table and open a menu with the following actions:

• Create segment (use a certain user group to build a segment for further analysis by using other reports)

• Export to CSV (export user data)

• Send push notification

• Create cohort for export (send an audience to Google Ads or Facebook to set up targeting for your ad campaigns).

The model is calculated on the basis of data obtained by the first, third, and seventh days since installation and it takes into account user actions in the application. After recalculation, the user’s status may change because the algorithms have processed more user behavior data. The forecast is automatically enabled for projects that meet the following conditions:

• There are 90 days of data During the 90 days, the basic and custom events (including the payment event) were sent

• The number of paying users is at least 1 per every 10,000 active users

• The average DAU is at least 300 At least one payment is made every 3 days

Visible notifications

Visible notifications is the most common type of notifications. Users receive a message, which is displayed in the notification center of their devices.

Languages

It is possible to sent notifications in several languages to make them more accessible to users from different countries. When the language used on a device is specified among languages of the campaign, the notification is sent in this language. In case there is no device language among languages of the campaign, the message is sent in the language that is specified as a default language.

To add or remove a language press the button with a ‘+’ sign.

First, you need to choose the language that will be used by default. In most cases it is English.

Each language is presented in a form of a tab. When switching between tabs, please fill the required fields with translations. Translations are necessary for such fields as ‘Title’, ‘Text’ and ‘Share text’ (if it is used). The rest of notification settings are general and do not depend on translations.

Title

A short line that describes the purpose of notification. Apple Watch displays this line as a part of notification interface. This line is displayed only briefly and should be written so that it can be understood quickly. This key was added in iOS 8.2.

Alert/body

The text of the alert message.

As long as the title and text are sent in a Unicode format, you can use texts and emoji supported by this format to diversify the way your notifications look. is here. We recommend you to test how messages with emoji are displayed on a device before sending them to wide audiences.

Badge

Optional. The number to be displayed as the badge of the app icon. If this property is absent, the badge is not changed. To remove the badge, set the value of this property to 0.

Sound

The value of this field is the name of a sound file in your app’s main bundle or in the Library/Sounds folder of your app’s data container. The sound in this file is played as an alert. If the sound file cannot be found or if you specify “default” as the value, the system plays the default alert sound.

Attachment

Available from devtodev iOS SDK 1.9, Cordova SDK 1.9, Unity SDK 2.3, UE4 SDK 1.9, Air SDK 1.8

Attachment delivery is available from iOS 10.

It is possible to attach image, video, audio, and GIF to your notification. Specify the type of an attachment ("image", "audio" or "video") and URL that leads to a media file. Please note that iOS uses only “https” protocol.

The following file formats can be used in attachments: "jpg", "jpeg", "png", "gif", "aif", "aiff", "mp3”, "wav","mpg", "mpeg", "mp4", "m4a", "avi".

The maximum file size that can be used in attachments is 5MB for audio files, 10MB for images and animation, 50MB for videos.

When using this option, keep in mind that attachments will not be displayed on some old devices. So create your messages in a way that they are informative even if the attachment is not displayed.

We recommend to optimize media files so that they are of a good quality and the minimum size. There is no point in sending images, which are more than 750 pixels wide.

If you use ad video, try to make it short and not use resolution formats above 720p (576p will be enough) with low frame frequency (24-25 frames per second.)

Collapse key

Multiple notifications with the same collapse identifier are displayed to users as a single notification.

Parameters

You can pass custom parameters with messages and use them within an app. For instance, you can activate advertising campaign or any other functionality for a user who has received this message.

With this function you will be able to send any data, the processing of which can be pre-programmed, in a key-value format to the app. For example, it is possible to activate a promotion or perform any other activity within the app.

Interaction

Action

The action after a click on the body of a notification. By default, a click opens an app. It is possible to perform the following actions:

• Home screen - this is the default behavior when a user taps on a push notification. It opens app’s home screen

• Deep link - directs the user to a specific resource either within your app or on the web

• Web page - opens a web page in a mobile browser or any valid device-level URL, such as Google Play or app protocol links

• Share - the ‘Share’ action drives users to share your message when they interact with your push notification. In case of selecting this action, don’t forget to specify translations of share texts into all languages used in your push campaign

Buttons

Before choosing the template of notification buttons, it is necessary to select the language of the message, which will be used by default (usually it is English).

Accessible button templates can be found in the table with button templates or directly in the interface.

After you have selected the template, you need to set the action of the button. We do not recommend to use actions that contradict the text on the button. Templates, which have a ‘Dismiss notification’ label, cannot have any other action except for closing the notification. In case you are not satisfied with the template you have chosen, you can replace (‘Set another template’ button) or delete it.

The set of accessible actions:

• Home screen - this is the default behavior when a user taps on a push notification. It opens app’s home screen

• Deep link - directs the user to a specific resource either within your app or on the web

• Web page - opens a web page in a mobile browser or any valid device-level URL, such as Google Play or app protocol links

• Share - the ‘Share’ action drives users to share your message when they interact with your push notification. In case of selecting this action, don’t forget to specify the translations of share texts into all languages used in your push campaign

Invisible notifications

Invisible notifications can be used in case you need to send some command to an app and make it invisible to users. Users will not see the message and will not be notified by a special notification signal. This kind of notification is aimed at the app, not users.

Parameters used for sending the data to the app are the same as described in the section about visible notifications.

Content available

Provide this checkbox to indicate that new content is available. This is used to support newsstand apps and background content downloads. Newsstand apps are guaranteed to be able to receive at least one push with this key per 24-hour window.

In this section you have several menu tabs:

Basic Metrics

You can change the following settings of the chart:

If you select any parameter in the ‘Group By’ dropdown list, except ‘None’, you will be able to see the result for the top values by ticking the box (Filter Top N).

This setting is optional for the ‘Main groups’ and mandatory for ‘Custom user properties’.

Also, you can select the number of top values to be shown (from 1 to 50) and select a specific metric to be displayed.

If you are going to group metrics by Custom user properties with numeric values, please note that only properties with up to 1,000 unique values could be used for grouping.

Moreover, you can turn in the following options:

• Trend – add a trend function

• Smooth – makes lines on the chart more smooth

• Cumulative – add a cumulative function

• Labels – if you previously created any labels, you can turn them on/off on the reports

• Data labels – it shows metric values above the graph points

• Axis scale – customize the axis bourndaries. Set the minimum or maximum value for the axis and click Save to apply the settings. To turn on automatic scaling again, remove the value and save the settings.

Default report period is the last 30 days, you can change it in the top right corner. You can configure a filter in the report. Use already created filter template or custom segment to get more detailed data. To apply changes press “Refresh” button.

For example, if you update your custom user characteristic that shows how many friends your players invited, you can later monitor the distribution of the revenue metrics by the number of users a player added. Also, you can now filter Top N by the chosen metric when the grouping is active. When you group by the custom values of the user card, the active grouping is obligatory. If you need to build a report not for the whole user set but for a user segment, you can click the "Segments" button. To build a report after you’ve defined all the settings, click the “View Results” button.

You can save the report for further, share it with teammates or on Slack. You can find these options in the top right corner under the “Menu” sign.

Conditional formatting for tables

Use this feature to highlight desired values in your tables, quickly evaluate metrics, and find relationships in the data.

It is available for tables in the ‘Basic Metrics’ or ‘SQL’ reports. After adding the report to a dashboard or sharing a link to it, conditional formatting remains intact. Click ‘Conditional formating’ above the table to apply the formatting.

It will open a new window where you can select formatting conditions for each metric. There are two types of formatting:

• Formatting by a specific value e.g. if the value is more than 5, the cell changes its color to the selected color.

• Formatting using a color scale. In this case, all cells in the row will change their color but the color intensity will differ – the bigger the value, the brighter the cell, and vice versa.

If you check the box of ‘Format total values’, then the color scale will be applied to the ‘Total’ columns.

If grouping is applied, the second type of formatting will have two more options. Let’s say, you sum certain metric values by day, then:

2. If ‘Format each column separately’ is selected, then the color scale is applied to each column separately based on its minimum and maximum values regardless of the metric values on other days.

Conversion Funnels

The Conversion Funnel report allows you to create conversion funnels based on the sequence of custom events. With this report you get statistics on the number of unique users who completed these events.

To build the report, choose up to 30 steps by clicking the Add step button. The sequence here is important: if you take A, B and C steps, first you will get the number of users who completed the A event, then the number of users who completed both A and B events, then the number of users who completed A, B and C events during a selected period of time.

To specify the value of step’s parameters, click Add parameter button to the right of the step, choose a parameter and set value’s condition. Choose dates when events are completed by modifying the date range menu on the top right of the page. Click View result to see the funnel.

You can also set:

• a time limit between two steps (Step time limit check button),

• make a step optional (Optional check button; in this case, two funnels will be built: with users who have and haven't completed the step) or set a time limit for the whole funnel. In the last case, if the user completes only 2 of 5 steps for the selected time, they will be calculated on these 2 steps, even if they complete all steps but it takes more time than you set.
• select Not to exclude the users who completed the event during the time frame specified in the report. If the user completed the event outside of the specified time frame, he will be included in the report.

  • The user will also be included in the report in case they have completed the same event before and after the excluded event. For example, the user completed events A-B-C-B. In the report with the funnel A -> B -> Not C the user matches the conditions because both B events are included in the report and there is no event C after the second event B .

• Alternative option allows to select several events for one step. For example, a user can register or login to an app, you can create a funnel that consists of steps with alternative actions.

You can also select the type for the funnel and choose between a table or a chart.

Also, you will be able to set the Aggregate by option to see how users progress through the funnel on specific days, weeks, or months. Alternatively, you can choose the Step option to view a simplified funnel. When specific data points (day/week/month) are selected, this chart will display the conversion rate and the number of users at different steps like if this funnel was built only for the data point (day/week/month). When the aggregation by steps is selected, the simplified funnel with the same metrics will be displayed.

For example, if you select aggregation by days and report time frame from July 1 to July 7, then for July 1 on the chart you will see only those users who started and finished the steps on that day.

Use the Conversion time limit setting above the report results to choose a parameter that will be used for limiting the conversion time window:

• without time limit

• Limit by time: specify the number of days, hours, and minutes that the user has to complete all funnel steps (countdown starts from the first funnel step completion). For example, you can build a funnel that a user completed within one hour after registration.

• Limit by first session: the specified steps must be completed during the first session. The first session needs to take place during the time frame specified in the report.

• Limit by number of sessions: all specified steps must be completed during a specified number of sessions. For example, Limit by number of sessions = 1 means that all funnel steps must be completed during a single session, but not necessarily the first one. To calculate the funnel, we take an event that satisfies the first step of the funnel and add a specified number of sessions to it.

To set a filter based on app version, channel, device or some custom segment, click the Filter button on the top right of the page. Compare the funnel for different segments by clicking Add comparison. The funnel will be built after clicking View result or Refresh buttons.

The number of unique users that completed events during a chosen time period is presented in the vertical axis of the chart.

After the funnel is created, you can see a grey icon to the right of each funnel step. A click on this icon shows the menu with the following options:

• Conversion by days. When the Aggregation period is disabled, you will be able to see conversion dynamics for steps. It shows the distribution of the conversion by days between two neighboring steps. The denominator for this conversion always stays the same – it is the number of users who performed the funnel step. The numerator contains the number of users who converted on a specific day. For example, if you build a funnel from the 1st to the 7th of July, then for the 3rd of July you will see the users who performed the specific step on the 3rd of July related to users who performed this step for the whole period (1st to 7th of July).

• Create segment of step-completers allows to create a static segment, which contains users who completed funnel steps to the current one inclusively

• Create segment of step-droppers allows to create a static segment, which contains users who completed all previous funnel steps but churned on the current step

• Export step-completer IDs: export the IDs of users who have reached the selected step to a CSV file

Also, the results of the funnel can be exported as a .csv file by clicking the Export button in the top right corner. The funnel can be saved by clicking the Save button in the top right corner. It will be available in the funnels list in the Conversion Funnel section. You can also save the funnel to a custom dashboard by clicking Save to dashboard:

Custom Events

Custom events are used to track particular user actions, which you specified for your app, such as:

• Any action a user takes in the app (hits, shoots, moves, putting an item into the basket, etc.)

• Taps on certain menu elements.

• Users' search for items in a virtual shop, etc.

You can track both events and their parameters (properties) and you can set up to 20 parameters for each event. For example, if you have an event for battle creation, parameters can be duration, map, number of players, battle mode, etc.

When one or more events are integrated, you can start using the Custom Event report.

To build the report, select up to 3 events above the report, and to set a filter for event parameters, select a parameter and value.

You can change the following report settings:

• Metric type – what you want to calculate; and it can be one of the following:

  • Number of events – the total number of performed events. It can be, for example, the number of item views or item category views, the number of shop openings from a certain screen.

  • Number of users completed event – count of unique users who completed events. Use it, for example, to calculate the number of users who shared a link or the number of users who logged in using a certain type of authentication.

  • Number of unique parameter values – count the number of unique parameter values. It can be, for example, the number of unique game areas opened by the users from a specific country or, if you pass the title of the article viewed by the user, you can find out the number of unique articles viewed by users.

  • Average parameter value – to see the average parameter number, select a metric and choose the parameter you want to calculate next to it. You can find out the average price of the viewed items or the average delivery price, the average user age, etc. if you pass these parameters.

  • Average number of events per user. Use it to find out the average number of combats the user engaged in, or how often they use the app for training.

  • Average sum of parameter values per user. To calculate the average sum of parameter values per user, select a metric and choose the parameter you want to calculate next to it. If you, for example, pass video view duration or combat duration, you can calculate the average sum of time periods the user spent battling or watching your video content.

  • Sum of the parameter values. To calculate the sum of parameter values, select a metric and choose the event parameter you want to sum next to it. If you, for example, pass the order value as a parameter, you can see the sum of all orders.

  • Minimum number of events per user. Use it to find out the minimum number of viewed ads longer than 10 min or the minimum number of processed photos in possession of paying users.

  • Minimum parameter value. To calculate the minimum parameter value, select a metric and choose the parameter you want to calculate next to it. You can, for example, group orders by acquisition channels and find out the one with the least sum.

  • Maximum number of events per user. Use it, for example, to find out the maximum number of live ops events your users participate in, the maximum number of ad views per user broken down by app version, etc.

  • Maximum parameter value. To calculate the maximum parameter value, select a metric and choose the parameter you want to calculate next to it. If you, for example, pass the discount percentage as a parameter, you can find out the maximum discount applied by your users, or, if you pass the combat duration, you can find out the longest combat duration to adjust the fighting sessions.

  • Median of parameter values. To calculate the median of parameter values, select a metric and choose the parameter you want to calculate next to it. If you, for example, pass the number of coins sent to a friend as a parameter, you can find out the median number of coins your players send to their friends.

  • Median number of events per user. Use it, for example, to find out the median number of completed training sessions with breakdown by training types or the median number of completed quests.

  • Median of the sum of parameter values per user. To calculate the median of the sum of parameter values, select a metric and choose the parameter you want to calculate next to it. Use it, for example, to calculate the median revenue from a paying user. % of users completed event among active users. Use it, for example, to find out the percentage of active users who view items and make purchases, the percentage of active users who participated in a live ops event, etc.

  • % of total events (available with the grouping only) – the proportion of the number of events of the specific segment from the total number of events

  • % of total unique users (available with the grouping only) – the proportion of the number of unique users of the specific segment from the total number of unique users.

  Add up to 5 metrics to a single report.

Custom formulas

Use the metrics coupled with the selected events. Besides the set metrics, you are free to create your own custom formula. Use it, for example, to analyze the relationship of one event to another or even to two events or to find out the number of users who completed the first event but fail to complete the second, or even to calculate the number of users who completed all three events. In the formulas, use the operators described below.

You can also carry out some arithmetic functions, for example, feel free to use the following operators: subtraction "-”, addition "+", division "/", multiplication “*” and numerical coefficients. You can also use parentheses () to specify the order of operations. These functions can be useful if you need to convert the value of a parameter from one currency to another, from minutes to seconds, to express the result as a percentage, or divide the number of events A by the number of users who completed event B.

Formula operators:

count(event) – allows you to calculate the number of performed events, e.g. count(A). Using the arithmetic operators, you can find out the number of started and unfinished training sessions, as well as apply grouping by the training objective:

count(event.param) – the number of events performed with the selected parameter. To specify the parameter, define it after a dot, e.g. count(A.parameter_name).

sum(event.param) – the sum of parameter values. For example, if you pass training duration as part of a ‘training complete’ event, you can calculate the total training duration of all users.

min(event) – the minimum number of events per user. For example, you can find out the minimum number of spins per player.

min(event.param) – the minimum value of event parameter. For example, you can find out the minimum value of coins players send to their friends or receive for completing a quest at someone else’s farm.

max(event) – the maximum number of events per user. Use it, for example, to calculate the maximum number of orders per user.

max(event.param) – the maximum value of event parameter. For example, you can use it to find out the maximum value of the order.

count_distinct(event)* – the number of users who performed the selected event e.g. the number of signed-in users. You can use operators and calculate the share of users who completed transactions out of total users who opened the shop.

count_distinct(event.param)* – the number of unique event parameter values e.g. the number of unique values of areas completed by users from a specific country.

avg(event.param) – the average value of event parameter, e.g. use it to find out the average number of coins acquired from a wheel of fortune or the average combat duration.

avg_per_user(event) – the average number of events per user, e.g. the average number of combats with friends.

avg_per_user(event.param) – the average sum of parameter values per user.

median(event.param)* – the median parameter value, e.g. the median payment amount.

median_per_user(event)* – the median number of events per user, e.g. the median number of items viewed in a catalog.

median_per_user(event.param)* – the median sum of parameter values per user, e.g. the median number of coins spent per user and grouped by level.

percentile(event.param, fraction)* – the percentile of the fraction parameter value (0-1), e.g. the 75th percentile of the total of all purchases - percentile(a.Sum, 0.75).

percentile_per_user(event, fraction)* – the percentile of the number of events among fraction (0-1) users, e.g. percentile_per_user(a, 0.5). The percentile is the value below which a given percentage of values falls. For example, our formula shows the 50th percentile of users who initiated the ‘trading order placed’ event. This means that, on average, 50% of users perform the ‘trading order placed’ three times or less.

percentile_per_user(event.param, fraction)* – the percentile of the parameter value sum among fraction (0-1) users. For example, the ‘money transfer’ event has an ‘amount’ parameter and we introduce the following formula - percentile_per_user(a.amount, 0.8). It means, that as a result, we get an 80th percentile for the ‘amount’ parameter per user.

percent_of_active(event)* – the percentage of users who completed the event out of all active users. For example, you can use it to find out the share of users who participated in a live ops event out of the total users in daily trend.

percent_per_total_count(event) – the percentage of a particular group’s events from the total number of events.

percent_per_total_user(event) – the percentage of users belonging to a particular group who completed the event from the total number of users who completed this event.

least(expr1, expr2, ... expr_n ) – the lowest value among the specified expressions. For example, you can find out the minimum value of the coins that the user gains for performing certain actions (pass them to separate events) by specifying two ‘min’ operators with different events in the formula, and the final formula will find the lowest value: least(min(a.money),min(b.money)).

greatest(expr1, expr2, ... expr_n ) – the highest value among the specified expressions. For example, you used nested formulas to calculate the number of users who participated in live ops events and now you can find out an event with the highest number of participants.

coalesce(expr1, expr2, ... expr_n ) – returns the first non-null expression. If one of the listed formulas returns an empty result, then the final formula will turn in the first non-empty result as the final result. For example, you use several payment systems to complete transactions in your app and each of them has its own commission. You create a formula that describes how you deal with commissions from different systems. A user completes a transaction using one of the systems, the rest of them return empty results and all of this will be taken into account by the final formula, e.g. coalesce(avg(a.discount)*0.8, max(a.discount)*0.6).

round(expr,lenght) – rounding the value of the expression to the specified precision. For example, if you want to find out the ratio of the number of one event to another, then you can round the value to the desired precision: round(count(b)/count(a),1).

* – To speed up report loading, devtodev uses the HyperLogLog approximate calculation algorithm, that allows an error rate of up to 2%.

Metrics that require parameter selection for calculation use all parameter values except "null".

• Aggregation period – the time period over which the data are aggregated (5 min, hour, day, week, month, year). To use a 5 min aggregation report the time frame should be 2 days or less.

• View – chart type (chart, table or transposed table, area chart, and bar chart, stacked area chart, stacked bar chart).

Also, there are powerful Grouping capabilities. You can select “on” in the Group by selector and then select up to 2 grouping levels. It can be user properties like app version, channel, country, language, device, paying capacity, paying status, campaign. You can also group values by custom user properties. For every grouping, you can select Top N filter to include into the report only Top N groups by events count.

And more complex grouping options such as Frequency and Parameter values grouping. Frequency grouping shows you how many users perform your events 1 time, 2 times, 3-5 times, and so on. So you can decide if they used it because it’s just a new button or feature in your app, or because it is a really useful feature. You can follow the frequency of use of any event dynamic and analyze how it’s changed over time or over app versions.

To analyze parameters of your events select “Parameter value” in a group by section then select the parameter and then one of the parameter functions. For numeric parameters it can be:

• None – without additional grouping.

• Distinct values – are unique values of the selected parameter. For every parameter value, you can calculate the total events count or unique users that perform an event with this parameter value (pick one of them in Metric view selector).

• Distribution – is a grouping option that allows you to analyze unlimited numeric parameter values that will be grouped into the bins; for each bin, you can calculate total events count or unique users that perform events within this parameter value bin.

Text parameters are always analyzed by distinct values, so for every text value, you can calculate the metric chosen in the Metric Type list.

To see results, choose the events and click the "View result" or “Refresh” button.

If you'd like to work with data on your own, click the "Export" button and data will be exported as a .csv file. Data in the exported file can be sorted by days.

Also, you can save the report by clicking the “Save” button. It will be available in the “Custom Events” section.

The default report period is the last 7 days; you can change it in the top right corner. You can configure a filter in the report, use an already created filter template or custom segment to get more detailed data. Compare different segments by clicking “Add comparison”. To apply changes tap the “Refresh” button.

Metrics settings

You can change the default name of the metric, for example, Event a. Number of events, to a more convenient title in Metrics settings.

In the pop-up menu you can give the metric a new name and also select how the metric value should be rounded when displayed on the charts. Click the OK button to save and apply the settings.

You can also change the units for the Number report type. Simply type the new name in the Units text box.

When you share the report or add it to the dashboard, these Metrics settings will be saved as well.

SQL Wizard

SQL Wizard allows you to create SQL-like queries and extract any type of data related to your project from the devtodev database.

Click "Add column" to start editing your query, then select columns for your report. You can choose any data about:

• User data (install date, country, app version, etc.)

• Basic events (sessions, payments, in-app purchases, tutorial steps, etc.)

• Custom events (any parameters of any custom event that you've integrated)

After you select columns, the body of the query will be created. All connections (joins) between the tables are set, but you can change them if necessary.

Drag and drop column names to reorder them in the report. If you need to use an aggregate function (AVG, MAX, MIN, etc.), click the down arrow button right to the column name and select a function from the list.

To add conditions to your query, click "Add conditions" button and then add rules (or groups of rules and logical operations between them) by clicking "Add rule" / "Add group" buttons.

Finally, you can set the order of lines in the report by filling the "Order by" condition.

Click "View result" - and the results of your query will be shown in the table below. You can save this query to use it again in future by clicking the "Save report" button.

SQL Editor

Check out this section to learn how to write your own SQL queries.

Share reports with links

After the report is created, you don’t need to save it or add it to a dashboard to share with coworkers. To share, you need to copy a special link that contains all report settings. Click the drop-down menu in the top right corner and choose “Copy report URL”.

You can use this method to share any finished custom report or to set various settings and apply filters to the reports. After a user clicks the link, they will see a report with the selected settings: time period, applied segments, filers, etc. For example, you can share: a funnel built with the Conversion Funnels report that retains all the selected stages and filters, the Game structure report with selected metrics and filters, comparison of selected cohorts in the Cohort analysis report, a filtered list of users in the Users section, a configured User flow report, data on comparing retention rates of two cohorts who executed different events in the Retention by event report, and other valuable reports that allow you to quickly start a discussion of discovered correlations, issues and any other observations.

Note, that if in the report settings you set a date range that is not within the time frame of raw data retention at the time of creating the report and you save the link, then the date range of the report will be changed. The retention period of the links is 1 year. After that the link gets disabled.

Users & Segments section includes:

Users

In the report, you can find information about every user and their activity.

You can filter users by adding filters to some user properties. Click Add filters to set a condition and then View result to see a table with users. In the filter, you can set various user properties and parameters, as well as events and performance windows. For example, filter out premium US users who added two friends in the last month and reached a certain level:

Click the Export button to get a table with users (first 1000 lines) or a specific user profile. Click any row in the table to view user profile details. It consists of basic properties, custom properties (any additional parameters added during integration), and statistics on user actions performed in the app.

Use tabs to toggle between basic and custom properties:

You can also flag a cheater or a tester if needed. You can delete or download user data by clicking the hamburger icon on the user card:

Also, the user card contains the following sections:

• Last user activity. Here you can see user activity days and the events with parameters that they performed in your project during the entire data retention period.

• Filter. Here you can specify the events that you want to display in the list of user activities. The rest of the events will be hidden, but you can expand them to view.

• Highlight. Here you can specify the events that need to be highlighted so that you can quickly find them in the complete list of events.

• Calendar. Here you can select a specific day to see what events the user performed on that particular day.

By clicking Show next/Show previous you can load more recent or older days of user activity.

• Payments. In the payments section, you can see the goods purchased by the user, as well as the transaction ID, date, and cost of the goods sold:

• Subscriptions. Section with the information related to the subscription purchases.

Segments

This page shows an overview of created user 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. The static segment can be created using the reports that contain data on the number of users.

The user list in a dynamic segment is refreshed every time new users perform a certain event or they obtain a property defined in the segment parameters. You can also define the parameters needed for a user to leave the segment and the parameters needed to re-enter the segment.

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.

Creating a Static Segment

You can upload a CSV file with a list of user identifiers manually. To do that, create a Static segment and follow the instructions.

• Conversion funnel report. After building a user experience funnel, you can add the user list to a static segment. The segment will start from the selected step, e.g. users who installed the app, viewed an offer and made a purchase.
• You can use SQL to create a static segment if your query results in a user ID list:
• You have the option to create a static segment using the Paying status prediction report:
• You can use RFM analysis to create a static segment:
• Or you can open the Users section to add the filtered user list to a segment:

Creating a Dynamic Segment

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

1. Name

2. Segment entry condition

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

   You can choose entry conditions for the segment:

   • User card parameters. Define the properties and their values that are necessary for a user to enter the segment. Use AND/OR operators to manage the segment entry conditions with more flexibility. For example, you can select the users who view your ads AND don’t buy anything in the app; an audience that installed version 1 OR version 2 of the app; users acquired through an ad campaign from Facebook AND a certain country, etc.
   • Event conditions. Specify a time frame and events the user has to perform to enter the segment. Here you can also define parameters of the event and/or user properties at the time of the specified event occurrence.

     Use AND/OR operators to add a new condition or a group of conditions for flexible segmentation. Users enter the segment when devtodev receives specified events at the current stage. All events that conform to conditions must occur within no more than 30 days. The order of events specified at this stage is irrelevant.

     For example, you can create a segment of unauthorized users from Brazilia who attempted to complete N levels in 4 days and analyze them later.
3. Segment exit condition. At this stage, you can specify whether or not the user can exit the segment. Open the relevant tab: User can’t leave segment – users will be accumulated in the segment. Entry condition changed. If the user does not fit the entry conditions anymore, they are excluded from the segment. You can also set a condition that will trigger users's exit from the segment. Special exit condition. Here you can specify exit conditions that must be met to exit the dynamic segment: by event conditions or by parameters specified in the user card.

   For example, you want to build a segment of users who viewed special offers and opened in-app sore within 30 days but didn’t make a purchase. Then, in the Segment exit condition tab you can specify Purchase event and then all the users who did make a purchase will exit the segment. If at this stage you set up the segment exit conditions, the next stage will open up.

4. Allow repeated entry. Check the box if you want the users to re-enter the segment in case they conform to conditions listed at stage 2. Click Apply to create a segment with the specified criteria.

Copying a segment

You can also copy and edit an existing dynamic segment. Simply select a segment you would like to edit and cllick on the Copy button that will appear in the upper right corner.

A new segment will be created with the same entry/exit conditions, all you need is to give it a new name.

Limitations

You can not use historical data to create dynamic segments therefore we recommend you create the segments in advance. In case you want to analyze new features, for example, you can create a dynamic segment right after the release so that there is enough time to add users to it before you start analyzing the metrics that may be affected by new features.

The static segment is applied to the historical data for the period up to three months from the segment creation. For example, metrics for the past 90 days in the Basic Metrics report or any other report where you can use segments as a filter.

Expiration date – the date when the segment will be terminated. The Expiration date of the segment is calculated automatically and cannot be changed manually. If the segment is not used in the reports, then the segment will expire in two months. Otherwise, the Expiration date is prolonged. If the segment expires, the user can restore it within one month but before it’s restored, it can’t be used in the reports.

An is a perfect place to see the key metric of your project in 1-2 minutes.

Alert widget on the dashboard shows the most important KPI of the project for the last day:

• Gross (total amount of all payments of the users)

• DAU (Daily Active Users, number of unique users that logged into the project on daily basis)

• New Users (users who launched the application for the first time)

• ARPU (Average Revenue Per User, Gross/DAU)

• Paying users (the number of unique users who pay per day)

• Average session length (Average time spent in the app per user)

• Transactions(the total number of transactions)

• Sticky factor (the regularity of users' entries DAU/MAU)

• Average check (the average transaction amount for all the payments performed yesterday)

• Transactions (how many payments were made in total by your users yesterday)

• ARPPU (Average Revenue Per Paying User, estimated revenue a single paying user generates during a specified revenue)

• User online (the average number of users who were active at the same time during the last day)

• Lifetime (how many days an average user spends in your project according to yesterday's data)

• Sessions (how many times your users launched the app yesterday)

• Paying users (how many users made at least one payment)

• Paying share (how many users made at least one payment yesterday)

Click the arrow buttons on the left and right parts of the widget to switch metrics. The color of the widget indicates whether the metrics are growing or not (e.g. red color means the fall).

Top right widget shows stats of integration process (general completeness of integration in percents and detailed percents for the groups of features).

The rest of the charts show the main indicators of the project for the last 30 days:

• New users

• Gross & ARPU

• Active users per day

• Retention (day 1, day7, day 28)

• Tutorial dynamics (how users pass the tutorial)

• Users activity (distribution by hours and days of the week)

You can dive to the deeper analysis of each indicator by clicking the 🔎 button on related chart.

The bar at the top of the page shows the most important metrics for the current day and their comparison vs previous day.

The text on the buttons (which are on the list of templates) is translated into Arabic, Chinese, Czech, Danish, Dutch, English, Finnish, French, German, Hungarian, Indonesian, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Romanian, Russian, Slovak, Spanish, Swedish, Thai, Turkish, Vietnamese, Indonesian languages. The text is displayed to users individually depending on the locale of a device. In case the user uses another language, texts of buttons will be shown in the default language.

Tuning section includes:

• : , ,

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

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.

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.

Alerts

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. The metrics you can choose from are New users, Gross, Day 7 retention, ARPU, Numbers custom events, Average number of custom events per user, and others.

Conditions can be:

• comparison with confidence interval (the previous day’s value will be compared to the confidence interval). You indicate the sensitivity parameter: high, medium, or low. This choice affects whether the confidence interval widens or narrows.

• comparison with threshold (the previous day’s value will be compared to the specific value). You provide one or two threshold values for the metric: Upper threshold value and Lower threshold value.

• сomparison with the previous day. You enter the percentage value by which the metric should change to trigger an alert, compare the value of the past day with the day before.

• сomparison with the same day last week. You enter the percentage value by which the metric should change to trigger an alert, compare it with the same day of the last week (for example, Monday with Monday).

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

Custom events configurations

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.

User property

In this section, you can ‘block’ certain user properties to stop collecting and storing their data. You can find this functionality in the “Tuning” section of the top menu, under the “Integration” subsection.

Please note that only space administrators or a space owner can edit custom properties. Other roles have only access for viewing. At the top of the report, you can see the overview of user properties:

• Active custom user properties - properties we are currently tracking and recording. These properties are available for all reports.

• Properties blocked by customer or system - properties that were implemented in the code but were blocked by the space administrator or space owner. We are not collecting or recording data for these properties at the moment. You won't see these properties when building reports.

There is a limit of 30 unique property names that we can track simultaneously. If you reach the limit, you can block those active custom properties that are currently irrelevant.

To block or unblock multiple properties, you can mark the checkboxes and then click on the lock icon.

We'll start collecting data for this property only after it is unblocked.

Please note that you can unblock a property from the blocked list if you have fewer than 30 active custom properties.

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:

Raw Export

The Raw Export section allows you to build custom reports and download them as csv. files. This may be needed if you want to work with data on your own and build more complex and customized reports.

To create a new report, click the "Add a new report" button above the table and follow the instructions.

• Choose events and data

• Select time frame for the report

• Name your report

To download an existing report, find it in the table and click "Download" in the right column of the table. The report will be downloaded to your computer.

You can download the reports with only "Ready" status. If a report is in a "In progress" status, wait until it reaches 100%. If the report is in an "Empty report" status, it means that there is no relevant data to be exported.

After the report is created, you can see its settings by clicking the button in the “Settings” column.

List of available events

Cohort export

Prepare a cohort for export

Use the following reports to export audiences:

• ‘Segments’: select one dynamic or some static segments, and click ‘Export cohort to Ad network’ in the top right corner.

• ‘SQL’: get a list of user IDs as a result of your query. Click the sandwich icon in the top right corner and select ‘Export cohort to Ad network’ to export the cohort to your ad account.

• ‘Users’: filter users by parameters, properties, completed events, then click the sandwich icon in the top right corner and select ‘Export cohort to Ad network’.

• ‘Paying status prediction’ report: select a segment with a certain purchase probability and click the Export cohort button.

• ‘RFM’ report: select the desired segment, e.g. Champions - the users who pay often and a lot, and click the Export cohort button.

• ’Funnels’ report: build a funnel and export the audience who completed specified steps by clicking ‘Cohort export’ in the dropdown menu.

Exporting a cohort to an ad account

1) After you have prepared an audience to export and clicked ‘Export cohort to Ad network’ in the new window, you need to choose whether you want to add new users to an existing audience in your ad account or build a new one. To create a new cohort, enter the name to be displayed in the ad network account.

2) Next, you need to name the cohort to be exported. This name is displayed in devtodev in the list of all exported cohorts. This is needed for history displaying and cohort management.

If your cohort was created from a dynamic segment, then on the next step, you will need to select the type of cohort synchronization: daily (the audience gets exported every 24 hours) or one-time. If you choose daily synchronization, then uses will accumulate in the cohort and the users who left the dynamic segment will not be removed from the cohort.

3) Click ‘Apply’ to finish audience export. Audience creation can take up to 12 hours to fully complete. You can find the cohort synchronization status in the Exported cohorts section.

The ‘Cohort export’ section contains information about exported cohorts - their names, ad networks where the cohort was exported to, date of the last synchronization, audience size, cohort state: synchronization, was it exported or an error was returned, audience type: one-time export or daily export, as well as buttons to stop syncing daily cohorts.

Filter by app version in the Retention report

You have two filter options:

• By the installation version (first app version)

• By the current version (current app version)

When applying the filter, you select the users with a certain app version while ignoring information about returns/sessions. It means that you use the filter to build a cohort and then calculate retention rates regardless of the current app version.

Let’s say a user installed the 1.2 version of the application. If we apply the “first app version = 1.2” filter then the user will enter our cohort and we can calculate his retention rate. If the user updates the app to version 1.4 then he will still remain in the calculation because it is based on the first app version only. If after that we apply the “current app version = 1.4” filter then our user will enter the new cohort because the first app version is in this case irrelevant and the cohort is made of the users currently using the 1.4 version. Depending on the selected retention type, the retention rate of this user will be calculated from day 0 or 1 regardless of the app version he was using at that time.

Basic Metric Filters

For most metrics, filters are applied to the data received at the time of the event. For some other metrics (e.g. retention rate, installs), however, information is pulled from the user card.

Subscription bundle - the name of the subscription active at the time of the event (you can compare the behavior of users who purchased a subscription to one part of the functionality with those who purchased a subscription to another part). Subscription state - the current state of the user's subscription, which can have the following values:

• None - the user does not have and never had a subscription

• Unsubscribed: - Expired - the user's active subscription has expired, and they didn’t renew it during the Grace period. - Refunded - the user has refunded their subscription.

• Trial - the user is using a trial period of any subscription Subscribed New - the user purchased a subscription for the first time.

• Renewed - the user renewed their subscription (using the auto-renew option or manually during the Grace period)

• Reactivated - the user purchased a subscription after being previously marked as Expired or Refunded.

• Upgraded - the user purchased a more expensive subscription.

• Downgraded - the user purchased a cheaper subscription.

Subscription filters are built on the basis of data received from SDK and app stores. Integration with stores allows you to receive information about subscription purchases even if the user hasn’t opened the app.

Filters by user

Detailed stats

Type - filter users by traffic type, e.g. you can use data from the tracker to select users coming from a paid source (External ad) or from External organic traffic source, or from Cross-promo ad. Source - filter data by the source of user data, e.g. data retrieved using the Custom postback API or a specific ad network (Tenjin, Branch.io, etc). Publisher - filter users by traffic source. The source is retrieved from the ‘utm_source’ parameter or an attribution tracker. Sub publisher, Sub placements - filer data by traffic type. The type that is retrieved from the ‘utm_medium’ parameter or an attribution tracker. Campaigns - filter data by campaigns. The data on campaigns is retrieved from the ‘utm_campaign’ parameter or an attribution tracker. Ad set - filter users by ads. Sub Ad groups - filter users by ad group. Sub sites - filter data by ad placement. Sub keywords - filer user data by keywords. The keywords are retrieved from the ‘utm_term’ UTM parameter.

Reports in are designed specially for game projects and allow to analyze game economies. You can find here information about in-game purchases, levels, locations, in-game currencies balances distributed by levels, etc

In-Game Analysis reports:

In-Game Analysis Dashboard

This dashboard presents an overview of data related to in-app purchases. All data is shown for a specified period of time (last 30 days are selected by default).

The first widget shows the dynamics of main in-game currencies for the first 20 levels.

Widgets “Top purchases” and “Top 3 purchases by days” show top in-app virtual purchases. “Top purchases” show purchases ordered descending by the amount of bought items. “Top 3 purchases by days” widget shows daily dynamics of top 3 items.

Widget “Top levels by revenue” shows levels stats:

• Gross on each level

• Number of users that completed a particular level

• Number and % of users remaining on a level

• Number of paying users and paying share

• ARPU

Click a 🔎 to open a more detailed report.

Economy Balance

The Economy Balance report shows the amount of in-game currency earned, bought, spent and kept in the account on each level or time period.

In this report, you can find the following information:

• Currency balance by level shows how much virtual currency is bought, earned, spent and kept in accounts on each level.

• The same currency balance with aggregation by day, week, or month. Then you can match it to various in-game events or promotions.

• Currency sources

Let’s take a look at how reports are created.

To calculate the Currency Balance metric with aggregation by level, we use the LevelUp event. It also passes information about current level and amount of currency held by a user.

The Currency Balance metric aggregated by time periods (day, week, month) shows how currency was spent and earned during the specified calendar periods. This feature is available for SDK version 2.0 and above.

To build a report, we use the currency accrual event that can track currency gains (earned, bought) and that is sent to the SDK every 5 minutes. The currency balance is tracked by the current balance event that is sent once a day. Information about currency spent (spent) is taken from the Virtual Currency Payment event.

You can display data in absolute and relative values. If you select Relative, then the metrics are calculated in the following manner:

• Earned = Earned / (Earned + Bought)

• Bought = Bought / (Earned + Bought)

• Spent = - Spent / (Earned + Bought)

• The value of Balance doesn’t change, so calculation is not applicable

You can also display Total - the total amount of currency, or Average - the average amount of currency per user (e.g. total amount spent divided by the number of users who spent it).

The Source of earn metric is also only available for SDK version 2.0 and above. It shows how users gain currency (earned). The Source parameter is passed with the currency accrual event.

The LevelUp event is used for grouping by levels.

If you apply the Relative unit, you will get information on the share of a specified source relative to all other sources.

Default report period is the last 30 days, you can change it in the top right corner. You can configure a filter in the report, use an already created filter template or custom segment to get more detailed data. Press “Refresh” button to apply the changes.

Virtual Goods & Purchases

The Virtual Goods & Purchases report shows the detailed overview of how users spend in-game currency.

There are 4 pages available:

1. Top purchases

2. Structure of purchases

3. Dynamics of purchases

4. ABC/XYZ-analysis

To build the report, click the "View result” button. If you would like to build the report after changing settings, use the “Refresh” button.

It is possible to set the range of levels you are most interested in for each page.

Moreover, you can configure a filter in the reports, use already created filter template or custom segment to get more detailed data.

Top Purchases

The Top purchases page shows top 5 in-game items based on the number of purchases that can be grouped by levels or days. You can check this statistics for all in-game currencies. The default period for this report is 5 weeks.

Purchases structure

The Purchases structure tab contains information about the items sold in the selected in-game currency or real currency. The report can help you analyze the structure of a player's basket and how it changes depending on the level they are on now. Use the report to answer the following questions:

• How much in-game currency was spent and the share of these spendings in total spend of this particular currency

• What is the average price of this item on all levels/dates?

• What is the minimum level at which this item was purchased?

The resulting table can include the following metrics:

• The number of purchases

• Total currency spent

• The number of items purchased on each level (available if ‘Metrics by level’ = pcs)

• The amount of currency spent on each level (available if ‘Metrics by level’ = Currency spent)

• Min level of purchase, Avg. price, % off all currency spent (available if ‘Metrics by level’ = No)

The default period for this report is last 30 days.

The report includes several controls. From the ‘Currency’ drop-down list, choose the in-game or real-world currency (e.g. to view currency spend distribution by levels or find the lowest level where users buy a starter pack).

If you need data by level, configure the report type using the ‘Metric by level’ drop-down list. It has the following options:

• No. In this case, the resulting table will not contain any data by levels. It will only include the following information: Pcs, currency spent, percentage of the total currency spent, average price, and the minimum level of item purchasing.

• Pcs. The report will include the total number of purchased items and the number purchased items by level.

• Currency spent. The resulting table will contain the total amount of spent currency and the amount of currency spent on each level.

You can also specify the level range here.

Use the section below to choose the display mode of the purchased items: group the item groups (it may come in handy if you have plenty of items or you want to look at the bigger picture) or group the items. Use the filters to the right to select the items for analysis.

If you want to analyze the change in demand for specific items or offers by levels, open the Purchases dynamics tap.

Purchases dynamics

The Purchases dynamics report contains information about changes in sales of selected items or purchases in real-world money. It can display sales data over time by dates or by levels.

It has several controls for report configuration.

First, specify the mode of data grouping: by days or levels.

Then, select the desired metric from the drop-down list:

• Items purchased to view the total number of items sold on the level or for a day.

• Items purchased per buyer to view the number of items purchased on a specific level divided by the number of buyers.

• % of buyers among active users to view the number of buyers divided by DAU.

• Number of buyers

After that, select the chart visual: Chart or Bar chart. Also, you can specify the level range.

In the section below, select the items or groups that you want to see over time:

• Virtual items

• Virtual item categories

• Real payments

ABC/XYZ-analysis

ABC/XYZ-analysis divides the set of items purchased for a chosen currency into 9 segments based on the amount of revenue that is generated by a particular item and stability of demand.

Those categories are:

• High contribution to the revenue structure - Goods that make up 80% of all purchases

• Average contribution to the revenue structure - Goods in 80%, but out of 90% of all purchases

• Low contribution to the revenue structure - Goods out of 90% of all purchases

• Stable demand - Demand fluctuations up to 60%

• Moderately stable demand - Demand fluctuations from 20% to 60%

• Unstable demand - Demand fluctuations more than 60%

The default period for this report is the last 30 days.

Game Structure

This report shows the distribution of users among players’ levels (of experience), locations and cumulative metrics.

There are three pages available:

1. Player levels

2. Cumulative metrics by level

3. Locations

On each page you can choose up to 3 metrics to track and select a time period. On the “Player levels” page the last activity date is used, on the “Locations” page - calendar date, on the “Cumulative metrics by level” page - install date.

To build the report, click the “View result” button. If you would like to build the report after changing settings, use the “Refresh” button. Moreover, you can configure a filter in the reports, use already created filter template or custom segment to get more detailed data.

Player levels

On the Player levels page you can track user related metrics grouped by levels (of players’ experience):

• The number of users that completed or remain on a particular level in absolute and percentage values

• The amount of generated revenue

Cumulative metrics by level

Cumulative metrics by level - this report shows cumulative metrics in the context of game levels (player experience), using the report you can predict what income and at what level the user will bring.

The report contains the following metrics:

• Cumulative ARPU by level - cumulative income of the average user at each level

• Level ARPU - average income from one active user at each level

• Level conversion - conversion to the first payment by level, the number of users who made a payment on a certain level divided by the number of applications installed.

• Cumulative level conversion - cumulative conversion to the first payment by level

• Users reached the level - the number of users at the game level

You can evaluate how much a player will bring to a project to a particular level, compare the value of game levels, determine which levels are most profitable, evaluate the change in accumulative metrics after processing a game level.

Cumulative ARPU by level allows you to compare cohorts, for example, when you made any changes to the product. To find out if users began to pay more or less you can compare the dynamics of cumulative ARPU for cohorts that installed the application before or after changes.

Cumulative conversion by level will also help to analyze the changes in the product. For example, earlier, 1% of users was converted to a purchase at the 20th level, but after a new release 1.5% of users began to be converted. You can’t notice such changes on the regular conversion chart by level, because it could be redistributed: before users paid more at the 3rd and 8th levels, now - at the 5th and 6th levels. Thanks to the levels at which the changes were made, cumulative conversion will let you know if more users were converted to the purchase than before the changes.

It will also be useful to compare the behavior of cumulative conversion and cumulative ARPU by level. For example, cumulative conversion has increased, and cumulative ARPU to the 20th level has become lower than before the changes, this may indicate that there are more paying users but they pay less.

It is important to note that for the payment event at the level we take exactly the level at which the payment was made (not the one at which the player is currently located).

Locations

The Locations report shows statistics about quests, game levels, etc. Therefore, here you can find both user related and location related metrics:

• Location complexity (the rate of successful attempts)

• The number of successful/unsuccessful attempts needed to pass the location

• The amount of users’ earnings and spendings for real and virtual currencies

There are two types of metrics aggregation – total sum and average.

This report can be saved to a custom dashboard as a widget. Click on Save to dashboard button and select the dashboard where you would like to add the report.

Here are the articles in this section:

allows you to create and manage push notifications campaigns.

If push notifications are not connected

To connect the push notifications service to the app you need to:

1. Integrate devtodev SDK and activate push notifications during integration

2. Fill in the required information in the push notifications panel in the Integration section of the application settings

Detailed information about the process of receiving necessary data and activation of push notifications for each platform can be found in the devtodev SDK integration manual in the ‘Help’ section.

Current campaigns

Here is the list of created push notification campaigns. You can filter them by status. Select one of the campaigns to view a more detailed report about it.

The report shows notification settings, such as campaign and audience info, statistics about campaign results, where:

• Audience - the number of users who fit selected conditions and whose push tokens are known

• Delivered - the number of delivered push notifications, which haven’t been declined by the push server. The most common reasons for rejection are that app is uninstalled or the token is not correct

• Failures - the number of rejected push notifications (the difference between the number of audience and delivered push notifications)

• Impressions - the number of impressions. This metric exists only for Android apps. The data come to us if the user opens the app or if it was opened at the time of receiving the push notification.

• Clicks - the amount of clicks on a notification

Creating a new campaign

To create a new campaign click the Add new campaign button in the top right corner of a Campaign tab and follow the steps:

1. Campaign name

2. Campaign type

3. Target audience or Triggering conditions

4. Push-notification content

5. Push testing

6. Settings for campaign analysis

7. Schedule

8. Confirmation

Name your push campaign

Campaign types

Select the type of the campaign. There are two types of campaign: Simple campaign and Automated campaign

• Choose Simple campaign to send a message to a specific segment of users or all users. You can send the push once or schedule it to a specific time, let’s say, every Thursday at 12:00. You can use it to notify all users about a new event in the game, or notify a specific segment about a new promotion available, etc.

• Choose Automated campaign (Trigger campaign) if you want to send more personal push notifications or when you want to regularly remind users about the application, e.g. when a user has taken a certain action or has not opened the application for a while.

Target audience / Triggering conditions

When creating a Simple campaign, at the Target audience step you can select the delivery target audience. You can include all the users whose push tokens were received by devtodev system or target a specific audience by using filter conditions.

When creating a trigger campaign, at the Triggering conditions step, you must specify one of the triggers that will launch the campaign:

• First open: specify the number of days/hours/minutes that have to pass after the application was first opened. For example, you can remind a new user about a time-limited starter pack 2 days after the app was first opened.

You can filter users by country of origin, language, device, application version, OS version:

• Inactivity: specify the number of days since the user's last activity. You can also set specific filters to select users you want to message, for example, you can select the users who used to pay in the application, but were not active for two weeks.
• Event: specify one or several events that the user must perform in order to receive a push notification. You can specify the number of days/hours/minutes that should elapse after the conditions of the trigger are met, or you can select Cancellation events. Cancellation events is a condition that prevents notifications from being dispatched if the condition is met within a specified delay period. For example, if you want to re-engage users who abandoned the cart, then as a trigger you can indicate opening a store and adding a specific product to the cart as a trigger and then select the product purchase event as a Cancellation event.

You can send push notification to every user who allows it or choose a particular segment.

Push-notification content

As for the customization of the content, you can add action, button and attachment (image, music or video). If you need to send a notification in different languages, you can click the Add button and customise each of them separately.

You can specify a text message for the default language, and also add other languages with different messages. When sending a notification, the user will receive a push message in the language specified in the user profile. If the language in the user profile is not among the added languages, the user will receive a notification in the default language.

Moreover, you can make the notification invisible.

Settings for campaign analysis

If you want to get a more detailed analysis on your push campaign, you can set the size of the control group. The control group consists of users who meet the conditions of the campaign, but do not receive push notifications. The control group is useful if you want to know the effectiveness of notifications or to compare the metric values of users who received them and those who didn’t.

For the push campaign you can also set a desired action that the user needs to take after receiving the notification. For example, if a push notification informs the user about new items in the store, then the desired action is to open the store screen; if the push informs the user about bargain price offers, then the desired action will be the purchase of the offer, etc.

Setting the target event will allow you to compare the conversion rate of the control group (users who do not receive the notification) with the conversion rate of the audience that receives the notification, it also allows you to compare the conversion rate of the users who opened the message and performed the target action with those who did not open it but still performed the target action.

Schedule

The next step is to schedule a campaign. Simple campaign. Here you can choose between two options - Send ASAP or Schedule sending time.

• “Send ASAP” - the push notification will be sent once you complete the campaign creation process.

• “Schedule sending time” - set specific parameters for sending the notification. For example, you can choose up to 30 calendar days when you would like to send the same push notification or you can select just one day if it is not a recurring message. Then you can select a delivery time and timezone: the push notification can be sent simultaneously to all users or according to the user's time zone.

A trigger campaign’s Schedule step offers the following settings:

• Campaign activity where you need to specify the start and finish date of the campaign. To start the campaign you can choose between two options - Send ASAP or Schedule sending time. If you choose “Send ASAP” then the push notification will be sent once you complete the campaign creation process. As a finish date, you can choose between two options - Never or Schedule sending time.

• You can tick the checkbox if you want to prohibit sending a delayed message after the campaign has expired.

  In the Delivery time window, select the time interval for the delivery of your message. Specify whether or not the notification should be sent at the next allowed time window if the trigger condition is met outside the specified period.

Copying an existing campaign

You easily can create a copy of an existing push campaign. Open the campaign that you would like to duplicate and click on the Copy icon in the upper right corner.

This will copy all of the settings of this campaign, you just need to give it a new name and save.

Push notification report (Simple campaign)

The Advanced report is made up of several widgets:

• Campaign info - general information about the sent message: title, alert, action, sound, audience filter and etc.

• Campaign statistics

• Monetization effect

• User structure

• User return

• Conversion funnel

Based on the widget data you can divide the audience of the campaign into the following segments:

• Number of users in the control group, if you specified it when configuring the campaign

• Number of users who received the push notification but did not open it

• Number of users who received and opened the push notification

These segments will allow you to evaluate the effectiveness of your message. All metrics for evaluating the effectiveness of notifications are measured 7 days before the start of the advertising campaign and 7 days after the receipt of the notification.

Campaign statistics. Audience is the number of users who entered the segment when creating the campaign. The table contains a Revenue value for each segment of the audience, seven days before the start of the campaign and seven days after the start to assess the impact of push notifications on user behavior. Conversion to action shows the percentage of users that have executed the desired action. Monetization effect. You can assess how the campaign has affected metrics such as ARPPU, ARPU, Avg. ARPDAU, Conversion to 1st payment, Conversion to 2nd payment. Based on the metric values you can also build a graph where the red line marks the start of the campaign. User structure. You can analyze the following metrics: Users, Average Session Length, ARPPU, ARPU, Revenue, Group audiences by Country, Paying capacity, days from Install. User return. The widget shows the number of users by their inactivity periods in the application and the number of re-engaged users (within 7 days after the campaign). Conversion Funnels. If you specified the desired action while configuring the campaign, the funnel will consist of three steps.The first step of the funnel contains the event about the campaign start, the second step is opening the push notification event. The third step is the event you specified when configuring your advertising campaign. If you want to add another step or change the current steps, you can go to the Funnel report.

Push notification report (Automated campaign)

Statistics

In the trigger campaign report you can find information about the campaign settings, its status, widgets with statistics. You can also cancel sending push notifications for this campaign or restart it:

Above the report, you can specify a date range for which you want to display data. A trigger push campaign report has three tabs:

• Base report - general information about the campaign.

• Advanced report - information about the number of users who re-engage after receiving notifications, information about the effectiveness of push notifications and conversion funnels if you specified a conversion event when setting up the campaign.

• Efficiency report - on the tab you can see how the campaign affected the monetization metrics.

Each tab of the tabs contains general information about the campaign:

Average number of campaign notifications per user Average number of all push notifications received by campaign audience. This information can be useful in determining what proportion of notifications a user receives during a given campaign. For example, during this campaign, the user only receives push notifications, in which case you can diversify notifications for this audience. Average time between push notification campaigns. This metric helps you measure how often users receive notifications from a given campaign. Number of delivered push notifications that were not opened Number of errors

In the “Number of days for analysis after the push notification has been sent out” drop-down list below, you can specify your push notification’s period of validity from 1 to 7 days. All metrics for evaluating notification effectiveness will be calculated depending on the specified period. For example, if you chose a seven-day period, then in order to evaluate the effectiveness of the campaign, the metrics will be calculated for 7 days before the start of the ad campaign and for 7 days after the push notification has been received. A similar timeframe will be set for the marketing funnel stages.

In the next "Display statistics for the * push notification" drop-down list, you can select the number of the notification “wave” for which you want to view statistics.

Base report tab

The widget displays the number of sent, opened push notifications, and the conversion from sending to opening. In the controls, you can choose the push notification on which you want to view statistics, for example, on the second or on all at once. You can also choose the count parameter: the number of push notifications or the number of unique users who received these messages.

Advanced report tab

User return. If the “Inactivity” trigger was added when setting up the campaign, this report will contain the Return widget. The widget displays the number of users with a breakdown by the time since their last engagement with the application and the number of users re-engaged due to the campaign. This widget allows you to estimate the optimum time for re-engaging lapsed users. Conversion Funnels. This report contains a funnel widget if you specified the desired action when setting up the campaign. The funnel shows the sequence of user actions and allows you to assess at what stage users “drop out” and do not reach the desired action point. The funnel has three stages. The first stage of the funnel contains the event about the sending of the campaign, the second stage is the push notification open event, and the third stage is the event that you specified when setting up the ad campaign. In case you want to add another stage or change the current stages, you can open the Funnel report The effectiveness of sending push notifications. The widget contains information on the number of push notifications sent in the first wave, the number of notifications opened, the number of push notifications sent and opened in the second wave, and so on. Using the widget, you can assess the effectiveness of the initial and subsequent notifications sent during this campaign. For example, it is possible that users open the first push notification, but don’t open the subsequent ones. In this case, sending a reminder that does not re-engage the player is useless. It might be worth changing the content, the call to action in subsequent messages first.

Efficiency report tab

Monetization effect. You can evaluate the impact of the campaign on such metrics as ARPPU, ARPU, Avg. ARPDAU, Conversion to 1st payment, Conversion to 2nd payment. You can also put these metrics into graph form and display them below the table (the red line stands for the start of the campaign). User structure. You can analyze the following metrics: users, Average Session Length, ARPPU, ARPU, Revenue, segment the audience by Country, Paying capacity, Days from install.

Errors

In some cases, you can encounter errors that occurred while sending push-notifications to the specified campaign in the Status column.

Below you can find examples of possible errors and their meaning.

Android

IOS

Windows