sonar
How App Revenue Estimates Are Calculated — and Why They Miss
Every investor pitch deck, competitor teardown, and market-sizing exercise depends on third-party app revenue estimates. The numbers look authoritative: "$20M monthly revenue," a clean chart, a confidence badge. But behind that figure is a chain of assumptions — each one introducing error that compounds instead of canceling out.
I've spent years building Sonar's own revenue model, and the single most important thing I've learned is this: multiplying two uncertain inputs (downloads × revenue per user) produces an output whose error is wider than either input alone. Appfigures reports its own median absolute percent error at 5–25% (source: Mirava, "How to Check Any App's Revenue," 2026). One app developer publicly reported Sensor Tower listing their app at $40K MRR when the actual number was $90K — a 2.25× underestimate (source: @SinaSinry on X, 2025).
These tools are still useful. But understanding how the sausage gets made — and where the model breaks — is the difference between using app revenue estimates as directional intelligence and treating them as gospel.
The Core Formula: Downloads × ARPU
Nearly every third-party revenue model follows the same skeleton: Estimated Downloads × Estimated ARPU (Average Revenue Per User) = Estimated Revenue. Sensor Tower, Appfigures, AppTweak, and Sonar all start here, though each fills in the variables differently (source: Sensor Tower product page).
The formula has three load-bearing variables:
- Install count. On Google Play, this is public (rounded, e.g., "10M+"). On iOS, Apple does not display download counts publicly — they're only visible to the developer in App Store Connect (source: Apple App Store Connect Help).
- Retention rate. What share of installers are still active? Industry-wide, Day 30 retention for the median app hovers around 6–8%, but subscription apps in Health & Fitness or Education can hold 11–15% depending on the cohort (source: RevenueCat, State of Subscription Apps 2025).
- Revenue per active user. This depends on the monetization model — subscription, IAP, ads, or hybrid. RevenueCat's 2025 data shows median 14-day ARPU of $0.44 for Health & Fitness apps, with the top 10% reaching $4.19 (source: RevenueCat, State of Subscription Apps 2025).
If any one of these three inputs is off by 30%, the output can swing by 30% or more. If two are off, errors compound.
Where iOS Estimates Go Wrong
The biggest source of error in iOS app revenue estimates is the install count. Google Play publishes a rounded install count on every listing page. Apple does not. This single asymmetry cascades through every downstream calculation.
To fill the gap, third-party tools use proxies. The most common: review-to-install ratios. If an app has 500,000 ratings and the assumed ratio is 1 review per 100–200 installs, the model infers 50M–100M downloads. That's already a 2× range before touching ARPU.
Sonar's revenue endpoint estimates Calm's iOS monthly revenue at $7.4M, derived from ~394.4M review-estimated installs, an 11% retention assumption, and subscription-model benchmarks for Health & Fitness — with a "medium" confidence rating at the time because iOS install counts are inferred from review counts, not public data (source: Sonar /api/v1/apps/revenue, queried 2026-08-10). The same lookup on 2026-10-12 returned $6.7M/mo with "low" confidence (source: Sonar /api/v1/apps/revenue, queried 2026-10-12).
The same endpoint puts Duolingo at $20.4M/mo on iOS (medium confidence at the time, review-derived installs) vs $50.8M/mo on Android (high confidence, public install count) — illustrating how the confidence gap between platforms affects estimate reliability (source: Sonar /api/v1/apps/revenue, queried 2026-08-10).
That confidence gap is not cosmetic. The Android estimate anchors to a known install count (952.2M public installs for Duolingo on Google Play), while the iOS figure infers installs from review volume. Same formula, different confidence floors.
The Retention Assumption Problem
Even with a solid install count, revenue models live or die on the retention assumption. Most tools apply a flat retention rate by category — say, 11% for subscription apps — but actual retention varies wildly within a category.
For Headspace, Sonar estimates $7M/mo on iOS from ~194.8M review-derived installs and ~21.5M estimated active users at 11% retention (source: Sonar /api/v1/apps/revenue, queried 2026-08-10). But Headspace's actual retention could be 8% or 15% — that difference alone would shift the estimate from $5.1M to $9.5M, a nearly 2× spread.
RevenueCat's data makes this concrete. Across all subscription apps, the middle 50% of monthly revenue per user spans $16–$429 — a 27× spread (source: RevenueCat, State of Subscription Apps 2026). Category benchmarks smooth over this variance, which is why broad-category retention rates produce broad error bars.
The problem is worse for apps with unusual user bases. A meditation app with a loyal subscriber cohort from 2019 will retain differently than a viral newcomer burning through free-trial users. RevenueCat found that apps launched before 2020 account for 69% of all subscription revenue, while apps launched in 2025 or later contribute just 3% (source: RevenueCat, State of Subscription Apps 2026).
How Error Compounds: A Worked Example
Here's how estimation error stacks up, using Calm on iOS as a baseline.
| Variable | Sonar estimate | Plausible low | Plausible high |
|---|---|---|---|
| Installs (review-derived) | 394.4M | 250M | 550M |
| Retention rate | 11% | 7% | 15% |
| Monthly ARPU | ~$0.17 (implied) | $0.10 | $0.25 |
| Monthly revenue | $7.4M | $1.8M | $20.6M |
The "plausible low" and "plausible high" columns aren't extreme scenarios — they're what happens when each input shifts by roughly 30–40%. The resulting revenue range spans more than 10×. This is the fundamental weakness of download×ARPU modeling: it compounds error instead of averaging it.
For a deeper look at how data accuracy affects ASO decisions, see our analysis of real search volume behind app store keywords.
Why Tools Disagree With Each Other
Third-party estimators disagree with one another more than their dashboards let on. Each tool uses different panel data, different review-to-install ratios, and different category benchmarks. Sensor Tower merged with data.ai in 2024 and now draws from both panels (source: TechCrunch, March 2024). Appfigures uses its own methodology. AppTweak takes a different approach entirely.
The result: ask three tools for the same app's revenue and you may get three meaningfully different numbers. One study found that Appfigures' self-reported median absolute percent error sits between 5% and 25% (source: Mirava, 2026). Sensor Tower's accuracy is harder to pin down externally, though its panel of more than 10 million opted-in consumers provides broader coverage (source: Sensor Tower, Responsibly Sourced Data).
The gap matters most for mid-tier apps. For the top 100 apps in any category, panel data is dense enough to constrain estimates. For an app ranked #300–#1000, panel overlap is thin and the models lean harder on assumptions. If you're evaluating Sensor Tower's pricing and alternatives, accuracy at your app's scale matters more than aggregate accuracy across all apps.
How to check an app's revenue estimate
To check any app's revenue estimate, follow four steps:
- Pick the exact store listing. Revenue is estimated per listing, so use the App Store ID or Google Play package name — iOS and Android are separate estimates for the same app.
- Run it through an estimator. Sensor Tower, Appfigures, and Sonar's revenue API all return a monthly figure built on variations of the downloads × ARPU approach described above (Appfigures describes its version as AI models trained on observable store data — source: Appfigures Help Center, 2026).
- Read the confidence rating and methodology, not just the number. Look for where the install count came from (public vs. review-derived), the retention rate assumed, and the monetization model.
- Cross-check. Compare the iOS and Android listings, and a second tool. If they disagree by 2× or more, treat the figure as an order of magnitude.
Step 4 matters more than it sounds. Here is what one estimator returns for the same three apps on each store:
| App | iOS estimate (confidence) | Android estimate (confidence) | Gap |
|---|---|---|---|
| Spotify | $81.8M/mo (low) | $122.4M/mo (high) | 1.5× |
| Duolingo | $35.2M/mo (medium) | $52.9M/mo (high) | 1.5× |
| Calm | $2.8M/mo (medium) | $3.4M/mo (high) | 1.2× |
Source: Sonar /api/v1/apps/revenue, US storefront, queried 2026-11-10.
The same company gets a store-to-store spread of 1.2–1.5×. Behind each iOS figure sits a much wider range, because its installs are estimated from US ratings (e.g. ~836.3M for Duolingo on iOS, range $5.3M–$175.9M/mo, vs. a public ~994.8M on Google Play), and Spotify's iOS monetization model was also unknown (source: Sonar /api/v1/apps/revenue, queried 2026-11-10). The model changed after our first query on 2026-10-12: back then the same three iOS lookups returned single figures, all at "low" confidence ($80.9M, $17.4M and $6.7M/mo); iOS estimates now come with a range and are capped at "medium" confidence (source: Sonar /api/v1/apps/revenue, queried 2026-10-12 and 2026-11-10). Sonar's confidence has three levels — high, medium, low — computed from penalties for review-derived installs, an unknown monetization model, missing in-app purchase pricing, or an unknown release date, offset by chart-rank corroboration and named IAP tiers (source: Sonar /api/v1/apps/revenue confidence_factors, queried 2026-10-12).
If you want to run the check programmatically, one request covers up to 25 apps:
curl "https://trysonar.app/api/v1/apps/revenue?ids=570060128,571800810&store=ios" \
-H "Authorization: Bearer $SONAR_API_KEY"Each response includes the monthly figure, the model, the methodology (installs, estimated active users and retention %, category benchmarks), confidence, and confidence_factors (source: Sonar /api/v1/apps/revenue, queried 2026-10-12). For how the major data APIs compare on price and coverage, see our ASO APIs comparison; if Sensor Tower's price is the blocker, see Sensor Tower alternatives.
How to test an app revenue checker against real numbers
The fastest way to judge an app revenue checker is to run it on an app whose real revenue is public, and see how far off it lands. Public companies that sell mostly through app stores are the best test cases, because their filings say how much revenue Apple and Google processed.
Duolingo is a clean example. Its Q3 2026 10-Q reports $309.0M total revenue for the quarter, and states that Apple processed 59.6% and Google 23.3% of it (source: Duolingo Form 10-Q, quarter ended Sep 30, 2026). That works out to roughly $61.4M/mo through Apple and $24.0M/mo through Google. Here is what one checker returned the same week:
| Duolingo | Reported (Q3 2026, per month) | Sonar estimate | Sonar range | Off by |
|---|---|---|---|---|
| iOS (Apple-processed) | ~$61.4M | $35.2M (medium) | $5.3M–$175.9M | ~1.7× low |
| Android (Google-processed) | ~$24.0M | $52.9M (high) | none (public installs) | ~2.2× high |
Reported: Duolingo 10-Q, $309.0M × processor share ÷ 3. Estimates: Sonar /api/v1/apps/revenue, queried 2026-11-10.
Two lessons. First, the "high" confidence Android figure missed by more than the "medium" iOS one: confidence describes how solid the install count is, not how well the ARPU assumption fits. The filing shows Apple processing about 2.6× Google's share even though Duolingo's public Google Play count is ~994.8M installs, so revenue per Android install is much lower than on iOS, and a category-wide benchmark can't see that. Second, the iOS point estimate was off, but the actual sat inside the stated range. Sonar's iOS lookups now return a monthly_range because installs are inferred from US ratings only (source: Sonar /api/v1/apps/revenue confidence_factors, queried 2026-11-10). A checker that shows a range is being honest about this; one that shows a single precise number is not more accurate, only less candid.
Keep the comparison fair. Company revenue covers every country and platform, and Duolingo also bills directly through Stripe (12.1% of Q3 revenue, same 10-Q), so the store shares above are the right yardstick, not the $309.0M total. That total also includes ~$20.8M of advertising and ~$9.9M of Duolingo English Test revenue (same 10-Q). Sonar's Android "hybrid" model counts ad revenue, while the Google-processed share covers billing only, which accounts for part of the Android gap. Reported revenue is also recognized over the subscription term, while store estimates approximate a month of sales. Treat a single test like this as a check of direction and scale, not a precise accuracy score. Free signals help too: an app's position in the top-grossing chart is a rank, not a dollar figure, but a checker that puts a top-100 grossing app below a lower-ranked one is worth questioning.
For your own app, skip the checkers: App Store Connect reports actual units and proceeds (see App Store Connect analytics). For the downloads side of the same math, our guide to how many downloads a new app should get shows why two download estimates can disagree by 30×.
What App Revenue Estimates Are Actually Good For
Despite the error margins, app revenue estimates serve three legitimate purposes:
- Order-of-magnitude sizing. Revenue estimates reliably separate a $10K/month app from a $1M/month app. They won't tell you whether an app makes $42K or $58K, but they'll tell you it's not making $500K (source: Mirava, 2026).
- Relative comparison. Comparing two apps within the same category using the same tool controls for systematic bias. If Tool X says App A earns 3× more than App B, the ratio is more reliable than either absolute number.
- Trend detection. Month-over-month changes from the same tool reflect real directional shifts, even if the absolute numbers are off. A 40% revenue jump in Sensor Tower data likely corresponds to a real increase, even if the precise magnitude differs.
Where they fail: due diligence on acquisitions, precise financial modeling, and any context where the number flows into a spreadsheet cell that feeds a binding decision. For those, you need actual financials — which only the company's finance team has.
Understanding which ASO KPIs to track alongside revenue estimates gives a more complete picture of app health. And if you're choosing between app monetization models, directional revenue data by category can still inform your strategy — just don't treat the numbers as actuals.
How to Get Better Revenue Estimates
No tool will hand you the exact number, but you can tighten the range by triangulating across multiple signals:
- Cross-reference tools. Run the same app through Sensor Tower, Appfigures, and Sonar's revenue endpoint and compare. Where estimates converge, confidence is higher. Where they diverge, investigate why.
- Check the confidence rating. Sonar's API returns a confidence field with three levels ("high", "medium", or "low"), scored from penalties such as review-derived installs or an unknown monetization model. On 2026-11-10, the Android listings of Spotify, Duolingo, and Calm all returned "high", while their iOS lookups returned "medium" (Duolingo, Calm) or "low" (Spotify), since review-derived iOS installs can't be graded above medium (source: Sonar /api/v1/apps/revenue, queried 2026-11-10). An Android estimate anchored to a public install count is structurally more reliable than a review-derived iOS one.
- Adjust for monetization model. A subscription app with publicly listed pricing narrows the ARPU estimate. If the app charges $69.99/year and you can estimate the subscriber count, you can bound revenue more tightly than a generic category benchmark allows.
- Use review velocity as a cross-check. If an app's review count is growing at 5,000/month and the assumed install-to-review ratio implies 1M new installs/month, check whether that squares with the app's chart ranking. Inconsistencies flag weak estimates.
Apple's App Store ecosystem facilitated $1.4 trillion in developer billings and sales in 2025, with $149 billion from digital goods and services alone (source: Apple Newsroom, June 2026). That's the total pie. Third-party tools are trying to slice it per-app with incomplete information — which is why triangulation beats reliance on any single source.
Frequently Asked Questions
How can I check an app's revenue?
Unless the developer publishes its numbers, you can only check an app's revenue estimate, not its actual revenue. Find the app's store listing (App Store ID or Google Play package), run it through an estimator such as Sensor Tower, Appfigures, or Sonar's /api/v1/apps/revenue endpoint, then read the confidence rating and methodology before trusting the figure. Cross-check the other store's listing and a second tool: on 2026-11-10, Sonar's iOS and Android estimates for the same app differed by 1.2–1.5× (Spotify, Duolingo, Calm), and no iOS lookup rated above "medium" confidence (source: Sonar /api/v1/apps/revenue, queried 2026-11-10).
Which app revenue checker can I trust?
No app revenue checker returns exact numbers, so trust the one that shows its work: the install source, the retention and monetization assumptions, a confidence rating, and ideally a range. Test it on a public company first. Against Duolingo's Q3 2026 filing, Sonar's iOS estimate came in about 1.7× low and its Android estimate about 2.2× high, with the iOS actual inside the stated $5.3M–$175.9M range (sources: Duolingo 10-Q; Sonar /api/v1/apps/revenue, queried 2026-11-10). Sonar's revenue endpoint is available on prepaid API credits and on the Indie and Agency plans (pricing).
How accurate are app revenue estimates from third-party tools?
Third-party app revenue estimates typically carry a 5–25% median absolute percent error for large apps with strong panel coverage (source: Mirava, 2026). For smaller or mid-tier apps, error can exceed 2× — one developer reported Sensor Tower estimating $40K MRR when actual MRR was $90K (source: @SinaSinry on X, 2025). Estimates are most reliable for relative comparisons within the same tool, not as absolute numbers.
Why are iOS revenue estimates less reliable than Android?
iOS app revenue estimates are less reliable because Apple does not publicly display download counts on App Store listings. Third-party tools must infer iOS installs from proxies like review counts, introducing an extra layer of uncertainty. Google Play, by contrast, shows a public (rounded) install count, which anchors the estimate to a known floor. Sonar flags this difference in its confidence rating: on 2026-11-10, iOS lookups for Spotify, Duolingo, and Calm returned "medium" or "low" confidence while their Android listings returned "high" (source: Sonar /api/v1/apps/revenue, queried 2026-11-10).
What is the download × ARPU model for estimating app revenue?
The download × ARPU model multiplies estimated installs by an assumed average revenue per user to produce a revenue estimate. Each variable introduces its own error: installs may be inferred from review counts (especially on iOS), and ARPU depends on assumptions about retention rate and monetization model. RevenueCat's 2025 data shows median 14-day ARPU of $0.44 for Health & Fitness apps, but the top 10% reaches $4.19 — a nearly 10× spread within a single category (source: RevenueCat, State of Subscription Apps 2025).
Should I use app revenue estimates for investment decisions?
App revenue estimates are useful for order-of-magnitude sizing and competitive benchmarking, but they should not be the sole basis for investment or acquisition decisions. The error bars are too wide for precise financial modeling. Use them to identify opportunities and filter candidates, then request actual financials from the company for any binding decision.
How does Sonar calculate app revenue estimates?
Sonar's revenue endpoint combines estimated installs, a category-specific retention rate, and monetization-model benchmarks to produce a monthly revenue figure. On Android, installs come from public Google Play counts. On iOS, installs are inferred from review counts. Each estimate includes a three-level confidence rating — high, medium, or low — that drops with each weak input (review-derived installs, unknown monetization model, missing IAP pricing), so users know how much weight to place on the number. iOS estimates also come with a monthly range and are capped at "medium"; on 2026-11-10, iOS lookups for Duolingo and Calm returned "medium" and Spotify "low" (source: Sonar /api/v1/apps/revenue, queried 2026-11-10).
Want to see revenue estimates with transparent confidence ratings? Try Sonar free — every estimate shows its methodology, data source, and confidence level so you know exactly what you're working with.
