Here are the articles in this section:

Reports

The Reports section allows you to build custom reports for several projects at the same time.

To build a report click the "Add new report" button.

You can choose a report template with set metrics or build a custom report:

While building a new report, you can define the necessary metrics. You can select up to 10 metrics for one report.

Then select the applications you want to have in the report. You can set an unlimited number of applications. But beware: sometimes the reports on too many applications are really hard to read and understand.

You can group metrics by different parameters:

• applications. The data will be grouped by application. If you need to compare the performance of different applications, use this grouping method. Recommendation: use basic metrics such as ARPU, retention, lifetime value, or total revenue;

• platforms. If you have the applications working for different platforms and you need to compare platform performance, use this grouping. Recommendation: use monetization metrics such as ARPU, ARPPU, and Gross;

• app versions;

• channels. The data is grouped by incoming traffic channels, so the report is useful for finding a favorable traffic structure. Recommendation: use traffic metrics such as ARPU, ARPPU, and paying conversion;

• countries. If you need to compare one country with another, use this option. Recommendation: usually the difference between countries can be found in monetization metrics such as Average Check, ARPU, and ARPPU;

• languages. If you need to compare either different markets or different localizations of your product, use this grouping method. Recommendation: use metrics such as ARPU and retention;

• devices, paying capacity, etc.

Finally, to set a filter on the application set click the "Filters" button. You can add one or more filters to the application set using for the report.

Applications can be filtered by install date, ad network, paying status, devices, etc.

In the report menu, you can choose one or some of the following actions:

• Reset settings - for fast reset of the selected filters, segments, apps, and other settings applied to the report.

• Save report - save the report and get fast access to all the saved reports. You can find the reports in the “Reports” list

• Share the report with teammates - you can also share the report with your colleagues.

• Share the report in a Slack channel

• Save to dashboard - save as a widget for a dashboard:

With Basic Metrics, you can check the metrics of all of your projects on one screen, see their individual and aggregated metrics, group metrics, and audiences by custom characteristics. Seeing the metrics of your apps in one place helps you quickly check the status of all your projects and make informed decisions later on. For example, with Basic Metrics you can compare the financial metrics of your projects to find which of the games brings more money to the studio and therefore invest more resources into its development. Also, if you compare projects’ behavior metrics and ARPPU of the paying users, you’ll be able to see which of the mechanics are more successful and use them when developing your other games. Using devtodev’s updated Basic Metrics, you can compare the revenue of your projects by country, and choose the best locations for each project. Knowing that, you can work on their positioning in their most profitable markets.

Filter your saved reports

You can filter out reports by type, e.g. display only saved Conversion funnels or reports built using SQL. To do that, select the desired type from the ‘Report type’ drop-down list:

Use filter by tags to filter saved reports not only by type but also by their content. For example, you can split reports by the topic, by country, by goals of their creation:

To add one or more tags to a report, select the report by checking the box on the left of the report name, and click the # (Add tag to report) above the list of reports.

Then add one or more tags and click ‘Ok’ to save the changes:

To filter the results, open the «Tag filter» drop-down list and select one or more tags that you want to filter on.

If you select several tags, you will see reports that have ALL the selected tags. To delete a tag for one or more reports, select them by checking the box and click the # button. In the window that opens, click the cross mark next to the tags you want to delete and save the changes:

Custom dashboards

Dashboards allow you to see data on several projects in one place. It gives you an opportunity to react to changes in user behavior decisively and saves time because you won’t need to open all the reports for analysis.

To the dashboard, you can add several custom reports that will be presented as one page. To grasp the whole picture, you can also use one widget to analyze different platforms’ project metrics. When you need to, for example, routinely track monetization metrics, you can create a dashboard with monetization metrics for the selected apps.

You can add to the dashboard a widget:

• a diagram that shows Gross performance per app.

• a diagram that shows an app-specific revenue structure.

• a table with more detailed information for the past month: number of new users, active users, revenue, conversion to paying user, ARPU, ARPPU, and other app-specific metrics.

If you want to build a report that shows the performance of apps’ audience acquisition channels, you can add some widgets to one dashboard and they will show the current traffic status. For example:

• a table for analyzing the most important metrics by traffic sources: new users, gross, paying conversion, ARPU, Day 1 retention, day 7 retention, and so on.

• a diagram that shows new user acquisition performance by app.

• and other widgets that help you analyze channel performance.

You can find all the necessary information on one page. You can respond to trends fast and improve your ad strategies, reassess your budget, and so on.

Creating a dashboard

To start working with dashboards, select the "Dashboard" section on the top of the form. To create a new dashboard, enter its name and click “Save”:

Once you name it, you'll be able to fill it out with your report widgets and start monitoring metrics. You can always rename your dashboard later.

Add widgets to a dashboard

