Level Progress Report and Dashboard

Overview

The Level Progress Report and Dashboard provide comprehensive insights into user progression through game levels and their interactions with in-game currency, boosters, and hints. These tools help game developers evaluate player behavior, retention patterns, and monetization strategies, ensuring optimized level design and enhanced engagement mechanics.

The Level Progress Report employs a cohort-based approach, aggregating data over a 30-day period from the date of app installation. Installation data is retrieved from AppsFlyer or Adjust, ensuring accurate user acquisition tracking.

The Level Progress Dashboard, on the other hand, offers real-time tracking of level completion trends, displaying a fixed date range of the last 24 days plus the current day.

Both tools rely on event data from gameplay sessions and in-game transactions, which require proper SDK configuration for accurate tracking. Simply integrating the SDK is not enough—developers must ensure event names follow the correct format and that necessary data is sent.

Key Features

1. Cohort-Based and Real-Time Analysis

The Level Progress Report groups users into cohorts based on their installation date and aggregates data over 30 days post-installation.
The Level Progress Dashboard presents daily data updates within a rolling 25-day window, allowing real-time monitoring of user progression.

2. Data Aggregation from Session and Transaction Events

SessionEvent Model: Captures in-game actions such as level completion, failure, and retries.
Transaction Model: Tracks in-game currency movements, booster usage, and hint consumption, providing insights into monetization behaviors.
Events are sourced from the SDK, but prior configuration is required for proper data transmission and accuracy.

3. Level Progression Tracking

Tracks user completion rates for each level and highlights difficulty spikes where users struggle.
Measures average attempts per level, helping to balance difficulty and improve engagement.

4. In-Game Currency and Booster Impact

Analyzes how currency usage correlates with level progression.
Tracks booster and hint consumption to evaluate their effectiveness in retention and engagement.
Provides monetization insights by linking in-game purchases with level completion data.

5. Retention and Engagement Insights

Identifies patterns in user progression and highlights drop-off points.
Helps optimize difficulty scaling and reward systems to improve long-term engagement.

6. Integration with Attribution Platforms

Uses AppsFlyer and Adjust to match session and transaction data with user acquisition sources.
Allows analysis of user progression across different marketing channels and campaigns.

7. Customizable Metrics and Filters

The Level Progress Report supports filters for cohort selection, level range, and in-game currency usage.
The Level Progress Dashboard provides daily-level tracking with interactive visualizations for immediate performance analysis.
Both tools support additional KPIs for retention and engagement tracking.

Use Cases

Game Balancing – Identify difficulty spikes impacting retention and adjust level design.
Monetization Optimization – Understand how in-game purchases influence level completion and progression.
User Retention Analysis – Evaluate drop-off points and adjust mechanics to improve player engagement.
Marketing Performance – Correlate user acquisition sources with in-game behavior to refine targeting strategies.

Both the Level Progress Report and Dashboard are essential tools for game developers, allowing data-driven decision-making to enhance player experience, optimize retention, and maximize monetization.

Level Progress Report

The Level Progress Report analyzes user progression, tracking level completion, drop-offs, and monetization factors like in-game currency, boosters, and hints. It provides cohort-based insights over a 30-day period from installation, using data from AppsFlyer, Adjust, and gameplay events.

Accurate reporting requires proper SDK integration and correct event formatting. Developers must ensure event tracking aligns with reporting needs. Analysts may need to adjust configurations for game-specific behavior.

This report helps optimize level difficulty, retention strategies, and monetization impact.

Definition of Cohort and Cohort Analysis

Cohort

A cohort is a group of users who share one or more common characteristics, such as:

A specific action (purchase, registration, click, etc.).
A specific time frame in which the action occurred.

Cohorts are formed based on user behavior data, allowing for the analysis of user interactions with the application over time.

Differentiation Between Cohort and Segment

Cohorts should not be confused with segments. Unlike cohorts, segments represent broader user groups categorized by shared characteristics. For example, Harvard graduates from 2012 and those from 2018 belong to different cohorts but fall under the same segment of “Harvard graduates.”

Cohort Analysis

