Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This block of reports allows to analyze users acquisition in your application. To start analysing user acquisition in your app, you need to:
Integrate an attribution platform (we support Adjust, AppsFlyer, Tune, Branch, Kochava and Tenjin) using postback URL's from the Integration section (Settings > 3rd party sources > Attribution tracking). Please note that to do it you must be in Admin or Owner role.
Integrate devtodev SDK into your application and you will be able to evaluate the quality of your traffic in devtodev. Learn more on the page below:
Acquisition reports:
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.
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.
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.
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.
Check out the Predictions section to learn more about LTV Prediction!
An Overview Dashboard 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.
This report shows the dynamics of quality metrics for different cohorts based on install date.
There are two pages available:
Custom cohorts
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.
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)
present information about user behavior related to retention and engagement.
Engagement reports are:
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.
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.
This report contains 2 sections: General, Cohort Playtime.
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.
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)
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.
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 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.
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).
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.
You can choose any tutorial metrics you need and see how users finish the tutorial and compare different versions.
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.
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.
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.
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.
This report shows the most popular actions (events) carried out by users during their first days in the app. The data is presented for two cohorts of users so that it’s convenient to compare them.
You can analyze the top 3 most popular events for every minute of the first in-app hour. You can also select the first in-app day or three in-app days in the “Period” drop-down list.
First of all, you need to define the “Primary Cohort” and “Comparative Cohort” by adding install dates and any additional filters (by default the system creates cohorts for the last 7 days with different paying capacity).
The list of the most popular events is created based on events carried out by users from the “Primary Cohort”. The same events are used for analyzing the “Comparative Cohort”.
If you want to see a report only for specific events, use the “Include events” drop-down list to include or exclude events.
If you need to know the exact parameter values of events, enable them in the “Include events with params distribution” menu. Then click on an event name and then “Show by parameters”. You will be able to see the parameters of selected events for users from both cohorts.
This report also takes into account users’ churn (when users stop using an app). Here churn is the period of users’ inactivity after which they will most likely never open the app again. This period should be set up in the “Churn period” section.
For the both cohorts we have the Total number of users that are taken for observation. Time since the first launch is a timeline of your new users activity. Each time period (0-1min, 1-2min … 22h-23h) shows maximum three events - these are the most common events of users from the Primary Cohort. Then the system calculates the proportion of users that perform this event to all users in each cohort.
For every time period on the given timeline the number of Active users is calculated (these are users that sent any event selected in the “Include events” section). The percentage of Active users is calculated from the number of Total users.
In addition to that, you can see how many users churn in each time period. The Churn users are users that were active for a certain time period on the timeline (i.e. sent at least one of the selected events) but then churned – were inactive during the selected Churn Period. The percentage of Churn users is calculated from the number of Total users.
For better understanding of the user lifecycle, the report provides you with milestones. You can see when the majority of users (75%) that haven’t churned before a particular period on the timeline complete the most important events in your app. The following milestones can be shown for your app:
Tutorial completion
Level up + Number of level
First payment
This report requires Tutorial Step basic event integration. Learn more
This report requires Custom Event integration. Learn more
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 requires Custom Event integration. Learn more here
Reports in this section cover key monetization metrics.
All reports here require Payment event integration. Learn more about Payment event.
Monetization reports:
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.
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).
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.
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.
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.
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).
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.
The report helps you evaluate how users interact with ads in your application.
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.
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
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.
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.
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.
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 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.
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.
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.
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.
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:
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.
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.
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.
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.
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:
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.
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.
The Virtual Goods & Purchases report shows the detailed overview of how users spend in-game currency.
There are 4 pages available:
Top purchases
Structure of purchases
Dynamics of purchases
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.
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.
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.
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 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.
This report shows the distribution of users among players’ levels (of experience), locations and cumulative metrics.
There are three pages available:
Player levels
Cumulative metrics by level
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.
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 - 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).
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.
| Segment name | R | FM | Description | How to apply it |
|---|---|---|---|---|
1. Can’t Lose Them
1-2
5
These customers made the biggest purchases, and made them often. But they haven’t returned for a long time.
Try to win them back by offering them renewals or newer offers, features. There is a chance to lose them to competition, try talking to them.
2. Loyal Customers
3-4
4-5
Customers who spend often good amounts of money. They are responsive to promo activities.
Try to upsell higher value products. Ask for reviews and think how you can engage them.
3. Сhampions
5
4-5
Customers who bought recently, buy often and spend the most money.
Try to reward them. These customers can be early adopters for new offers and features. They will promote your app.
4. At Risk
1-2
3-4
These customers spent big sums of money and made purchases often but a long time ago. You need to bring them back!
Try to reconnect with customers by sending them personalized push notifications, offering renewals, and providing helpful resources.
5. Need Attention
3
3
Customers in this segment have above average recency, frequency and monetary values. They may not have made purchases very recently though.
Try making time limited offers, recommend based on past purchases, and reactivate them.
6. Potential Loyalists
4-5
2-3
These are recent customers who spent a good amount and made purchases more than once.
Try offering membership or loyalty programs, and recommend other products.
7. Hibernating
1-2
1-2
Last purchase by these customers was a long time ago. They are low spenders and have a low number of orders.
Try offering them other relevant products and special discounts. You can also promote new features and modes.
8. About To Sleep
3
1-2
Customers have below average recency, frequency and monetary values. You will lose them if they remain not reactivated.
Try sharing valuable resources, recommend popular products, renewals at discount, and reconnect with them.
9. Promising
4
1
These customers are recent payers but they haven’t spent much.
Try making time limited offers and persuade them to use the app more frequently.
10. New Payers
5
1
These users have just converted to payers.
Try engaging them to use the app more frequently and give them bigger discounts.