After you click the “Add widget” button, you will be redirected to the Basic Metrics for building a report. After you complete it, you can add it as a widget to the dashboard. Also, you can create widgets from any saved reports in the Basic Metrics.

To do it, you need to:

1. Name the widget.

2. Choose the dashboard where you want to save the widget to.

3. Set the report date range: fixed, moving.

If a preset time frame is set (i.e. last 7 days) then this time frame will be used further as to the actual date.

After that your widget appears on the dashboard where you can quickly analyze the necessary metrics for the selected apps:

Text widget that you can use to add comments to dashboards and these comments will be visible to your coworkers. You can highlight the main points, key analysis takeaways, remind your colleagues that they can open the report from any widget, and go on with the research by changing the report, its rate range, applying filters to the data, etc. You can add links or other data sources to the text, for example, a link to a storyboard of screens or a screenshot of features in question.

To add a text widget to a dashboard, click ‘Add widget’ in the drop-down menu and then select the ‘Text widget (for notes and descriptions)’ type.

Name your text widget and then add notes or takeaways to the text body while formatting it as you like (alignment, styles, colors, bulleted lists, etc.)

A total of 20 widgets per dashboard are available, of which up to 10 can be widgets based on SQL queries. Additionaly, 20 text widgets allow users to freely include information in text format. For example, you can customize your dashboard by adding: 8 SQL widgets, 12 widgets from other reports (Basic metrics report, Custom events, Retention report, Funnels), and a few more text widgets to explain graphs or describe conclusions.

Widget customization

By clicking the widget menu, you can open the report in the Basic Metrics and edit it, add an additional filter, group, apply a segment, select additional metrics or apps for a more detailed analysis.

You also have an opportunity to change the widget’s name and description. Hover over the title to change it. A pencil icon will appear next to the title, click it to edit. The widget description may be useful, for example, if you give your coworkers access to the dashboard. You can add comments, conclusions, and other useful information to your widgets.

To read the widget’s description, you need to choose “i” icon to the right of the widget’s name.

Table widget settings

Sometimes the text in tables may be difficult to read. You can use Table settings to adjust the column width and text content. Only users with Editor access can apply these settings.

Autofit column width option sets the best column width automatically based on the text length in the header and column values. If this option is not selected, you can change the column width manually.

Wrap text option wraps text in the heading and table rows. The text is wraped up to 3 lines, however, if it is too long, the text will be cut.

You can use both options simultaneously. These settings are saved on the dashboard for all users.

Dashboard management

If you want to switch between dashboards, click the drop-down menu near the dashboard’s name.

There are two types of access to the dashboards: for view and for edit. The access level of a user (owner, viever, editor) can be found next to the dashboard name.

The user who gained permission to edit, can:

• Edit created widgets (change report settings, rename, switch widgets, add/edit the description of the widget).

• Add and delete widgets (also, by using the ‘Move to another dashboard’ option on another widget).

• Grant access to view the dashboard to other team members.

The user who gained permission to edit, CAN NOT:

• Delete the dashboard.

• Give edit permission to another team member. Only the dashboard’s owner can grant permission to edit.

• Remove the access that is not provided by them.

You can also use the menu to save the selected widget to your dashboard:

To change the order of widgets, simply drag any widget to your desired position, via the icon at the top right of the report.

The icon in the lower right of the report is used to resize the widgets.

Adding comments to a dashboard

Add a comment to a dashboard if you want to discuss widget data with your colleagues, ask a question or share your conclusions.

To do this, click the ‘Comments’ icon to the right of the dashboard’s name or next to the widget’s name if you want to comment on a specific widget.

To see all comments, click ‘Comments’ next to the Refresh button:

Mentions of colleagues To mention a colleague, type the @ symbol followed by the user name. Choose one of the options. If you’ve mentioned a user in a comment, they will receive a notification via email and an on-site (bell) notification.

If you’ve mentioned a user who does not have access to the dashboard, then they will be granted access to it and receive an email notification about the mention.

Edit or delete comments You can edit or delete your comments. Open the drop-down list (the three dots menu) next to the comment and select the action you want to perform.

When your problem is resolved, you can close it by clicking the check mark or open the three dots menu and select ‘Close thread’.

Conditions with dates

1. To set the difference between two dates, it is better to use the following expression: eventtime - created <= interval ‘10 min’ (instead of eventtime - created <= 600000)

2. To set a relative date, instead of created <= to_timestamp('2020-11-01 12:59:59', 'YYYY-MM-DD HH24:MI:SS') it is better to use created < date ‘2020-11-02’ or created <= timestamp ‘2020-11-01 12:59:59’ if you need to add the exact time.

3. To include a specific date to the query result (for example 30th of November 2020) you can apply the following condition: created < date '2020-12-01' or created <= timestamp '2020-11-30 23:59:59' The first option is preferable.

Countries