Cohort analysis is a research method in which users are grouped into cohorts and their behavior is tracked over a defined period. This approach helps identify trends in user behavior dynamics, retention, engagement, and response to changes in game mechanics.

SDK Data and Client ID Matching

To ensure accurate reporting, it is essential to establish a reliable connection between app installations and SDK data. This connection is maintained through an internal user identifier, Client ID. The Client ID must meet the following criteria for consistency:

It must be received both from the Mobile Measurement Partner (MMP) (AppFlyer or Adjust) and the SDK.
The Client ID must be identical across both sources to correctly attribute user data.

Metric Segmentation and Automatic Switching

The report is structured into two metric categories:

Event-based metrics
Transaction-based metrics

Metric availability is dynamically adjusted based on the selected filter or dimension, following the "at least one" principle. This means:

If any chosen filter/dimension lacks compatibility with a specific set of metrics, those unavailable metrics will be automatically excluded from the report.
Even if other selected filters/dimensions support all metrics, any restricted metrics due to the initial selection will remain hidden.

Example: Transaction vs. Event Metric Availability

Transactions and Boosters Source
- The SDK transmits transaction data, including the source of in-game currency (Boosters Source).
- Transactions can be linked to specific in-game currency sources.
- However, for event-based data (e.g., level start, success/failure completion), no direct association exists with the in-game currency source.
- As a result, when filtering by Boosters Source, only six currency-related metrics will be available, while eight event-based metrics (level start and completion) will be excluded.
Game Level DimensionWhen filtering by game level, it is possible to determine both the level where a booster was obtained and the level where a player started or completed an event. Consequently, when filtering by game level, all metrics remain accessible.For additional details, refer to the tooltip section below.

Filters and Dimensions

The Filters and Dimensions table is used for setting up analytics and reporting within the system. It allows users to filter data based on various parameters and group it into meaningful segments for analysis.

Filters help narrow down the dataset by displaying only the relevant values based on specified criteria.
Dimensions are used to group data by different attributes, such as date, platform, country, and other metrics.

Filters and Dimensions	Description	Comment
Application	The name of the application.	Only one app can be selected in this filter, as it is not possible to sum identical bonuses from different apps.
App Version	The version of the application.	Any number of versions can be selected, as identical bonuses from different versions can be summed.
Day of Install	The installation date of the application.	Allows selecting a date range. A single date can be selected if the start and end of the range match. The selection can include dates within the last 180 days.
Day of Event	The date when an event occurred in the application.	Allows selecting a date range. A single date can be selected if the start and end of the range match. The selection can include dates within the last 90 days.
Day Index	The number of days between the installation date and an event.	Allows selecting a range of day numbers. A single day can be selected if the start and end of the range match. The minimum filter value is 0.
Level	The in-app level reached by the user.	Allows selecting a range of levels. A single level can be selected if the start and end of the range match. The minimum filter value is 1.
Mode	The mode of the application or game.	Any number of modes can be selected, as identical bonuses from different modes can be summed.
In-App Status	The status of the user within the application.	Any number of statuses can be selected, as identical bonuses obtained while the player is in different statuses can be summed.
Country	The country of the user.	Any number of countries can be selected, as identical bonuses from different countries can be summed.
Media Source	The source of traffic.	Any number of sources can be selected, as identical bonuses for installs from different sources can be summed.
A/B Test	The name of the A/B test.	Only one test can be selected at a time.
A/B Test Group	The group in an A/B test.	Multiple groups can be selected (usually up to 2).
Codeword	A custom keyword used for filtering events.	Free text filter. Retrieved from `custom_params` in the `SessionEvent` table (configured individually for each application upon request).

Note

The In-App Status filters represent dynamic user states sent by the SDK. These states reflect the user's status at specific moments rather than fixed attributes.

For example, if you select In-App Status = Paying, the data displayed will not include all users who have made an in-app purchase. Instead, it will show data for users after they have completed a purchase.

This distinction is important when analyzing user behavior, as these filters provide insights based on the user's current state at the time of the event rather than their entire purchase history.

Metrics

Data Collection and Event Mapping Requirements

