I. The Problem Is Not Bad Data, but Misaligned Measurement Definitions

After each release of a “global AI app revenue ranking,” the discussion almost always converges to the same conclusion: the top products are strong. That conclusion is correct, but it contains almost no analytical information. The more valuable material lies in seemingly contradictory combinations of numbers on the same ranking:

• App A has about 3.28 million monthly active users and about $18.01 million in in-app purchase revenue, equivalent to roughly $5.5 per MAU per month.
• App B had about 9.5 million downloads in a single month, while monthly active users climbed to about 12.37 million.
• App C had nearly 10 million downloads in a single month, but the in-app purchase revenue detected by the ranking was only about $2,500, equivalent to roughly $2.5 per 10,000 downloads, or about $0.00025 per download.

Note: The ranking figures in this section and the following sections are illustrative examples. Verify the statistical scope and reporting period against the data source you use, and do not treat them directly as competitive financial benchmarks.

If you assume that these apps are simply “in the same business but at different scales,” any horizontal ranking will lead to the wrong conclusion. They are not the same type of product in terms of revenue structure, monetization timing, or payment trigger conditions. To make such rankings analyzable, the first step is to understand the boundaries of their measurement definitions.

1.1 In-App Purchase Revenue Covers Only Part of the Business

The “revenue” in these rankings usually refers to in-app purchase revenue reported by app stores, typically before store revenue share. It does not include:

• Web-based subscriptions or payments collected through independent payment channels;
• Advertising and traffic monetization;
• Hardware, compute packages, or offline services;
• Enterprise contracts, seat purchases, or API and platform usage billing.

This boundary already explains App C above: 10 million downloads and $2,500 in in-app purchase revenue do not mean the product has no revenue. They mean its monetization path bypasses store settlement entirely. This is especially common in AI tools designed for specific work scenarios, because enterprise or team purchases often go through web contracts and invoicing processes.

1.2 Channel Coverage Is Incomplete, So Cross-Market Comparisons Can Be Misleading

Most public rankings cover only two major app stores and do not include third-party Android stores, especially those common in mainland China. This creates two problems:

• Products whose main distribution channel is a third-party Android store may be systematically underestimated or entirely missing.
• Comparing “products built by teams in China” with “overseas products” within the same ranking can mix different measurement sources, making the numerator and denominator inconsistent. The resulting conclusion is not reliable.

1.3 Three Technical Biases That Are Easy to Miss

• Reporting periods may have different numbers of days (28, 30, or 31 days). Comparing total revenue directly across periods can create false growth.
• Non-U.S. dollar markets require currency conversion, which introduces exchange-rate error. A weak currency may directly show up as “revenue decline.”
• Different data sources may handle refunds, chargebacks, sandbox test transactions, and trial conversions differently. If these items are not uniformly excluded, data during feature ramp-up periods may be significantly overstated.

Conclusion: These rankings are useful for observing trends and order of magnitude, but they are not suitable as the sole basis for competitive financial benchmarking. Reliable judgment should come from a first-party measurement system.

II. Use Concentration to Understand the Existing Base, and Use Trends to Understand Incremental Change

How Should AI App Revenue Rankings Be Analyzed with HHI?

Head concentration is normal. In a given reporting month, the combined in-app purchase revenue of the top 100 apps may be about $793 million, with the top three taking 78.9% and the top ten taking 87.5%. These are example figures for a single calendar month and should be verified against the actual data source.

This type of structure is best described with two metrics: cumulative Top N share and the Herfindahl-Hirschman Index (HHI).

