Overview

The Revenue type cohorts report is a powerful tool for teams looking to dive deeper into how different monetization models impact user behavior and revenue. While it’s built with flexibility in mind, a bit of familiarity with cohort analysis and monetization logic will help you get the most value out of it.

This report gives you full control over how metrics are calculated and displayed, so you can tailor insights to fit your specific analytical goals.

Key Usage Guidelines

• Mandatory Monetization Model Selection Users must select a specific monetization model for metric calculation. For detailed guidance on model selection and how it impacts calculations, refer to: Revenue Type Cohorts | Monetization Model Selection
• Revenue Metrics Representation All monetary values are displayed in USD, calculated net of platform fees, regional markups, and refunds. However, each metric may have its own specific data treatment rules. For full definitions and logic behind each metric, refer to: Revenue Type Cohorts | Metric Definitions
• Understanding Paying Users For accurate interpretation of metrics, it’s important to understand how paying users are identified within this report. Details are available here: Revenue Type Cohorts | Paying User Inclusion Logic

Metric Definitions

This section provides definitions for each metric included in the Revenue Type Cohorts report. It explains the general logic behind each metric, how it is calculated, and any important considerations. Specific details related to monetization models are covered in separate sections.

Cohort Size

Cohort Size represents the total number of users who installed the application during the date range selected in the Date filter. Install data is sourced from Adjust or AppsFlyer.

If no MMP is connected, install data is estimated using Magify’s internal AppLaunch model based on SDK signals. In this case:

• The first tracked app launch is considered the install date.
• If a user does not launch the app for 90 days, the next launch is treated as a re-attribution (i.e., a new install).
• All installs tracked this way are considered organic.

Paying Users: PU0, PU4, PU7, PU14, etc.

Paying Users (PU) indicates the number of users within the cohort who made at least one purchase within a specific number of days since installing the app.

• PU0 – Number of users who made a purchase on the same day they installed the app.
• PU4 – Number of users who made a purchase within the first 4 days post-install.
• PU7, PU14, etc. follow the same logic with longer windows.

However, this may not hold true in some scenarios — for instance, if a significant number of users request refunds after making purchases (e.g., subscription issues or billing errors). Such cases can be identified by monitoring the Refund Number metric.

TARPPU0, TARPPU4, TARPPU7, TARPPU14, etc.

TARPPU (Total Average Revenue Per Paying User) represents the average revenue generated by paying users within a cohort over a specific number of days after app installation. It is calculated as the total revenue from all paying users divided by the number of unique users who made a purchase in the given period:

Why TARPPU Usually Increases

In real-world scenarios, TARPPU typically increases over time because:

• Purchase values among users tend to be stable or increase on average.
• Users who make a purchase often continue generating ad revenue, which contributes to overall revenue and offsets low-value purchases by others.

Relation to IARPPU and AdARPPU

TARPPU is the sum of two separate metrics:

• IARPPU — Average revenue from in-app purchases per paying user.
• AdARPPU — Average revenue from ads per paying user.

All three metrics share the same denominator (PU), and the TARPPU numerator is the sum of revenues from purchases and ads. Minor rounding differences may occur.

Deriving Total Revenue from Paying Users

Although the total revenue from paying users is not shown directly in the report, it can be calculated using:

Again, rounding may result in slight variations.

TARPU0, TARPU4, TARPU7, TARPU14, etc.

TARPU (Total Average Revenue Per User) represents the average revenue generated by all users in a cohort, regardless of whether they made a purchase. It is calculated by dividing the total revenue generated by the cohort by the total number of users in that cohort (Cohort Size):

Unlike TARPPU, which includes only paying users, TARPU accounts for all users, making it a more general indicator of monetization performance across an entire cohort.

How It's Calculated

• TARPU0 — Total revenue generated by the cohort on Day 0 (day of install) divided by the cohort size.
• TARPU4 — Total revenue generated by the cohort in the first 4 days after install, divided by the original cohort size.

Why TARPU Tends to Increase

Unlike TARPPU, TARPU tends to grow over time for mathematical reasons:

• The denominator (cohort size) remains constant.
• The numerator (total cohort revenue) increases cumulatively as users continue to generate revenue.
• Refunds may reduce revenue slightly but typically have minimal impact compared to ongoing ad or in-app revenue growth.