For this report to function correctly, SDK data transmission must be properly configured in the SessionEvent and Transaction models. This configuration is handled at the SDK integration level.

It is important to note that we cannot account for every possible event name defined by developers. To ensure accurate data collection, we rely on standardized event code names for event detection. The Comment column specifies the key terms we use in event names to extract the relevant metrics. The Model Name column indicates the specific SDK model where the data must be sent for metric tracking.

Transaction Model Event Processing

Event processing from the Transaction model is configured individually upon request. In this report, the system maps numeric values (1-10) to in-game currency names.

For example, in an application with two boosters — Star and Heart —we assign:

Heart = Event 1
Star = Event 2

As a result:

The number of Hearts spent will be recorded in Spend Event 1.
The number of Hearts received will be counted in Receive Event 1.
The number of Stars spent will be recorded in Spend Event 2.
The number of Stars received will be counted in Receive Event 2.

This mapping system ensures that in-game currency transactions are accurately tracked and reported based on predefined event codes.

Metric	Description	Model	Comment
Users Opened Attempts	The number of users who opened a level.	SessionEvent	Users with event `%level%open%` or `%level%started%`
Users Completed Attempts	The number of users who completed a level.	SessionEvent	Users with event `%level%complet%`
Failed Attempts	The number of attempts when users had an unsuccessful result within a level.	SessionEvent	Attempts with event `%level%failed%`
Users Failed 1 Attempt	The number of users who had 1 unsuccessful attempt within a level.	SessionEvent	Users with 1 event `%level%failed%` within the level
Users Failed 2 Attempts	The number of users who had 2 unsuccessful attempts within a level.	SessionEvent	Users with 2 events `%level%failed%` within the level
Users Failed 3 Attempts	The number of users who had 3 unsuccessful attempts within a level.	SessionEvent	Users with 3 events `%level%failed%` within the level
Users Failed 4 Attempts	The number of users who had 4 unsuccessful attempts within a level.	SessionEvent	Users with 4 events `%level%failed%` within the level
Users Failed 5 Attempts	The number of users who had 5 unsuccessful attempts within a level.	SessionEvent	Users with 5 events `%level%failed%` within the level
Users Failed 6 Attempts	The number of users who had 6 unsuccessful attempts within a level.	SessionEvent	Users with 6 events `%level%failed%` within the level
Users Failed 7 Attempts	The number of users who had 7 unsuccessful attempts within a level.	SessionEvent	Users with 7 events `%level%failed%` within the level
Users Failed 8 Attempts	The number of users who had 8 unsuccessful attempts within a level.	SessionEvent	Users with 8 events `%level%failed%` within the level
Users Failed 9 Attempts	The number of users who had 9 unsuccessful attempts within a level.	SessionEvent	Users with 9 events `%level%failed%` within the level
Users Failed More than 10 Attempts	The number of users who had more than 10 unsuccessful attempts within a level.	SessionEvent	Users with more than 10 events `%level%failed%` within the level
Spend Event 1	The number of times users spent booster #1.	Transaction	Booster usage from the `bonus_type` column (configured individually per application upon request)
Spend Event 2	The number of times users spent booster #2.	Transaction	Booster usage from the `bonus_type` column (configured individually per application upon request)
Spend Event 3	The number of times users spent booster #3.	Transaction	Booster usage from the `bonus_type` column (configured individually per application upon request)
Spend Event 4	The number of times users spent booster #4.	Transaction	Booster usage from the `bonus_type` column (configured individually per application upon request)
Spend Event 5	The number of times users spent booster #5.	Transaction	Booster usage from the `bonus_type` column (configured individually per application upon request)
Receive Event 1	The number of times users received booster #1.	Transaction	Booster receipt from the `bonus_type` column (configured individually per application upon request)
Receive Event 2	The number of times users received booster #2.	Transaction	Booster receipt from the `bonus_type` column (configured individually per application upon request)
Opened Attempts	The number of times users opened a level.	SessionEvent	Events `%level%open%` or `%level%started%` from the session events table
Interstitial Count	The number of times users saw an interstitial.	SessionEvent	Events `interstitial_view` from the session events table
Reward Count	The number of times users received a reward.	SessionEvent	Events `%reward%` from the session events table
DAU	The number of unique active users per day.	SessionEvent	Unique `client_id` from the session events table
Failed Rate	The level difficulty metric.	SessionEvent	Ratio: `failed_attempts/cnt_completed`
PreHalf Level Failed	The number of failed attempts in the first half of the level (`FuuFactor = 0`). Each application defines what is considered the first half of the level.	SessionEvent	`FuuFactor` is the ratio of combined tiles to the total number. It is a parameter sent by the client. In JSON, the parameter `FuuFactor=0` must be included.
PastHalf Level Failed	The number of failed attempts in the second half of the level (`FuuFactor = 1`). Each application defines what is considered the second half of the level.	SessionEvent	`FuuFactor` is the ratio of combined tiles to the total number. It is a parameter sent by the client. In JSON, the parameter `FuuFactor=1` must be included.