The country names are stored in two-letter code form, such as ‘CN’, ‘FR’, ‘GB’, etc.Therefore, instead of the full country name (‘China’) you can use a code ('CN') or use the countries dictionary - and p.country <> ANY(select code from countries where name = 'China')

DAU (Daily active users)

Active user is a user who generates any event (basic, custom, Start session event) via SDK or API over a certain period of time, for example, a day for DAU. You can use a more convenient table with users’ activity to calculate DAU: users get added only once per day if they are active.

select eventdate, count(devtodevid)
from p103198.dau
where eventdate >= current_date - interval '1 month'
group by 1
order by 1 asc

It corresponds to the DAU metric in the Basic Metrics report. Users marked as cheater or tester are not included in this table.

User segments:

To see the segments the user belongs to:

SELECT  devtodevid, segmentvalues
FROM p102968.users
WHERE segmentvalues is not null 

To filter users and select those who belong to the 'test_segment' segment:

SELECT  devtodevid
FROM p102968.users
WHERE segmentvalues->'test_segment' is true 
or segmentvalues->'other_segment' is not true

To filter users and select those who belong to the specific A/B test group:

select devtodevid, abtestvalues
from p105424.users u
where u.lasttime >= current_date - interval '1 year' 
and u.abtestvalues->'test_name.A' is not null

Currency conversion

When we receive payment information, we convert it into United States Dollar (USD) using the latest exchange rate. Thus, devtodev stores information about payment amounts in USD.

However, if you want to calculate your financial metrics in Euro (EUR), Japanese Yen (JPY), Russian Ruble (RUB), or any other currency, you can use the currencies_historical table which contains exchange rates of multiple currencies to the U.S. dollar for each day.

select 
  p.date,
  p.usd,
  round(p.usd/eur.rate::numeric, 2) as eur
from (select  
        eventtime::date as date,
        sum(p.priceusd) as usd
      from p102968.payments p
      where p.eventtime >= current_date - interval '30 day' and p.eventtime < current_date
      group by 1) p
  left join public.currencies_historical eur on 
      eur.source = 'EUR' 
      and eur.update_date = p.date
order by p.date

​This dashboard contains the overview table of key metrics for all projects in the space: Gross, New users, Active users, ARPU, Paying share.

At the top of the page, there are several settings:

• Calendar. This feature allows you to adjust the reporting period. It offers a dropdown list with predefined time intervals for quick selection:

  • Today

  • Yesterday

  • Last 7 days

  • Last 30 days

  • Last 90 day

• Revenue sources. This selector impacts the calculation of monetization metrics by selecting the ones you need from the list: SUB, IA, AD.

• Search. This functionality allows filtering the displayed apps in the table and the charts. For example, you can filter the table to show all projects on the Android platform or projects with the same name:

The table provides key metrics for all projects in the Space organized by apps. To the right of each metric value, a percentage is displayed, comparing the current period with the previous period of equal length. If you want to analyze the data of one of the applications, you can click on its name in the table.

Below the table, you can view the metrics values on the chart: New users, Active users, Day 1 retention by calendar, Gross, ARPU, and Paying share. A checkbox in the table marks the projects whose metrics will be displayed on the widgets.

At the bottom of the page, you can find the most important devtodev news.

This tool allows you to get access to any data stored in devtodev (basic and custom events) via SQL-based queries. It is available for the whole Space, which means that you can build a query for several projects simultaneously.

Query creation

Let’s look at how it works. First, explore the interface. There is a list of the projects in Space represented by the tables on the left side of the screen. Each product in our database has its own unique identifier which looks like pXXXXX. The name of the product is mentioned in brackets.

You can expand this project to see its table and column structure. On the right side of the screen, there is a field where you can write a query (Query Editor tab).

To do it faster you can use the following methods:

• One click on the scheme, table, or column in the list will put their names to the text of the query

• A combination of ‘Ctrl + Enter’ will run the query.

You can also change the time zone for the queries by choosing the right one in the top right corner. If there is a mistake in the query, you will see a notification. If not this query will be stored in History which will be available in the next tab. After you run the correct query, you will see the results at the bottom of the screen, where you can export them as a CSV file (up to 10M rows) or create a chart.

Making a chart

Columns in the result of the query will be used for making a chart. First of all, you need to select a type of chart. 8 options are available: line chart, area chart, column and pie charts, area and column stacked charts, combo chart and number. Then you can select a metric from the columns which were received in the query results which will be used as X-axis. It could be only 1 metric.

Then you can select one or several сolumns which will be displayed on the Y-axis. The number of these metrics depends on the selected chart type. For the pie chart, you can choose only 1 metric, for the rest of the chart types you can select up to 10 metrics.

It is enough to create a chart but you can also customize it if you tap “View advanced options”. This menu allows you to:

• add axis name