Deriving Total Cohort Revenue

Although total cohort revenue is not explicitly shown in the report, it can be derived from the TARPU value:

Minor rounding differences may occur depending on precision settings.

IARPPU0, IARPPU4, IARPPU7, IARPPU14, etc.

IARPPU (In-App Average Revenue Per Paying User) represents the average revenue from in-app purchases (including subscriptions) generated by paying users in a cohort. It is calculated by dividing the total in-app revenue by the number of paying users (PU):

This metric excludes ad revenue and focuses solely on monetization through in-app transactions. Subscriptions are treated as part of in-app revenue.

How It's Calculated

• IARPPU0 — In-app revenue on Day 0 (install day), divided by the number of users who made a purchase that day.
• IARPPU4 — Cumulative in-app revenue over the first 4 days after install, divided by the number of users who made at least one purchase during that time.

Key Characteristics

Like TARPPU, this metric does not inherently increase over time. While total in-app revenue may grow, the addition of new payers with smaller purchase amounts can lower the average. However, in practice, IARPPU often grows over the cohort’s lifetime due to typical user behavior patterns and balanced spending.

Relationship to Other Metrics

IARPPU contributes to the overall TARPPU (Total Average Revenue Per Paying User), together with ad revenue per paying user:

These metrics share the same denominator (PU), and the numerator of TARPPU equals the sum of the numerators of IARPPU and AdARPPU. Minor discrepancies may appear due to rounding.

Deriving In-App Revenue

Total in-app revenue from paying users in a cohort can be calculated using:

As with other calculated values, small rounding errors may occur.

AdARPPU0, AdARPPU4, AdARPPU7, AdARPPU14, etc.

AdARPPU (Advertisement Average Revenue Per Paying User) represents the average advertising revenue generated by paying users in a cohort. It is calculated by dividing the total ad revenue attributed to paying users by the number of paying users (PU):

This metric accounts only for revenue generated from advertisements and excludes in-app purchases.

How It’s Calculated

• AdARPPU0 — Ad revenue generated on the install day, divided by the number of users who made a purchase that day.
• AdARPPU4 — Cumulative ad revenue over the first 4 days post-install, divided by the number of unique users who made at least one purchase during that time.

Key Characteristics

This metric typically increases over the cohort’s lifetime, as paying users continue to generate ad revenue over time. In general:

However, exceptions can occur—for example, when a large number of users make a purchase and later receive a refund (e.g., due to support tickets or payment issues). Such users are excluded from the cohort and, if they had high ad revenue, their removal can lower the metric. This behavior is similar to the effects seen with TARPPU, and anomalies can be investigated by checking the Refund Number metric.

Relationship to Other Metrics

AdARPPU, together with IARPPU, forms the TARPPU value:

All three metrics share the same denominator (PU). The numerators for IARPPU and AdARPPU sum to equal that of TARPPU. Minor discrepancies may occur due to rounding.

Deriving Total Ad Revenue from Paying Users

The total advertising revenue generated by paying users can be calculated using:

As with other calculations, slight differences may appear due to rounding.

%PU0, %PU4, %PU7, %PU14, etc.

%PU (Percentage of Paying Users) represents the percentage of users within a cohort (based on install date) who made at least one in-app purchase within a given number of days post-install.

It is calculated as follows:

• %PU0 – The percentage of users who made a purchase on the same day they installed the app.
• %PU4 – The percentage of users who made a purchase within the first 4 days after installation.

The Cohort Size (number of users who installed the app during the selected date range) is fixed and does not change over time. Therefore, %PU reflects the cumulative growth in the number of paying users within the cohort.

Key Characteristics

This metric typically increases over the cohort’s lifetime, as more users make purchases over time. Thus, it is generally true that:

This is because the denominator (Cohort Size) remains constant, while the number of paying users (PU) generally increases as time progresses.

Exceptions and Edge Cases

There are rare scenarios where this progression may not hold true. For instance, if many users in the cohort made a purchase and later requested a refund (e.g., due to a technical issue or accidental charge), they would be removed from the paying user count (PU), potentially lowering the %PU metric.

These anomalies can be investigated using the Refund Number metric to identify cohorts with a high volume of refunded transactions.