Level Progress Dashboard

The Level Progress Dashboard provides insights into user progression across game levels. It enables tracking of player engagement, level completion rates, and potential drop-off points, helping optimize game balance and user experience.

Update Frequency: Once per day
Displayed Date Range: The dashboard shows a fixed range of the last 24 days plus the current day.

Level Progress Dashboard Widgets

The Level Progress Dashboard provides various widgets to analyze user progression, engagement, and level performance. Below is a detailed description of each widget, including its purpose, calculation rules, and limitations.

% Completed Levels to First Start

This widget calculates the percentage of users who started Level 1 on a given day and successfully completed the specified level. It helps analyze user engagement and identify levels where an abnormal drop-off occurs.

Calculation Rules & Limitations:

Tracks levels from the predefined list: [1, 2, 3, 4, 5, 10, 15, 20].
A level is considered started based on the following event triggers:
- 'Level Started', 'level_open', 'Level_Started', 'core_game_started', 'm3_game_started', 'level_started', 'level_start'
A level is considered completed based on:
- 'Level Complete', 'level_completed', 'Level_Completed', 'core_game_finished', 'm3_game_finished'
- The event must have the parameter Result = ‘won’.
Only levels where level = maxLevel or maxLevel is one level higher than level are considered (except for mycat and tamadog, where maxLevel is ignored).
Events are counted only for mode 'default' or 'single'.
For some applications, stats are collected based on 'level_start', meaning the widget will display the percentage of users who started Level 1 on that day and also reached the specified level.

% Completed Levels to Started (+Avg)

This widget calculates the percentage of users who started a specific level on a given day and successfully completed it. It is useful for identifying difficult levels that may impact engagement.

Tutorial Completion Rate

This widget measures the percentage of users who completed each step of the tutorial compared to those who started it. It helps assess tutorial effectiveness and identify potential bottlenecks.

% Completed TLE Levels to First Start

This widget calculates the percentage of users who started Level 1 of a Time-Limited Event (TLE) on a given day and successfully completed the specified level. TLE modes include easter_tle, halloween_tle, etc.

% Completed TLE Levels to Started (+Avg)

Calculates the percentage of users who started a specific TLE level on a given day and successfully completed it. This helps evaluate the effectiveness of TLE levels.

Churn Rate, 1/ARPU Rate, Failed Rate

These metrics provide insights into player retention, revenue, and level difficulty.

Metric Definitions:

Churn Rate: (Total churned users) / (Total unique users)
1/ARPU Rate: 1 / (Total revenue / Total unique users)
Failed Rate: (Total failed attempts) / (Total successful completions)

Calculation Rules & Limitations:

Displays Top 10 values.
Data is aggregated from Level Report and Level Failed Report.
Includes levels 15+ with mode in ('default', 'single').
Data is calculated over a 7-day period.
- Example: Stats for June 7 are based on data from June 1 to June 7.
DAU per level is calculated using SessionEvent table over 7 days, counting unique users who triggered any event at the selected level.
Only levels with at least 50 unique users are considered.
The Average metric is the mean of all levels meeting the above conditions.

Level Completed Events per DAU

This widget calculates how many levels are completed on average per Daily Active User (DAU). It helps determine whether players are progressing through levels or exiting the game early.