# App revenue estimation: the methodology behind the numbers

> Every competitor-revenue number in every ASO tool is a model, because Apple publishes none. This page shows the standard methodology — and the exact shape of openaso's — so you can read any vendor's figure for what it is.

## Why estimates are all there is

Real revenue exists in exactly one place: App Store Connect, visible only to the app's own developer. What is public is the [top-grossing chart](https://openaso.ai/reference/top-charts.md) — an ordered top-100 list per storefront and genre, with no numbers attached. Vendors bridge the gap with models: chart position in, dollars out, calibrated against whatever ground truth they can assemble. The models differ; the epistemic situation does not.

## The rank-to-revenue power law

App spending is extremely top-heavy, and grossing charts inherit that shape: revenue at rank *r* is well approximated by *A · r^-α*, an anchor times a decay exponent. openaso's shipped calibration uses **α ≈ 0.95** with a US overall-chart anchor on the order of **$4M of daily gross consumer spend at #1**, then scales by per-country multipliers (storefront spend size) and per-genre multipliers (how that category's chart interleaves with overall spend). The point of publishing this is not that the constants are sacred — it is that a number you can interrogate beats a number you must trust.

## Bands, not points

Even well-calibrated public-data models carry tens-of-percent error on typical apps and worse in the long tail — monetization mix, price points, and regional skew are invisible from a rank. Reporting a point estimate from that uncertainty is false precision, so openaso's [revenue](https://openaso.ai/tools.md) tool reports a **multiplicative band**: ×2 around the estimate when working from an overall-chart rank, ×2.5 from a genre chart (shallower pools, noisier interleaving). Apps outside every top-100 get an upper bound only — *less than roughly X* is all a missing rank supports.

```json
{
  "storefronts": [
    { "country": "US", "genreName": "Photo & Video",
      "topGrossing": null, "genreGrossing": 34,
      "estimate": {
        "basis": "genre-chart", "rankUsed": 34,
        "daily": { "low": 1300, "mid": 3200, "high": 8000 },
        "monthly": { "low": 39000, "mid": 97000, "high": 240000 },
        "countryMultiplier": 1, "genreMultiplier": 0.2,
        "bandMultiplier": 2.5
      } }
  ],
  "note": "modeled from public grossing ranks — report as an estimate, never as fact"
}
```

## Calibration and drift

The constants are fitted against disclosed figures — earnings reports, court filings, developers publishing their own numbers — and refreshed against daily archived chart snapshots, because the mapping drifts with seasonality and the genre mix of the charts. Genre multipliers get sharper wherever a developer's actual App Store Connect figures can anchor them; subscription-dense categories, for instance, monetize well above what naive chart interleaving implies.

## How to use a band honestly

- Right uses: market sizing, competitor triage, *is this niche worth entering*, trend direction over months. Wrong uses: accounting, valuation models, or settling a bet to the nearest $10k.
- Comparisons are most reliable **same genre, same storefront, same day** — shared multipliers cancel, and the power law does the ordering.
- Every openaso revenue response carries its basis, multipliers, and band; agents consuming it are instructed to present figures as estimates. Any tool that shows a competitor's revenue as a bare number is running the same class of model and hiding the error bars.

## FAQ

### How accurate are app revenue estimates?

Best public-data models land within tens of percent on typical top-charting apps and degrade toward order-of-magnitude in the long tail. That is why openaso reports bands with the model's parameters attached rather than point figures.

### Why do Sensor Tower, Appfigures, and openaso disagree about the same app?

Different models: different anchors, exponents, panel data, and calibration sets on top of the same public chart positions. Disagreement between vendors is the error bar, made visible.

### Can I get real numbers for my own app?

Yes — App Store Connect reports actual proceeds for apps you own (sales reports daily, finance reports monthly). Models are only for apps whose Connect account you cannot see.

### What does it mean if an app is on no grossing chart?

Its spend velocity is below the top-100 cutoff of its genre and storefront, so public data supports only an upper bound. For most storefronts and genres that still brackets it usefully — and null is more honest than an invented rank.

## Terms

- **power-law model** — Revenue estimated as A · rank^-α from a grossing chart position — anchor times decay, scaled by country and genre multipliers.
- **revenue band** — A low/mid/high range produced by a multiplicative factor around the model's estimate — the honest output format for rank-based revenue.
- **estimate basis** — Which observation fed the model: an overall-chart rank, a genre-chart rank, or no rank at all (upper bound only).