-- Concentration: Top N cumulative share and HHI
-- Example engines: Postgres / ClickHouse / BigQuery, with minor dialect differences
-- Parameterize :month to the target reporting month; adjust :days if the period length changes
WITH app_rev AS (
    SELECT app_id, SUM(iap_amount_usd) AS revenue
    FROM app_iap_daily
    WHERE month = :month                 -- e.g., DATE '2026-10-01'
      AND is_sandbox = FALSE             -- exclude sandbox/test transactions
    GROUP BY app_id
),
s AS (
    SELECT app_id, revenue,
           revenue / SUM(revenue) OVER ()          AS share,
           ROW_NUMBER() OVER (ORDER BY revenue DESC) AS rk
    FROM app_rev
)
SELECT SUM(share * share)                      AS hhi,
       SUM(CASE WHEN rk <= 3   THEN share END)  AS top3_share,
       SUM(CASE WHEN rk <= 10  THEN share END)  AS top10_share,
       SUM(CASE WHEN rk <= 100 THEN share END)  AS top100_share
FROM s;

HHI is the sum of the squared shares of all participants. It ranges from 0 to 1 and places more weight on large players. Compared with looking at Top 1 share alone, it better answers one question: Is this market dominated by one company, or is it a two-player competition?

When HHI remains at a very high level while the Top 1 share slowly declines, it usually means that second-tier products are taking incremental revenue from the same pool, rather than new entrants appearing in the market.

Why Is Sequential Growth Rate Not the Same as Incremental Contribution?

Stock share answers where the money is. Incremental share answers where the money is moving. Comparing the same reporting month with the previous month, the ranking’s overall month-over-month revenue increase may be about $94.86 million, with the top two apps contributing about $60.88 million and $17.45 million respectively, together accounting for about 82.6% of the increase. These are example figures and should be verified.

The following SQL uses conditional aggregation to align the full population. It keeps both newly added revenue in the current month and products that had revenue in the previous month but dropped to zero in the current month. This avoids missing negative increment and distorting the denominator.

-- Increment attribution: full alignment between current month and previous month, keeping churned apps
WITH monthly AS (
    SELECT month, app_id, SUM(iap_amount_usd) AS revenue
    FROM app_iap_daily
    WHERE month >= :prev_month            -- e.g., DATE '2026-09-01'
      AND is_sandbox = FALSE
    GROUP BY month, app_id
),
pivot AS (
    SELECT app_id,
           SUM(CASE WHEN month = :cur_month  THEN revenue ELSE 0 END) AS cur_rev,
           SUM(CASE WHEN month = :prev_month THEN revenue ELSE 0 END) AS prev_rev
    FROM monthly
    GROUP BY app_id                          -- keep every app that appears in either month
),
delta AS (
    SELECT app_id, cur_rev,
           cur_rev - prev_rev AS revenue_delta
    FROM pivot
)
SELECT app_id,
       cur_rev,
       ROUND(cur_rev      / NULLIF(SUM(cur_rev) OVER (), 0), 4)        AS stock_share,
       revenue_delta,
       ROUND(revenue_delta / NULLIF(SUM(revenue_delta) OVER (), 0), 4) AS delta_share
FROM delta
ORDER BY revenue_delta DESC;

When using this result, pay attention to the base effect. A product with over a billion monthly active users can contribute most of the increment with only a single-digit percentage growth rate, while a product with a very small base can double its revenue and still be almost invisible on the ranking.

It is therefore recommended to output three columns together: stock share, incremental share, and sequential growth rate. When these three diverge, that is often the most important signal.

III. Decompose Revenue into Attributable Factors

Any app-store in-app purchase revenue can be approximated as:

Revenue ≈ MAU × Paid Conversion Rate × ARPPU

Here, ARPPU is uniformly defined as average revenue per paying user, calculated as revenue divided by the number of paying users. It can be further decomposed into average number of purchases per paying user multiplied by average transaction value.

This identity is the standard tool for evaluating “contradictory data.” Returning to the three examples from the first section:

• App A: MAU is 3.28 million, and monthly revenue is $18.01 million. If the paid conversion rate is 5%, the number of paying users is about 164,000, and ARPPU is about $110 per month. This suggests that its main offerings are high-priced annual plans or professional-tier subscriptions. For this type of product, the growth engine is retention and renewal, not acquisition. The number of new users is not the key metric.