• add up to 4 Y-axes which will be useful when you create a chart for the metrics with completely different units or values (e.g. ARPU, Gross, Paying share, Number of purchases)

• change the axis type to linear, logarithmic or categorical

• distribute metrics by different Y-axes

• set a metric type when you use the combo chart

• set a specific rounding of values

• select a color for the chart

• write down the units that will be used to label the values on the chart and will be displayed in hints (%, pcs. $, etc.)

Axis scale settings

By default the values on the chart are scaled automatically so that the graph is centered.

You can change the axis boundaries by clicking on Axis scale button. Axis scale settings are available for Chart, Area chart, Stacked area chart, Bar chart and Stacked bar chart types.

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.

When you save a widget to the dashboard or copy report URL, the settings for axes are saved as well.

Managing SQL query variables

Filters are often used in SQL queries, e.g. filters by country, registration date, app version, user ID, payment status, etc. Occasionally, you need to change parameters of these filters to run a query on another user category. Even more, sometimes you need to change them not in the query but directly in the dashboard.

The feature described below allows you to use the interface to change values of query variables without altering the text of the query.

How to create a variable

You can specify variables in the SQL query text, save it as a widget (with defined variables) on a dashboard and later change the variable values if you need.

To create a variable, open a menu by clicking the @ icon in the top right corner. Click «+ Add variable».

In the ‘Variable name’ block, specify the variable name that will be used in the text of the query. This name will also be used when merging variables in a single dashboard.

In the ‘Control title’ block, specify the name of control that will be used in the interface.

After that, select the variable type (read more about types below). There are the following types:

• Date

• Timestamp

• Period Interval

• Text

• Number

• List of reference values

• List of numbers

• List of strings

Set a default value of each variable. You can change this value later.

After adjusting all the settings, click ‘Save’ in the column with variable names on the left.

Actions available for variables:

• Edit variable settings. Click the @ button (the one you used for variable creation) and select the desired variable from the list on the left. After that, open the list of settings that you can change any time.

• Edit variable values. Open a list of variables in the ‘Defined variables’ block and click on the variable. In the window that opens you can set or change the value of the variable. You can also do this by clicking the ‘Edit’ button in the block of variables.

• Set default values of variables by clicking the ‘Reset to default’ button. This will reset the values of variables to their default values specified at the time those variables were created.

• Delete a variable. Click the @ button and then click the cross next to the variable to delete it.

By clicking the @ button, you can not only create a new variable (‘Create new variable’ option), but also select a variable out of the variables previously created in the current project by a single user. Click ‘Select from recently created’ and get a list of the last 10 variables.

Variable types

Date

This type of variable allows you to set a date in the ISO 8601 format (YYYY-MM-DD) to use it in the query, e.g. 2022-03-15 date specifies that you will factor in all values received from 2022-03-15 00:00:00 to 2022-03-15 23:59:59.

There is a ‘Rolling time frame’ option available for this type of variable. If you select it, then when opening the report, as the value of the variable you will get the defined date with an offset for the number of days passed. For example, you set 2022-03-15 in the ‘Select default value’ field, then after five days you run the SQL query and the system will use another date - 2022-03-20.

Timestamp

This type of variable allows you to set a date and time in ISO 8601 format (YYYY-MM-DD hh:mm:ss), e.g. 2022-03-15 14:35:00.

Period

This type of variable allows you to set a date range, e.g. 07.Mar.2022 - 13.Mar..2022 means that you are going to include the entire time period from 07.Mar.2022 00:00:00 to 12.Mar.2022 23:59:59.

To use the variable in a query, write the following: created >= @variable.from and created < @variable.to

Interval

This type of variable allows you to work with relative time intervals, e.g. 30 days, 4 weeks, 2 months.

You can use the intervals to limit action time or registration dates. Intervals are convenient to work with because they are not fixed but are always changing. For example, a payment made within the past 30 days:

Text

This type of variable allows you to use text values, e.g. names of game characters or items:

Number

The ‘Number’ type of variable allows you to input a number as a variable value, e.g. 2 or 2.6.

Use it in a query to filter values of custom event parameters or number of payments:

List of reference values

Here you can select available values from the lists, e.g. certain countries, campaigns, item names, etc. It works similar to filters in the interface of our reports:

To use the variable in a query, write the following: country = any(@variable)

List of numbers

This type of variable allows you to specify a list of numbers that can be further filtered using a query, e.g. values of a custom event parameter or tutorial step numbers:

To use the list, write: step = any(@variable) Use commas to separate the numbers in the list.

List of strings

You can use several string values in this variable, e.g. version numbers, list of items or countries, string parameters values.

To use the list, write: appversion = any(@variable) Use commas to separate the values in the list.

How to use variables in queries

After you have created the variables, they will show up in the ‘Defined variable’ block above the query text.

