# App Revenue Estimates: How They Work (and Fail) > App revenue estimates can miss actual numbers by 2×+. Learn how third-party tools calculate revenue, why they're wrong, and when to trust them anyway. - **Author:** Peter Sutarik - **Published:** August 10, 2026 - **Tags:** app revenue estimates, aso tools, mobile analytics, app monetization - **Reading time:** 10 min - **Canonical:** https://trysonar.app/blog/app-revenue-estimates-how-they-work-and-fail --- ## 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](https://www.mirava.io/blog/how-to-check-app-revenue)). 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](https://x.com/SinaSinry/status/1950810210819297342)). 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](https://sensortower.com/product/mobile-app/app-performance-insights)). 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](https://developer.apple.com/help/app-store-connect/)). - **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](https://www.revenuecat.com/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](https://www.revenuecat.com/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 because iOS install counts are inferred from review counts, not public data (source: Sonar /api/v1/apps/revenue, queried 2026-08-10). The same endpoint puts Duolingo at $20.4M/mo on iOS (medium confidence, 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). ![App revenue estimates compared across iOS and Android for Duolingo, Calm, and Headspace — showing confidence ratings differ by platform due to install-count data availability](https://trysonar.app/blog/app-revenue-estimates-how-they-work-and-fail-hero.png) *iOS estimates carry medium confidence (review-derived installs) while Android estimates earn high confidence from public install counts.* 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](https://www.revenuecat.com/state-of-subscription-apps)). 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](https://www.revenuecat.com/state-of-subscription-apps)). ## 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](https://trysonar.app/blog/real-search-volume). ## 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](https://techcrunch.com/2024/03/18/app-analytics-firm-sensor-tower-acquires-rival-data-ai/)). 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](https://www.mirava.io/blog/how-to-check-app-revenue)). 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](https://sensortower.com/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](https://trysonar.app/blog/sensor-tower-pricing), accuracy at your app's scale matters more than aggregate accuracy across all apps. ## What App Revenue Estimates Are Actually Good For Despite the error margins, app revenue estimates serve three legitimate purposes: 1. **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](https://www.mirava.io/blog/how-to-check-app-revenue)). 2. **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. 3. **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](https://trysonar.app/blog/aso-kpis) alongside revenue estimates gives a more complete picture of app health. And if you're choosing between [app monetization models](https://trysonar.app/blog/app-monetization-strategy-models-compared), 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](https://trysonar.app/pricing) and compare. Where estimates converge, confidence is higher. Where they diverge, investigate why. - **Check the confidence rating.** Sonar's API returns a confidence field ("high" or "medium") that reflects whether the install base comes from public data or review-derived inference. A "high" confidence Android estimate anchored to a public install count is structurally more reliable than a "medium" iOS estimate. - **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](https://www.apple.com/newsroom/2026/06/app-store-ecosystem-reaches-1-point-4-trillion-usd-as-developers-thrive-globally/)). 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 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](https://www.mirava.io/blog/how-to-check-app-revenue)). 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](https://x.com/SinaSinry/status/1950810210819297342)). 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 with a "medium" confidence rating for iOS estimates vs. "high" for Android when a public install count exists (source: Sonar /api/v1/apps/revenue, queried 2026-08-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](https://www.revenuecat.com/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 confidence rating — "high" when anchored to public data, "medium" when review-derived — so users know how much weight to place on the number (source: Sonar /api/v1/apps/revenue, queried 2026-08-10). *Want to see revenue estimates with transparent confidence ratings? [Try Sonar free](https://trysonar.app/pricing) — every estimate shows its methodology, data source, and confidence level so you know exactly what you're working with.* --- Source: https://trysonar.app/blog/app-revenue-estimates-how-they-work-and-fail — published by [Sonar](https://trysonar.app), an App Store Optimization platform for keyword research, difficulty analysis, and rank tracking.