• App B: Downloads are 9.5 million and MAU is 12.37 million. MAU being higher than current-month downloads indicates that users from the previous month and earlier are still active. However, the large download volume also suggests that a high proportion of users may still be newly acquired, so retention has not yet been validated. Whether it can monetize should be judged by the paid conversion curve over the next two to three months, not by current-month revenue.

• App C: In-app purchase revenue is about $2.5 per 10,000 downloads, close to a purely free or entry-level product. Evaluating it with in-app purchase revenue alone would be seriously misleading. Different metrics are required: average daily usage time per user, average daily calls per user, day-one and day-30 retention, and inference cost per active user.

# Factor decomposition: identify whether growth comes from acquisition, conversion, or unit price
# Convention: ARPPU = average revenue per paying user = revenue / paying_users
# Identity: revenue ≈ MAU × paid conversion rate × ARPPU
def decompose_revenue(cur, prev):
    def parts(d):
        mau, paying, rev, cnt = d["mau"], d["paying_users"], d["revenue"], d["pay_count"]
        return {
            "mau":        mau,
            "pay_rate":   paying / mau   if mau   else 0.0,   # paid conversion rate
            "arppu":      rev / paying   if paying else 0.0,   # average revenue per paying user
            "pay_freq":   cnt / paying   if paying else 0.0,   # purchases per paying user
            "unit_price": rev / cnt      if cnt   else 0.0,    # average transaction value
        }
    c, p = parts(cur), parts(prev)
    def growth(key):
        return (c[key] / p[key] - 1) if p.get(key) else None
    return {
        "mau_growth":      growth("mau"),
        "pay_rate_growth": growth("pay_rate"),
        "arppu_growth":    growth("arppu"),
    }

The three growth rates multiplied together approximately equal the revenue growth rate. On a logarithmic scale, they can be added precisely. Whichever factor has the largest growth contribution is where the product team should focus investment.

IV. Four Monetization Models, Four Sets of Core Metrics

Putting different monetization models into the same revenue ranking is a major source of misjudgment. A more practical approach is to classify products by monetization path first, then use a dedicated set of metrics for each category.

• Subscription productivity tools: Focus on paid conversion rate, monthly churn, net revenue retention (NRR), and ARPPU. Revenue is strongly coupled with active scale, and the ceiling is determined by retention.

• Entry-occupancy products: Acquire scale through free or very low-cost offers, then monetize through ecosystems, value-added services, or synergy with the core business. In-app purchase revenue is naturally very low. Look instead at DAU/MAU stickiness, day-one retention, average calls per user, and acquisition cost per active user.

• Relationship or companion products: Focus on average daily usage time, number of conversation turns, day-one and day-seven retention, and renewal rate. Revenue is delayed and highly sensitive to churn. A single model experience fluctuation can show up in the revenue curve within two to three weeks.

• Workflow-embedded products: Used deeply for specific tasks, often billed by seat or usage. Revenue often occurs on the web or through enterprise settlement and does not enter the in-app purchase scope. Look at task completion rate, team adoption seat ratio, account-level usage expansion or seat expansion, and weekly active seat retention.

V. Build a First-Party Measurement System: From Event Tracking to Monitoring

5.1 Design the Event Model Correctly the First Time

The root cause of measurement-definition problems is often found at the event tracking stage. Purchase and refund events should include at least an idempotency key, dual timestamps, platform and settlement source, amount in the smallest currency unit, product and billing type, and refund linkage.

{
  "event_id": "01J9Z3K7QW8M2X4T6B1C0D9EFG",
  "event_name": "purchase_success",
  "occurred_at": "2026-10-12T08:31:05Z",
  "ingested_at":  "2026-10-12T08:31:07Z",
  "app_id": "app_001",
  "platform": "ios",
  "settle_channel": "store_iap",
  "geo": "US",
  "currency": "USD",
  "amount_minor": 1999,
  "product_id": "sub_pro_monthly",
  "billing_type": "subscription",
  "is_sandbox": false,
  "refund_of": null
}