This block works similar to creating variables using the DECLARE function. In this case, however, you don't need to duplicate them in the text of the query. In the query, you can use the variables described in the ‘Defined variables’ list.

To add a variable to a query, click on its name in the ‘Defined variables’ block and it will appear where the cursor is positioned. Or you can type in the name of the variable after @ in the text of the query.

select country, sum(priceusd) as gross 
from p102968.payments p
where eventtime>=current_date - @rel_dates      -- Data type: Interval
and paymentcount = @paym_cnt                    -- Data type: Number
and p.product like @item_name                   -- Data type: Text
and appversion = any(@ver)                      -- Data type: List of strings
and country = any(@countries)                   -- Data type: List of reference values
and created::date = @inst_date                  -- Data type: Date
and lastpaymentdate::date >= @last_paym.from and lastpaymentdate::date < @last_paym.to  -- Data type: Period
group by 1

Change widget’s variable values on a dashboard

After you’ve added a query with created variables to a dashboard as a widget, you can change the values of the variables by using the filter icon in the top right corner of the widget.

If the variable value in the filter is different from a default value, then the filter icon turns darker.

Create common dashboard controls

If a dashboard contains several widgets with similar variables, e.g. country or creation date, then you can choose to edit the values of the variables simultaneously in all the widgets that contain them.

To create a dashboard control that will be common for all the widgets, click ‘Manage controls’ in the dashboard menu.

In this section you can create a control (e.g. country) and assign it to respective variables from the dashboard widgets. Also, in this section you can view, edit and delete created dashboard controls.

To create a control:

1. Enter the name of the control

2. Select the variable type (date, text, list of numbers etc.)

3. In the drop-down menu, select the widgets (out of those containing the variable of the selected type) to which the common filter will be applied.

4. In the next drop-down menu, select a specific variable of the selected type in the selected widget. It may be that there are two variables of the same type in the widget (e.g. installation date - “created” and date of event - “eventtime”) then when creating a general control you need to select the one that you need.

Let’s look at an example. A dashboard has several SQL widgets that contain variables of the ‘List of reference - Country’ type. You want the values of these variables to change simultaneously in all dashboard widgets that contain it. You create a common dashboard control for the three widgets. Default values are pulled up from the first variable in the list and become default for the entire control. It means that all three widgets will be built for the same countries.

Another example. You want all dashboard widgets to be built over the same period. In this case we need to create a ‘Period’ type of variable in each SQL widget that will set the date range for the report (the period will be pulled up automatically from widgets created in other reports). After that, you need to create a common dashboard control and unite the ‘Period’ variables from all the widgets.

Change the values of widget variables

After you create a common dashboard control in the ‘Manage controls’ section, it will appear as a block in the upper part of the dashboard.

To change control values, click these values and then click ‘Edit’ in the top right corner of the ‘Variables’ block. After that, the variable values will be updated in all the widgets that contain the variables.

If a variable of a widget is taken out of control on the dashboard level, then changing its values using the widget filter is impossible.

Saving and downloading the data

After you get the results of the query you can save the report by clicking on the Settings button in the top right corner. The chat settings will be saved as well.

This saved report will be available in the table in the SQL section of the top menu.

You can also download the results of the query to a CSV file by clicking on buttons above the table with the results or use the Settings button on the top right corner.

Now let’s explore the details of writing SQL-queries.

SQL functions description

The major PostgreSQL functions are available in this tool for writing a query such as:

• All types of Joins and Union

• Subqueries and aliases

• Operators for comparison values (!=, <, >, between …)

• Logic operators (and, not, or)

• Mathematical operators (+, -, abs, log, …)

• Working with strings (substring, concat, length, ...)

• Conditions (case, coalesce, least, …)

• Grouping, ordering, limit, having

• etc.

To learn more about SQL queries functions visit this page

Functions that are not available currently:

• temporary table creation

• tables creation and adding data to tables

• creation of indexes to the table

• stored procedures

Working with the date and time

First of all, you can easily select the time zone for making queries by choosing the right one in the dropdown menu of the top right corner of the query field.

After doing this, the time zone will be automatically applied to all dates used in the query. For working with dates and time ISO 8601 format is used. To get the date you can apply the following functions:

To modify date and time, use the following functions:

Use intervals to move dates

Here are several examples of how you can set the intervals:

• ‘1-2’ means 1 year and 2 months

• ‘0-1 2’ means 1 month and 2 days

• ‘1 02:03’ means 1 day 2 hours and 3 minutes

• 1 year 2 month 3 week 4 day 17 min

• 1 week 02:03:04 means 1 week 2 hours 3 minutes 4 seconds

For rounding dates use this function:

The following values can be used as the ‘field’:

• Microsecond

• Millisecond

• Second

• Minute

• Hour

• Day

• Week

• Month

• Quarter

• Year

