Engagement reports
These reports present information about user behavior related to retention and engagement.
Engagement reports are:
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:
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)
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
Last updated
Was this helpful?