Purch0, Purch4, Purch7, Purch14, etc.

Purchases (Purch) represents the total number of in-app purchases made by users from the selected cohort between the install date and a specified number of days after installation.

This metric includes both standard one-time purchases and subscription renewals. Each renewal is counted as a separate purchase. For example, if a user renews a subscription four weeks in a row, this counts as four purchases.

Metric Interpretation

• Purch0 – Total number of purchases made by cohort users on the day they installed the app.
• Purch4 – Total number of purchases made by the same users during the first 4 days after installation.
• And so on for Purch7, Purch14, etc.

Since the purchase count accumulates over time, the following relationship usually holds:

Exceptions and Edge Cases

In rare cases, the typical metric progression may not apply. For example, if a significant number of users in a cohort made purchases but later requested refunds (e.g., due to technical issues or accidental charges), those users would no longer be counted as paying users (PU). This can lead to an unexpected drop in the %PU metric.

To identify such anomalies, you can use the Refund Number metric, which highlights cohorts with unusually high volumes of refunded transactions.

PPU0, PPU4, PPU7, PPU14, etc.

Purchases per Paying User (PPU) represents the average number of purchases made by each paying user within the cohort, calculated over a defined number of days since app installation.

The formula is:

Where:

• Purch – Total number of purchases made by the cohort within the defined period.
• PU – Number of unique paying users in the cohort during the same period.

Metric Interpretation

• PPU0 – Number of purchases made on the install day divided by the number of users who made purchases that day.
• PPU4 – Total number of purchases during the first 4 days divided by the number of unique users who made those purchases.

Expected Behavior

This metric generally increases over time as cohorts age:

The minimum value is 1, since by definition a paying user must have made at least one purchase.

Related Metrics

PPU is directly linked to IARPPU (In-App Average Revenue per Paying User) and MPP (Mean Purchase Price):

Where:

• MPP (Mean Purchase Price) = Total In-App Revenue / Number of Purchases

This relationship reflects that the in-app revenue per paying user is a product of the number of purchases per paying user and the average value of each purchase.

MPP0, MPP4, MPP7, MPP14, etc.

Mean Purchase Price (MPP) represents the average value of a single in-app purchase made by users in a given cohort during a specified period.

The formula is:

Where:

• Inapp_PU_Revenue – Total revenue from in-app purchases (including subscriptions) made by the cohort during the selected period.
• Purch – Total number of purchases made during that period.

Metric Interpretation

• MPP0 – In-app revenue from purchases made on the installation day, divided by the number of purchases made on that day.
• MPP4 – In-app revenue from purchases made in the first 4 days after installation, divided by the total number of purchases during those 4 days.

Expected Behavior

This metric does not necessarily increase over time but tends to do so in most practical cases:

The minimum possible value is determined by the cheapest available product in the store, which defines the lower bound of this metric.

Related Metrics

MPP is directly tied to IARPPU (In-App Average Revenue per Paying User) and PPU (Purchases per Paying User):

This relationship holds mathematically:

Max Ind Purch Rev

Maximal Individual Purchase Revenue (Max Ind Purch Rev) represents the highest total in-app purchase revenue generated by a single user within the selected cohort. This metric helps identify whether the cohort includes a user with an unusually high purchase amount, which may indicate outlier behavior or heavy spender patterns.

Calculation Logic

For each unique user in the cohort:

• The total revenue from all in-app purchases (including subscriptions) is calculated starting from the app installation date and up to a maximum of 150 days.
• The system then determines the maximum of these user-level revenue totals.

Use Case

This metric is especially useful for:

• Detecting outlier spenders within a cohort.
• Comparing the highest user spend to the Mean Purchase Price (MPP) of the cohort to assess the impact of individual users on total revenue.

A large gap between Max Ind Purch Rev and the cohort’s average purchase values may suggest the presence of high-value customers or unusual purchasing behavior.

Refunds

Refund Number refers to the total number of in-app purchase refunds issued within the selected cohort. This metric captures the count of transactions where users received a monetary reimbursement.

A common scenario for refunds includes users who contact the app store's support due to bugs, unintentional purchases, or billing errors.

Refund Revenue represents the total amount of revenue lost due to these refunded transactions. This value reflects the financial impact of refunds on the cohort’s overall profitability.

