Somebody on your team pastes a competitor's "monthly revenue" into a planning doc. It came from a free app-intelligence page, it has no range beside it, and within a week it is being quoted as fact. The figure is not a lie, but it is not a measurement either. It is the output of a model that started from a chart position, and the honest form of that output is a range.
This article walks through how such a model gets from a rank to a dollar figure, where each step adds uncertainty, and how to read the range once you have one.
Exact numbers go to the app's owner, and only the owner
Apple and Google both report exact downloads and earnings, but only to the developer who owns the app. Apple's App Store Connect defines proceeds as "the Customer Price minus applicable taxes and Apple's commission" and counts an app unit "when a customer taps the 'Buy' or 'Get' button for the first-time" (View units, proceeds, sales, and pre-orders, App Store Connect Help). Google gives Play developers a Statistics page to "compare metrics, select custom date ranges, and view data by dimensions" (View app statistics, Play Console Help).
Neither of those is visible to you for an app you do not own. Researchers hit the same wall years ago. A peer-reviewed study of Apple's App Store noted that it does not provide "actual download data, a very useful statistic for both practitioners and researchers" (Garg & Telang, Inferring App Demand from Publicly Available Data, MIS Quarterly, 2013).
What everyone can see is the charts: top free, top paid and top grossing, overall and by category, per store and per country. Every outside estimate starts there.
Step 1: a rank becomes a value through a curve
A chart position is ordinal. It tells you an app was 12th, not how far ahead of 13th it was. To turn ranks into quantities, a model assumes a shape for how value falls off as you go down the chart. The usual choice is a power law: value at rank r is roughly a × r^(−b), where a sets the scale and b sets how steeply the curve drops.
The slope is the part with the best public evidence. Garg and Telang inferred it from public data alone and found that "the top ranked paid app for iPhone generates 150 times more downloads compared to the 200th ranked app" (SSRN abstract). That ratio pins down b for one chart. It says nothing about a: a curve can have the right shape and still be wrong by a factor of ten.
Step 2: the scale comes from published anchors
To set the scale, you need at least one rank where somebody has published an absolute number. The public record holds a handful of these, and nearly all of them are estimates themselves:
- Downloads. Sensor Tower reported that a non-game iPhone app needed a median of 156,000 daily US downloads to reach No. 1 in 2022, and 52,000 to reach the top 10, based on its own Store Intelligence data (Sensor Tower).
- Revenue by rank. Distimo found that in May 2013 a US iPhone app needed about "$47,000 in daily revenue" to enter the top 10 grossing and "$12,000" for the top 50 (TechCrunch).
- Market size. Appfigures estimated that US App Store developers generated $33.68 billion in gross revenue in 2024 through Apple's payment system (TechCrunch).
The large vendors do not rely only on anchors like these. Appfigures, for example, says it trains its models "with real downloads and revenue data from hundreds of thousands of apps that share that data with us" (Appfigures help). A model built only on public anchors has no panel like that. It re-derives the shape of curves that vendors have published, and it should say so.
Step 3: every weak point widens the range
If all the anchors agreed, were current and covered every storefront, you could draw one curve and report one number. They do not, and each gap shows up as width.
The anchors disagree. The slope implied by Distimo's 2013 grossing figures is not the slope implied by later concentration data, such as Sensor Tower's finding that the top 100 US mobile games took 64% of the sector's revenue in 2020 (Game Dev Reports, summarising Sensor Tower). The honest move is to keep every curve the anchors allow and report the spread between them, not to pick a favourite.
The anchors are old. A 2022 median read in 2026, or a 2013 revenue figure, describes a market that has since moved. A careful model widens its range for that drift rather than pretending the anchor is current.
Most countries have no anchor. The published absolute figures above are for the United States. Distimo gave relative figures for a couple of other markets, reporting that in the UK an app needed "only 21 percent" of the US downloads to reach the top 25 (TechCrunch). For most storefronts there is nothing, so any estimate there is a wide prior scaled from the US curve.
Few days in the chart. An app that charted for three days of the last thirty has given the model three data points. A month of daily positions averages out spikes; a few days cannot.
Category charts need translating. A position in a category chart has to be converted to an overall-chart equivalent, usually through apps that appear in both on the same day. That conversion carries its own error.
Gross versus net. Grossing charts track what customers spend. What the developer keeps depends on the commission, and the published schedules have many tiers: Apple offers 15% under its Small Business Program and mentions a 10% rate for some cases (Apple), while Google lists rates from 10% plus a 5% billing fee upward for US transactions (Service fees, Play Console Help). From outside, you do not know which tier an app is on.
Stack those together and a range whose top is many times its bottom is not a sign of a bad model. It is the model reporting what the public evidence can support.
Apple and Google Play need separate curves
The two stores' charts are not interchangeable. Sensor Tower's 2022 figures show a non-game app needing 56,000 median daily US downloads for No. 1 on Google Play against 156,000 on the App Store (Sensor Tower), so a single curve for both stores would be wrong for at least one of them. The public evidence is also uneven between them. The peer-reviewed slope is for Apple's paid chart, and the revenue anchors above are App Store figures, so a Google Play revenue estimate usually rests on thinner ground than an App Store one. Treat the two stores as two separate estimates, even for the same app.
A hypothetical example
For illustration only. These are not observed or modeled figures for any real app. A meditation app sits around 40th in the US App Store's Health & Fitness grossing chart for most of a month and never appears in the overall grossing chart. The model converts its category position to an overall equivalent through apps that appear in both charts, averages the month and returns something like "$20K to $90K per month in gross revenue (what users paid, before store commission), Low confidence". The width comes from two sources at once: category conversion and the anchor spread. Seeing the same app in the overall chart on most days would narrow it. Moving the question to a storefront with no anchor would widen it.
How to read a range once you have one
- Read the low end and the width before the middle. The low end tells you what the evidence supports at minimum. The width tells you how much the model knows.
- Treat the point estimate as a sorting aid. It lets a table put apps in an order. It is not a more precise answer than the range around it.
- Overlapping ranges are a tie. If two apps' ranges overlap heavily, the order between them is not known, whatever the point estimates say.
- Changes inside the overlap are noise. If this month's range and last month's overlap heavily, call the change flat.
- Check what is excluded. Grossing charts only see store purchases. Ad revenue and web payments are invisible to them.
The same habit runs through our piece on what a keyword difficulty score can and cannot tell you. A model's output is useful for ordering things roughly and dangerous when quoted as a measurement. Storefront matters here too, for the reasons covered in why keyword rankings differ by country.
Where ASOClimb fits
ASOClimb's Revenue Estimates page models monthly store revenue and downloads from the public chart positions it captures, for the App Store and Google Play, one storefront at a time. Every figure is a range with a point estimate and a Medium or Low confidence level, and the reasons for the confidence are listed next to it. The methodology page names each public anchor, says that the range is a heuristic band rather than a statistical confidence interval, and says that no backtest against reported revenue has been published, so ASOClimb makes no accuracy claim. To look up an app, sign in and open Revenue Estimates.