• Decade

• Century

• Millennium

For formatting dates use this function:

Here are several mask examples:

• HH12 - hour of day (01-12)

• HH24 - hour of day (00-23)

• MI - minute (00-59)

• MS - millisecond (000-999)

• AM, am, PM or pm - meridiem indicator (without periods)

• YYYY - year (4 or more digits)

• Y - last digit of year

• IYYY - week-numbering year (4 or more digits)

• MONTH - full upper case month name (blank-padded to 9 chars)

• MM - month number (01-12)

• DAY - full upper case day name (blank-padded to 9 chars)

• DD - day of month (01-31)

• WW - week number of year (1-53) (the first week starts on the first day of the year)

• TZ - upper case time-zone name

• etc.

Data structure

Let's take a look at the database structure. The highest level in the tree contains all projects of the space. Each project contains a list of tables. Some of them are related to basic events, others - to сustom events (their names start with the underscore sign). Most of the tables include the following fields:

• devtodevid - unique identifier of the user which is used in devtodev and assigned to the user when he launches the app for the first time. It could be different for one user in different apps.

• firstpaymentdate - unix timestamp of the first user payment

• lastpaymentdate - unix timestamp of the last user payment

• created - when the user opened the app for the first time

• paymentcount - number of payments that the user have made in the app

• paymentsum - total sum of payments in USD

• level - current user’s level which couldn’t be decreased

• deviceid - identifier of the device

• country - user’s country

• locale - user’s language

• device - name of the device model (IPHONE 6S PLUS, GALAXY NOTE 10+, etc.)

• eventtime - time in unix timestamp format when the specific event was performed

• eventlevel - on which level user performed the specific event

• appversion - current version of the app for specific user

• cheater - whether the user has cheated or not (true/false)

• tester - whether the user is a tester or not (true/false)

• firstappversion - the first version installed by the user

• firstappversionid - ID of the first installation version

• sbsfirstpaymentdate - unix timestamp of the first subscription payment date

• sbspaymentcount - the number of subscription payments made by the user in the app

• sbspaymentsum - total amount of subscription payments in USD

• segmentvalues - whether or not the user belongs to a segment. For more information, see the ‘User segments’ section below

Fields in levelups table:

• leveluprecordid - identifier which can be used for connection with Levelup_currencies table

Fields in levelup_currencies table:

• type - how the resource was changed. It could be: 'BALANCE', 'SPENT', 'EARNED', 'BOUGHT'

• leveluprecordid - identifier which can be used for connection with Levelup_currencies table

• _{currency_name} - such a column will be created for each currency of the project. For example, "_Coins". The name of the column will be the same as it was received from the app.

Fields in the tutorial table:

• step - if the value is more than 0, then it is the number of the tutorial step, step = 0 means that tutorial was skipped, step = -1 means that tutorial was started, step = -2 means that tutorial was finished.

Fields in payments table (this table contains information about real payments):

• currency - shows the currency of the payment

• price - price of the product in the user's currency

• priceusd - price of the product in USD

• revenueusd - price of the product in USD after the store comission rate. The revenue rate is set up in Settings -> SDK -> Payments.

• product - name of the purchased product

• paymentid - identifier of the payment

Fields in purchases table (this table contains information about in-game payments):

• amount - amount of the purchased product

• price - price of the purchased product

• currency - currency of the purchased product

• itemtype - group of the purchased product

• item - name of the purchased product

• _{currency_name} - such a column will be created for each currency of the project. For example, "_Coins". The name of the column will be the same as it was received from the app.

Fields in sessions table:

• activityduration - duration of the session in seconds

• sessionstarts - number of sessions

• eventtype - type of the event: "gs" - contains duration and amount, "ss" - contains only amount, "ue" - contains only duration

Fields in progressions table (this table contains information about changes of locations):

• duration - duration of completing the location in seconds

• progressionrecordid - identifier of the event. Can be used for connection with the progression_currencies table

• locationsourceid - identifier of the location

• difficulty - difficulty of the location

• success - whether the location was passed successfully or not

• locationsource - name of the location

Fields in progression_currencies table (this table contains information about resources which was sent with the progression events):

• type - how the resource was changed. It could be: 'SPENT', 'EARNED'

• _{currency_name} - such s column will be created for each currency of the project. For example, "_Coins". The name of the column will be the same as it was received from the app.

Fields in push_clicked, push-sent tables:

• pushcampaignid - identifier of the push campaign

• name - campaign name

• success - whether it was sent successfully or not

Tables with custom events have the same fields as tables with basic events. If there are any parameters in these tables, their names also start with the underscore sign.

Other fields that custom event tables contain:

• customeventid - identifier of the custom event

• name - custom event name

• _{custom_param_name} - each event parameter has a column with its name which contains the parameter value (for example, "_bonus").

