AppScoutAppScout.gallery
Back to home

How we estimate downloads & revenue

Short version: we combine two public signals — chart rank and review velocity — and express the result as a range with a confidence label. Point estimates would be dishonest without an SDK panel; ranges with caveats are not.

Expect ~2× error margin on absolute numbers for individual apps. Useful for "is App A bigger than App B" comparisons and category sizing. Less useful as exact claims. Tools that quote 30% accuracy (Sensor Tower, AppTweak) have SDK panels in thousands of apps — we don't.

Signal A — Chart-position decay curve

An app's position on the Top Free / Top Paid / Top Grossing charts maps to a downloads-per-day range, empirically calibrated from published benchmarks (Sensor Tower blog posts, AppFigures research, historical leaks). Our default curve for a category like Productivity looks roughly like:

Rank bandEst. downloads / day
Top 1–1012K – 60K
11–502.5K – 15K
51–100800 – 8K
101–200150 – 1.5K
Outside top 20030 – 400

We use only Top Freerank — Top Paid and Top Grossing describe revenue density, not download volume, so feeding them into a download curve produces misleading numbers. Top rank is taken from the best of US / UK / CA / AU. Categories with different volume dynamics (Finance vs. Photo & Video) get tuned curves.

Sustained-presence adjustment: apps with fewer than 100 ratings orfewer than 7 days of momentum history get their chart-band estimate scaled down by half. These are usually newly-charting apps that briefly hit a high rank but haven't accumulated the typical volume of an app that lives at that rank. Without this, a 3-rating app at #10 would look like a unicorn.

Signal B — Rating-count velocity

Apps accumulate reviews proportionally to downloads. If an app gained 120 reviews in the last 7 days, that's ~17 reviews/day. Multiply by the inverse of category review-rate (e.g., 1 review per 500 downloads = 500× downloads per review) to get downloads/day.

Category-specific review-to-download ratios (low–high):

CategoryReviews : downloads
Productivity1 : 300 – 1000
Finance1 : 500 – 1500
Utilities1 : 500 – 2000
Health & Fitness1 : 200 – 500
Photo & Video1 : 300 – 800
Lifestyle1 : 400 – 1200

Combining the two

We compute both signals and return a range that brackets them. If they broadly agree (within 1.5×) and the app charts in the top 50 and we have 14+ days of momentum history, the estimate gets a high confidence label. Within 2× and 7+ days of history → medium. Anything else → low.

Revenue

Paid apps: downloads × price × 0.7 (Apple takes 30%).

Free with IAP/subscription:downloads × category ARPU × 0.7. We can't tell which free apps actually monetize via IAP from public data, so this number assumes monetization exists. When you see "(IAP-driven)" next to a free app's revenue, that assumption is in play — treat it as an upper bound, not a guarantee.

We do notattempt subscription LTV modelling — the required retention data isn't public.

What we cannot compute

  • Per-country revenue breakdowns (US/UK/CA/AU only, combined)
  • Subscription LTV or churn-adjusted ARPU
  • Ad-network revenue with precision
  • Apps that have never charted and have no review history

Plain-language guarantee

We'll never quote a single number with two decimal places like "$43,247.12/month" — that would be theater. You get a band and a confidence label, with the math behind it documented here. If something looks off for a specific app, the most likely cause is either (a) we don't have enough history yet, or (b) the category multiplier needs tuning. Both improve over time.

Model version: v1.1-2026-05. We publish a new model version when the calibration tables or signal weights change.