Game Economy Daily and Cohort Report

Overview

Game Economy Reports are designed to analyze user progression and the utilization of in-game currency. These reports provide insights into the leveling process and user interactions with the in-game economy, helping you optimize engagement and monetization strategies.

Game Economy Daily

Daily Report Objective

The primary goal of this report is to assess overall audience progress and analyze the usage of in-game currency over time or across different application versions. This helps identify user behavior patterns, enabling data-driven adjustments to game design and monetization strategies.

Data

The report aggregates session and transaction data collected from the SDK on a daily basis. It also accounts for offline users, adjusting data over a week-long period to ensure accuracy.

Game Economy Cohort

The primary goal of this report is to evaluate the progress of specific user cohorts and analyze the usage of in-game currency in relation to the User Acquisition (UA) process. This helps you understand audience dynamics and make data-driven adjustments to your game design or UA strategy.

Data

This is a cohort-based report, meaning it aggregates data over a 35-day period for each user, starting from their app installation date.

Installation data is sourced from AppsFlyer or Adjust.
Session and transaction data is collected from the SDK.

Data Sources

Both reports leverage two key SDK data models:

SessionEvent Model – Tracks event data during user sessions.
Transaction Model – Captures data related to booster usage and in-game currency transactions.

Additionally, the Cohort Report incorporates installation data from AppsFlyer or Adjust.

By combining these data sources, the reports complement each other, providing a comprehensive view of user behavior, progression, and in-game currency usage both for the entire audience and within specific cohorts.

Cohort Definition

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

A specific action performed (e.g., app installation, level completion, in-game currency purchase).
The time period in which this action occurred.

Difference Between a Cohort and a Segment

A cohort differs from a segment in that a segment represents a broader and more general dataset. For example:

Players who installed the app in January 2023 and players who installed the app in February 2023 are two different cohorts since they are grouped by installation date. However, both groups belong to the general segment of active players in 2023.

Cohort Analysis

Cohort analysis is a research method in which users are divided into groups (cohorts) based on shared characteristics. Their behavior is then analyzed over a specific period.

This approach enables you to:

Track player actions over time (e.g., level progression or engagement).
Identify behavioral trends associated with different cohorts.
Conduct precise data analysis to optimize game mechanics, retention, and monetization.

Logic of Metric Display in the Report

The report is generated based on two categories of metrics: some metrics are related to game events (events), while others are exclusively tied to transactions. The system automatically switches between these categories depending on the selected dimension or metric.

Automatic Switching Mechanism

The switching mechanism follows the "at least one" principle. This means that if at least one filter or dimension is selected in the report and certain metrics are unavailable for it, those metrics will be hidden. Even if other filters or dimensions allow for the use of all metrics, the unavailable ones will not be displayed.

Example 1: Filtering by In-Game Currency Source

When analyzing transactions, the SDK transmits data about the Boosters Source, indicating the source of the in-game currency associated with a specific transaction. However, for game events (such as level start or completion), it is impossible to determine which in-game currency source was used.

Therefore, when applying a filter/dimension by in-game currency source, only 6 metrics related to in-game currency movement will be available. The remaining 8 metrics, associated with level start and successful/unsuccessful completion events, will be hidden.

Example 2: Filtering by Game Level

If a filter/dimension by game level is applied, all metrics remain available. This is because it is possible to accurately determine at which level a specific booster was received and which level the player started or completed.

For more details on metric availability, refer to the help section below.

Availability of Metrics and Dimensions by Category

The availability of metrics and dimensions depends on the data model used. The report includes two types of models:

SessionEvent (SE) – related to in-game events such as level starts and completions.
Transaction (T) – related to in-game currency transactions.

The table below outlines which metrics and dimensions are available for each model:

Filters and Dimensions

The table below provides a detailed breakdown of the dimensions and filters available in the reporting system, including their names, descriptions, additional notes, and availability across reports.