If you want to combine users from different projects then use the following user identifiers:

• If these apps are on different platforms (for example, iOS and Android), you can merge them only if your project uses a custom identifier that is sent to devtodev (https://docs.devtodev.com/faq/identification#identification-by-user-id-set-by-developer ). Then you can use ‘customuid’ field.

• If the apps are on the same platform, then you can use ‘idfa’ field for iOS apps or ‘advertisingid’ for Android apps.

Information about Users and Payments is available for the whole time, the rest of the data is available for the last 90 days.

User segments

segmentvalues field in the user card (the 'Users' table) contains information about the current user segment with a true/false value. In event tables there is also a segmentvalues field which contains segment values at the time of the user performing it. A special data type has been created for segments that is converted to an array of segment names while being displayed. Usage example:

SELECT  devtodevid, segmentvalues, segmentvalues->'example'
FROM p102968.users
WHERE segmentvalues is not null

Views in SQL

In devtodev analytics, you can create materialized, automatically updated as well as normal (with no physical materialization) query Views.

A View is a virtual table with a content determined by a query. Like a table, the View consists of a set of named columns and rows of data. After you create the View, it appears in the list of tables in the “views” directory on the left and can be used for writing SQL queries.

The use of materialized Views can drastically speed up dashboard loading because they allow you to execute a query against a data sample prepared in the View instead of running it against a larger dataset.

In addition, you can collect the necessary data from several tables in a single View and thus speed up query execution because it allows you to avoid joining entire tables.

How to create a View

CREATE [ OR REPLACE ] [MATERIALIZED [DAILY|WEEKLY|NEVER]] VIEW 
name [ ( column_name [, ...] ) ] AS query

OR REPLACE - if a View with a specified name already exists, it gets replaced with a new one. This works only with the Views that are visible during query execution. If you use an SQL project to create the View and it is conflicting with a View from another project, then OR REPLACE won’t function.

MATERIALIZED - the View result is saved as a table.

DAILY|WEEKLY|NEVER - the View is automatically updated with the specified frequency (calendar day or week). If not specified, NEVER is used - with no auto update.

name - View name. When creating the View, it is prohibited to specify a schema. All Views are stored in a dedicated views schema.

( column__name [, ...] ) - a list of fields. If specified, columns are named this way. The number of columns must be equal to the number of columns in the data sample. They are matched with columns in the data sample by index.

query - content of the View. SELECT or VALUES are available.

Types of Views

You can set up both materialized and normal Views. Normal Views are basically named queries. They can be used to avoid repeat statements in the queries.

Materialized Views are tables that are created based on a specified query and get updated on a schedule (DAILY, WEEKLY). If NEVER is used, or the update rate is not specified, the View ‘freezes’ the data sample.

Materialized Views can drastically speed up dashboard loading. Instead of running a query against a large data sample, you “freeze” the required part of it for a certain period of time (most often one calendar day) as a materialized View and then your dashboards get built much quicker. When using materialized Views, it’s a good idea to create intermediate data sets that can be used in a large number of dashboards, rather than setting up a separate View for each graph.

Some specific features of working with Views

1. View dependencies are supported - that is, you can create a View that uses other Views.

2. Important! Views can NOT contain more than 10 mln rows!

3. Important! When using a materialized View, it’s very important to use the same time zone that was set when the View was created.

4. If you want to revise or modify the View, open the list of all views (VIEWS) and change the code that was used to create it.

5. To delete views, use the DROP VIEW command.

DROP VIEW name

Usage examples

Create a projection (DAU, in this case)

CREATE OR REPLACE MATERIALIZED DAILY VIEW p2_dau(dau, eventtime, level, country) AS 
SELECT 
  hyperloglog_accum(devtodevid), 
  eventtime::date, 
  eventlevel,
  country
FROM p2.sessions s
WHERE 
	eventtime >=  current_date - INTERVAL '30 days'
	and eventtime < current_date  
GROUP BY 2,3,4;

Usage:

select round(hyperloglog_get_estimate(hyperloglog_merge(dau))) dau, eventtime
from p2_dau
group by 2
order by 2

Create dictionaries:

create view custom_dict (id, name) as values(1, 'name_1'), (2, 'name_2')

SQL query examples

Let’s explore several SQL query examples. Number of purchases of different product grouped by months:

select to_char(eventtime, 'yyyy-mm') as month
, count(eventtime) filter (where product = 'offer4') as offer4
, count(eventtime) filter (where product = 'starterpack') as starterpack
, count(eventtime) filter (where product = 'offer1') as offer1
, count(eventtime) filter (where product = 'special offer') as special_offer
, count(eventtime) filter (where product = 'offer2') as offer2
, count(eventtime) filter (where product = 'offer3') as offer3
from p102968.payments p
where eventtime >=current_date - interval '6 month' and eventtime < current_date
and tester is false
group by 1
order by 1 asc

On the next tab, we can build a chart using data from the results of the query:

The number of users who installed the app 1 month ago, passed at least 3 levels, and haven't added a friend:

select count(distinct l.devtodevid) filter (where level >=3)
from p102968.levelups l
left join p102968."_add friend" f
on l.devtodevid=f.devtodevid and f.eventtime >= date_trunc('month', current_date) - interval '1 month'
where l.created >=current_date - interval '1 month' and l.created < current_date
and l.eventtime >=current_date - interval '1 month' and l.eventtime < current_date
and f.devtodevid is null

Example 1

The result of this query is a list of user events for the last 2 days sorted by the amount of times the event was performed.

Example 2

The result of this query is a list of last user events before they churn. The churn period is specified.

Example 3

The result of this query is a timestamp of the last event with numeric value.

The result of this query is a timestamp of the last event with text (string) value.

Example 4

Use this query to find the users with decreasing player level (events with decreasing player level alert). The result of this query is a list of users and their previous and current levels.

Example 5

Use this query to calculate user retention. The result of this query is a table that contains the number of new users per day and the number of returning users on the 0th, 1st, 2nd, 3rd, 7th, and 14th day after installation.

gives you information about audience overlap (of a set of advertising IDs) in applications of the same platform within the space. This report becomes available when you have at least two applications on the same platform within the space, but it is not available for web applications. To match users during report building, we use a set of advertising IDs, that is, for an advertising ID used in one project, we look for similar IDs in another project. For iOS applications comparison we use IDFA, and for Android and Windows applications comparison we use advertising ID.

Some users don’t have an advertising ID parameter in their card and these users are not taken into account while comparing apps’ audiences.

The report has two tabs:

• General report

• Advanced report

The “General report” tab contains general information about the number of overlaps of active and paying audiences. In order to build a report you need to select the application platform, the overlap period, and select the applications that you want to compare. The overlap period is the time period during which users were active in at least one of the comparison projects. Then click the "View result" button to see the report results.

The Active users chart shows the overlap of active users in the selected projects (users who had at least one session in the selected period).

The Paying users chart shows the overlap of paying users (users who made at least one payment) in the selected projects.

The "Advanced report" tab allows you to compare users by custom parameters. To perform a comparison, you need to select the Main project and the Donor projects with which the comparison is to be made. You also have to choose the criteria of overlapping. You can overlap the audience by:

• channels

• countries

• amount of payments

• number of payments

• date of the first payment

• date of the last payment

• date of last activity

To add several overlaps with different criteria press +Counter. After specifying the settings necessary for comparison, click the "View result" button to see a report results table. You can change the display of audience overlap results from a table to a chart.

After receiving the results of the comparison you will be able to:

• create a user segment and study the behavior of the users later on. For example, you can save a segment of users who make payments in Application A, but don’t pay in Application B. After that, using the created segment, you can study user behavior in detail: what offers motivate users to buy in Application A, what goods they buy there, what amount of money they spend. Perhaps the prices in Application A are lower than in Application B, or in Application A you can buy goods for customizing your game character, while in Application B there are no such goods. After analyzing the paying audience of your application you can develop hypotheses for A/B testing, as well as start sending push notifications with appealing offers to potential paying audience.

• select a potential paying audience for behavior research and Gross increase. For example, by studying a segment composed of users who have not paid in Application B for a long time or users who pay more in Application A. Thus, you can analyze what exactly users buy in Application A, at what stage they make payments, what amount of money they spend, what offers motivate users to buy. With this information at hand, you can test various hypotheses (price changes, offer content, etc.) that can increase Gross.

• export users’ devtodevId to a CSV file. This can for example save cross-promotion costs by excluding users who are already using the promoted application. Or you can upload the IDs of the users who are not yet using your second application in order to promote it later on:

The 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)

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.

Here are the articles in this section:

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

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!

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

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.

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.

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.

Reports in this section 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:

• Dashboard

• Economy Balance

• Virtual Goods & Purchases

• Game structure

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.

In this section you have several menu tabs:

• Basic Metrics

• Conversion Funnels

• Custom Events

• SQL Wizard

• SQL

Basic Metrics

In this section you can create and save custom reports. To create a custom report, choose metrics you want to see and click the “View result” button. If you would like to build the report after changing settings, use the “Refresh” button. You can choose up to 10 metrics.

You can change the following settings of the chart:

‘Group By’ section includes two lists: ‘Main groups’ with the basic criteria for grouping such as ‘Applications’, ’Country’, ‘Platforms’, etc. and ‘Custom user properties’ which contains custom properties that are being sent to ‘User profile’.

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

The Custom Event report allows you to analyze and keep track of user activity collected as 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.

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.

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.

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.

Key metrics forecast

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

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.

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

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 , 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

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