{
  "event_id": "01J9Z3K7QW8M2X4T6B1C0D9EFH",
  "event_name": "refund_success",
  "occurred_at": "2026-10-20T11:02:33Z",
  "ingested_at":  "2026-10-20T11:02:35Z",
  "app_id": "app_001",
  "platform": "ios",
  "settle_channel": "store_iap",
  "geo": "US",
  "currency": "USD",
  "refunded_amount_minor": 1999,
  "refund_of": "01J9Z3K7QW8M2X4T6B1C0D9EFG",
  "refund_reason": "user_request"
}

Several engineering conventions are worth writing into the specification:

• Use event_id for deduplication and idempotency to avoid revenue overstatement caused by client retries.
• Store amounts in the smallest currency unit and convert them only at the presentation layer to avoid floating-point errors.
• Distinguish occurred_at from ingested_at to identify clock skew and late-arriving events.
• Treat refunds as separate events and write back refund_of. Revenue statistics should uniformly use net revenue.
• Version the event-tracking schema together with metric definitions so that historical data can be traced and recalculated when definitions change.

5.2 Layered Modeling and Anomaly Detection

The data pipeline can be layered as collection, buffering, detail, aggregation, and alerting:

• Client-side SDKs collect events.
• A message queue smooths traffic and decouples upstream and downstream systems.
• The detail layer stores raw archives in object storage.
• The aggregation layer generates atomic metrics such as MAU, paying users, and revenue.
• The metric layer combines these into paid conversion rate, ARPPU, and NRR.

These are common cloud data capabilities. Major cloud providers offer object storage, message queues, container platforms, logging services, and monitoring and alerting tools that can support building and operating this type of pipeline.

The monitoring system should cover at least four types of anomalies:

• Revenue month-over-month changes exceeding a threshold.
• Paid conversion rate and ARPPU moving in opposite directions, which often occurs after price changes or campaign endings.
• Data gaps caused by delayed revenue reporting from app stores.
• A sudden increase in the revenue share of a single channel, which may indicate traffic fraud or settlement anomalies.

Turning these rules into alerts is far more useful than reviewing the ranking after the fact.

VI. Common Misreadings of AI App Revenue Rankings

1. Reporting only total revenue without paid conversion rate and ARPPU makes it impossible to distinguish “selling expensive” from “selling at scale.”
2. Failing to exclude refunds, sandbox transactions, and trial conversions inflates data during campaign periods.
3. Directly comparing across markets while ignoring incomplete ranking channel coverage.
4. Using sequential growth rate instead of incremental contribution, which overestimates products with a small base.
5. Directly subtracting reporting periods with different numbers of days.
6. Using in-app purchase revenue to evaluate products that mainly rely on enterprise settlement or web subscriptions.
7. Treating downloads as user assets. When the MAU-to-download ratio is imbalanced, retention has not yet been validated.
8. Looking only at a single-month snapshot instead of tracking cohort retention over three to six months.

VII. Practical Guidance: Define Measurement First, Then Interpret the Ranking

1. Define measurement scope: Unify atomic metrics and dimension dictionaries, clarify definitions such as ARPPU, and standardize net revenue and currency rules.

2. Cross-check two sources: Compare store data with first-party event tracking. Set a difference threshold, such as triggering an investigation when monthly revenue differs by more than 3%, and keep records.

3. Use a monthly three-column report: Place stock share, incremental share, and growth rate side by side. If the three diverge, treat it as an early warning.

4. Position the product: Use the four monetization models in Section IV to position your own product, then decide which competitor metrics to follow.

5. Downgrade external rankings: Treat external rankings as a cross-validation input rather than the source of conclusions.

At this point, the quality of judgment will be noticeably different. The data is still the same ranking, but you now have a ruler that is reproducible, attributable, and monitorable.