These metrics are important for evaluating the net revenue and identifying potential issues in the purchase flow that may be causing users to request refunds.

Ind Purch Rev > $5/$10/$15 or from $0/$5/$20 to $5/$20/$50

Individual Purchase Revenue (Ind Purch Rev) > $5/$10/$15 or within $0/$5/$20 to $5/$20/$50 — this metric represents the number of users in the cohort whose cumulative in-app purchase revenue exceeds a given threshold ($5, $10, or $15), or falls within specific revenue intervals (e.g., from $0 to $5, $5 to $20, or $20 to $50).

How it's calculated: For each unique user, the total value of in-app purchases is accumulated starting from the app install date, over a maximum period of 150 days. Once all users' cumulative purchase values are calculated, the system determines how many users meet either of the following conditions:

• Their total purchase revenue exceeds $5, $10, or $15
• Their total purchase revenue falls within one of the specified intervals:
  • $0 to $5
  • $5 to $20
  • $20 to $50

This metric helps identify user segments by their total lifetime spend, providing insight into monetization tiers and high-value user behavior.

Monetization Model Selection

The Revenue Type Cohorts report requires the selection of a monetization model to calculate and display data. The chosen model directly affects how all core metrics are computed and interpreted.

This article outlines the unique characteristics of each available monetization model. For general metric definitions and behavior, please refer to the Metric Descriptions section.

Inapp Monetization

This model includes only users who made in-app purchases, based on data from RevenueCat or Magify’s internal validator. Revenue from subscriptions and ad impressions is not included.

Model-specific behaviors:

• Only users who purchased in-app products are counted as paying users (PU).
• Revenue includes only in-app purchases. If a user bought both a subscription and an in-app, only the in-app value is counted.
• Ad revenue is excluded from all calculations.
• As a result:
  • TARPPU = IARPPU
  • AdARPPU = 0
  • TARPU may be very low due to the exclusion of ads.
• If a user made both a subscription and an in-app purchase, only one purchase is counted.
• Refunds are not included (since they are generally related to subscriptions).

Subscription Monetization

This model is structurally similar to the In-App Purchases Only model but focuses exclusively on subscriptions.

Model-specific behaviors:

• Only users who purchased a subscription are counted as paying users.
• Revenue includes only subscription income. In-app purchases are excluded.
• Ad revenue is excluded.
• As a result:
  • TARPPU = IARPPU
  • AdARPPU = 0
  • TARPU may be very low due to the exclusion of ads.
• If a user bought both a subscription and an in-app, only one purchase is counted.
• Each subscription renewal counts as an additional purchase (e.g., 4 renewals = 4 purchases).
• Refunds are included, as they are common in subscription-based monetization.

Subscription & Inapp Monetization

This hybrid model includes all users who made any purchase, whether subscription or in-app.

Model-specific behaviors:

• All paying users are included (subscription and in-app).
• Revenue includes all purchase types.
• Ad revenue is excluded.
• As a result:
  • TARPPU = IARPPU
  • AdARPPU = 0
• TARPU may appear low due to lack of ad data.
• If a user purchased both subscription and in-app, both purchases are counted.
• Renewals are treated as additional purchases.
• Refunds are included.

Ad Monetization

This model excludes all purchases and focuses entirely on ad revenue, considering all users regardless of purchasing behavior.

Model-specific behaviors:

• Purchases are not tracked; therefore, PU = 0.
• All per-paying-user metrics (TARPPU, IARPPU, AdARPPU) = 0.
• TARPU is the only meaningful metric available.
• Provides insight into ad-driven monetization performance.

In-App Purchases & Ad Monetization

This model includes only in-app purchasers, but their ad revenue is also counted.

Model-specific behaviors:

• Only in-app purchasers are counted as PUs.
• Purchase revenue includes only in-apps.
• Ad revenue is included for those users.
• As a result:
  • TARPPU = IARPPU + AdARPPU
• If a user also bought a subscription, only one purchase is counted (in-app).
• Refunds are not included, as they pertain mostly to subscriptions.

Subscriptions & Ad Monetization

This model includes only subscription purchasers, and their ad revenue is also counted.

Model-specific behaviors:

• Only subscription purchasers are counted as PUs.
• Purchase revenue includes only subscriptions.
• Ad revenue is included for those users.
• As a result:
  • TARPPU = IARPPU + AdARPPU
• If a user also made an in-app purchase, only one purchase is counted (subscription).
• Renewals are counted as separate purchases.
• Refunds are included.

All Monetization Models

This model includes all monetization sources — subscriptions, in-app purchases, and ad revenue — and is recommended for comprehensive financial performance tracking.

Model-specific behaviors:

• All paying users are included (subscriptions and in-apps).
• Revenue includes all purchases and ad revenue.
• As a result:
  • TARPPU = IARPPU + AdARPPU
• If a user made both types of purchases, both are counted.
• Renewals are counted as additional purchases.
• Refunds are included.

Each model should be chosen based on the specific analysis goal and the available monetization sources for the application. Accurate interpretation of report metrics depends on the proper selection of the monetization model.

Paying User Inclusion Logic

General ARPPU Calculation

In general terms:

• Users refers to individuals who have made at least one purchase (either an in-app or subscription). If a user requests and receives a full refund for a subscription, they are removed from the paying user cohort on the day the refund is processed.
• Revenue is calculated in USD, net of store commissions, regional markups, and currency exchange rates, and falls into three categories:
  • IARPPU – In-app and subscription revenue only
  • AdARPPU – Ad revenue from paying users only
  • TARPPU – Total revenue from both purchases and ads (paid user cohort only)

How ARPPU Is Calculated

Calculations are based on a combination of:

• Purchase data from RevenueCat or Magify’s internal validator
• Install data from Adjust or AppsFlyer

Example: Standard ARPPU Calculation

Suppose a user installs the app on March 1. They activate a free trial on March 2, purchase a $5 subscription on March 3, and renew it with another $5 payment on March 10.

If this user is the only one in the cohort, ARPPU would be calculated as follows:

Example: Refund Scenario

If the same user refunds the second payment on March 16, calculations change:

If the first payment is refunded instead (on March 6), and not the second:

ARPPU for Ad Revenue

Ad revenue is tracked separately and included only if the user is considered a paying user.

Assume the user above views $1 worth of ads daily, and purchases are the same as in the original scenario (March 3 and 10):

If the user loses paying user status (e.g., refund on March 6), all accumulated ad revenue is removed:

A/B Test ARPPU Specifics

In standard ARPPU calculations, the cohort is defined by install date. In A/B test reports, the cohort is defined by the date the user enters the test group — and all prior revenue is excluded.

Otherwise, ARPPU values may underrepresent user behavior due to missing historical revenue data.

Cohort Lifetime Considerations

Metrics in the Revenue Type Cohorts report are calculated with respect to each user’s install date and how long they have remained active in the app. There are three main types of metrics based on how cohort lifetime is considered:

1. Metrics Based on the Cohort Formation Date

This applies to metrics like Cohort Size.

• The Cohort Size is calculated once — on the user’s install date — and remains fixed thereafter.
• It includes all users who installed the app within the selected date range (based on Adjust, AppsFlyer, or Magify AppLaunch if no MMP is connected).

2. Metrics Based on a Specific Day in the Cohort’s Lifecycle

This applies to most metrics in the report, such as ARPPU7, PU4, IARPPU14, etc.

• For each metric, only users who have reached the specified day in their lifecycle are included in the calculation.
• Example: To calculate ARPPU7, users must have been installed at least 7 days ago.

Let’s say today is the 7th of the month, and we analyze a cohort of users who installed the app on the 1st:

• These users have completed 7 days in the app.
• Therefore, ARPPU7 will be available and calculated based on their data.

Now assume the cohort includes users from both the 1st and 2nd:

• On the 7th, only users from the 1st have reached day 7.
• On the 8th, users from the 2nd also become eligible, and ARPPU7 will include both dates.

3. Metrics Based on the Maximum Available Lifetime

Some metrics, such as:

• Refund Revenue
• Max Individual Purchase Revenue

...are calculated based on the maximum number of days each user has existed in the app, up to the available data window (typically 150 days).

However, use caution when interpreting totals:

• If you select a single day 7 days ago, the report compares users who installed the app on that exact day.
• If you select a week-long range (e.g., 14–7 days ago), users will have different lifespans—some may have 14 days of activity, while others only 7.