Metric	Description	Notes	Report
Application	The name of the application	Only one application can be selected as bonuses cannot be summed across multiple apps.	Both
App Version	The version of the application	Multiple versions can be selected; bonuses across versions can be summed.	Both
App Init Version	Initialization version of the app	The initial version of the application. Multiple versions can be selected, and bonuses across versions can be summed.	Both
Day	The date of the event	Allows selection of a date range. Users can choose a single day or a range of up to 120 days.	Daily
Week	The week of the event	Enables comparison between different weeks in the table.	Daily
Month	The month of the event	Enables comparison between different months in the table.	Daily
Day of Install	The calendar date when the user installed the application.	Allows selection of a date range. Users can choose a single day or a range of up to 120 days.	Cohort
Week of Install	The calendar week when the user installed the application.	Enables comparison between different weeks in the table.	Cohort
Month of Install	The calendar month when the user installed the application.	Enables comparison between different months in the table.	Cohort
Cohort Day	The number of days between the user's installation date and the recorded event.	Allows selection of a range of days. Minimum value in the filter is 0.	Cohort
Media Source	The source of traffic that attributed the user acquisition.	Multiple sources can be selected; bonuses across sources can be summed.	Cohort
Country	The country of the user.	Multiple countries can be selected; bonuses across countries can be summed.	Both
Level	The game level.	Allows selection of a level range. Minimum value in the filter is 1.	Both
Mode	The specific game mode.	Multiple modes can be selected; bonuses across modes can be summed.	Both
Product ID	The identifier of the product ID.	Multiple products can be selected; bonuses across products can be summed.	Both
In-App Status	The user's payment status, indicating whether they have made a purchase. Possible values: free, paying, or unknown.	Multiple statuses can be selected; bonuses for players in different statuses can be summed.	Both
Subscription Status	The user's current subscription status. Possible values: free, paid, paid canceled, trial, or trial canceled.	Multiple statuses can be selected; bonuses for players in different statuses can be summed.	Both
Boosters Type	The category or classification of an in-game booster used by the player.	Multiple booster types can be selected; bonuses across booster types can be summed.	Both
Boosters Source	The category or classification of an in-game booster used by the player.	Multiple booster sources can be selected; bonuses across sources can be summed.	Both

Interaction Between "Day/Week/Month of Install" and "Cohort Day" Filters

The "Day/Week/Month of Install" filter determines when users installed the application, while the "Cohort Day" filter aligns the corresponding time periods within the dataset. Here’s how these filters work together:

If you select a cohort, for example, from December 1 to December 3, and do not apply any values in the "Cohort Day" filter, the report will display cumulative data collected from the installation date onward for the next 35 days.
However, if you set the "Cohort Day" filter to a specific value (e.g., 1), the report will show data only for the day following the installation (installation day = 0, subsequent days = 1, 2, 3, etc.).

For instance:

On December 2, data will be displayed for users who installed the app on December 1.
On December 3, data will be displayed for users who installed the app on December 2.
On December 4, data will be displayed for users who installed the app on December 3.

Filters "In-App Status" and "Subscription Status"

The values in these filters represent the user’s dynamic state as reported by the SDK. It is important to understand their behavior:

"In-App Status": For example, selecting "Paying" in this filter will not display data for users who simply made an in-app purchase. Instead, it will display data for users after they made a purchase.
"Subscription Status": Similarly, selecting a status will reflect data for users while they are in the specified subscription state.

These filters provide a nuanced view of user behavior, enabling targeted analysis based on specific conditions or states within the application.

Metrics

To ensure accurate data collection and display in this report, the SDK must be properly configured to transmit data to the SessionEvent and Transaction models. This configuration is implemented during the SDK integration process.

It is important to note that we cannot account for all possible variations in event naming conventions used by developers. Therefore, we rely on a set of standard event code names for identifying events. Detailed information is provided in the commentary column for reference.

Metric	Description	Commentary
Receive Boosters	The number of boosters received by players	Sum of bonuses where the transaction type is "receive" (received).
Spend Boosters	The number of boosters spent by players	Sum of bonuses where the transaction type is "spend" (spent).
Boosters Balance	The number of remaining boosters	The difference between Receive Bonus and Spend Bonus.
Booster Surplus	The surplus of accumulated boosters	Calculated as Receive Bonus / Spend Bonus, displayed as a percentage rounded to the nearest whole number.
Receive Boosters % of Total	The percentage of "Receive Boosters" in the total row	In the total row, always equals 100%. In the dropdown, the percentage is distributed according to the total percentage at the top.
Spend Boosters % of Total	The percentage of "Spend Boosters" in the total row	In the total row, always equals 100%. In the dropdown, the percentage is distributed according to the total percentage at the top.
Levels Started	The number of events where the name matches or contains "level start" or similar	Event names may vary in format, including underscores, lowercase, uppercase, or prefixes/suffixes (e.g., "stle_level_started_12345"). This metric is unavailable when broken down by bonus type, its source, or product, as these are unrelated indicators.
Level Failed	The number of events where the name matches or contains "level failed"	Event names may vary in format, including underscores, lowercase, uppercase, or prefixes/suffixes (e.g., "stle_level_failed_12345"). This metric is unavailable when broken down by bonus type, its source, or product, as these are unrelated indicators.
Level Completed	The number of events where the name matches or contains "level completed"	Event names may vary in format, including underscores, lowercase, uppercase, or prefixes/suffixes (e.g., "stle_level_completed_12345"). This metric is unavailable when broken down by bonus type, its source, or product, as these are unrelated indicators.
Fill Rate	How successfully players progress through levels	Calculated as the ratio of Level Completed to Level Failed.
Spend Boosters per Level Failed	The average number of boosters spent per failed level attempt	Calculated as the ratio of Spend Bonus to Level Failed.
Spend Boosters per Level Completed	The average number of boosters spent per successfully completed level	Calculated as the ratio of Spend Bonus to Level Completed.

Game Economy Daily and Cohort Report

Overview