Methodology

How we collect, validate, and estimate app data.

Where the numbers come from, how we cross-check them, and where they fall short. No black boxes.

1. Data sources

Many noisy signals, aggregated on purpose.

We pull from app stores, search engines, ad platforms, SEO tooling, third-party consumer-panel providers, and published industry benchmarks. No single source is treated as ground truth — they get cross-checked against each other.

App stores (official)
  • — Apple App Store rankings, listings, and structured metadata
  • — Google Play rankings, listings, and structured metadata
Search engines
  • — Google Search index signals (visibility, organic reach)
  • — Bing Search index signals
Paid search and visibility
  • — Google Ads inventory and bid landscape signals
  • — Apple Search Ads visibility and competitive signals
Paid social
  • — Meta Ads (Facebook + Instagram) creative and reach signals
  • — TikTok Ads creative and reach signals
SEO intelligence
  • — Semrush traffic, keyword, and backlink signals
  • — Ahrefs traffic, keyword, and referring-domain signals
Consumer panel
  • — Aggregated, de-identified consumer-panel signals obtained through third-party data providers
Industry benchmarks
  • — Published industry benchmarks (revenue-per-install and retention medians) used as model priors

2. Validation and estimation

An in-house ML model does the cross-check.

Cross-validate signals
A single source — one ad platform's reach number, one ranking snapshot — is noisy in isolation. The model reconciles signals across every source listed above so a metric only ships when at least one other source agrees.
Estimate revenue when no source publishes it
Stores don't publish revenue directly. We trained the model to map the combination of download signals, ad spend indicators, in-app purchase visibility, and ranking trajectory into a revenue estimate.
Honest about accuracy
These are estimates, not reported figures, and their precision tracks how much signal an app actually generates — tightest for large, established apps, loosest in the long tail. Where confidence is too low to report a real number, we fall back to bucket labels (
<$3k
,
<3k
) rather than fake precision.

3. Refresh cadence

Daily, with hot apps re-checked more often.

  • Main batch runs daily between 02:00 and 07:00 UTC.
  • A subset of high-velocity apps is re-checked every 4–6 hours so ranking moves don't fall behind the live store.
  • The sitemap <lastmod> on every detail page reflects the latest model output time, not the last render.

4. Coverage today

Where the dataset reaches right now.

  • iOS App Store and Google Play, US storefront.
  • A catalogue of ~58,000 apps, of which ~12,000 currently carry ranking data.
  • More countries on the roadmap, not done yet.

5. Known limits

Where the numbers fall short — documented.

Floor effects on weak signals
When source signals only confirm “less than the threshold,” we render
<$3k
for revenue and
<3k
for downloads, instead of guessing a precise figure.
Revenue per download (RPD) suppression
When revenue sits at the floor (i.e. renders as
<$3k
), we suppress the RPD value to
−
. Dividing by an unknown numerator produces noise that looks like signal, and we'd rather show nothing than mislead.
Refresh lag for some metrics
A subset of metrics can lag the live store state by up to ~24 hours, especially during high-traffic events (launches, holidays).
US storefront only, for now
We currently cover the US App Store and Google Play storefronts. Multi-country expansion (EU, Asia) is on the roadmap, not done.

6. Statistics pages

How the aggregate reports are built.

The statistics reports aggregate the whole active catalogue after every crawl. Because revenue and download estimates are bucketed and floored at $1,000 a month, a median across all apps would be meaningless — most apps sit at the floor. Every population-wide figure on those pages is therefore the share of apps above the floor, and medians are computed only among apps that clear it, reported as the median band.

Store revenue only: paid downloads, in-app purchases and subscriptions, before the store commission. Advertising income never passes through the stores and is not included, so ad-supported apps appear as not earning. The catalogue is drawn from the US top charts, including Top Paid, so paid apps are over-represented; ratios within a monetization model are unaffected, overall ratios lean slightly paid. Delisted apps are excluded everywhere, unrated apps are excluded from rating charts, and categories are merged across stores where they mean the same thing (Social Networking and Social, Photo & Video and Photography, Utilities and Tools).

7. FAQ

Common questions about the numbers.

Every day. The main batch runs between 02:00 and 07:00 UTC, and a subset of high-velocity apps is re-checked every 4 to 6 hours so ranking-board movements don't fall behind the live store.

From the app stores themselves (Apple App Store and Google Play), search engine index signals (Google, Bing), ad platforms (Meta, Google Ads, TikTok Ads), SEO intelligence tools (Semrush, Ahrefs), Apple Search Ads, aggregated and de-identified consumer-panel signals obtained through third-party data providers, and published industry benchmarks. No single source is treated as ground truth — they get cross-checked by our model.

It means the signals available for that app only confirmed the value is below our display threshold (revenue under ~$3k/month, or fewer than 3k downloads/month). Rather than invent a precise figure, we render the bucket label so the uncertainty is visible.

We only compute revenue per download when revenue itself is above the floor. Otherwise the numerator is unknown and any ratio would look like signal without being one. "-" means "we don't know yet," not "zero."

They are estimates, not reported figures, and their precision tracks how much signal exists for a given app. Large, established apps carry the most cross-source signal and estimate the tightest; long-tail apps carry the least. Where confidence is too low to report a real number, we fall back to bucket labels instead of fake precision.

Pro subscribers can export filtered app lists to CSV or Excel from the trending apps page. A programmatic API is on the roadmap for the next phase.

The /statistics reports aggregate the active catalogue after every crawl. Revenue and download estimates are bucketed and floored at $1,000, so every population-wide figure is the share of apps above that floor; medians are computed only among apps above it. Store revenue only — advertising income is never included. Delisted apps are excluded, unrated apps are excluded from rating charts, and the catalogue over-represents paid apps because it is drawn from the Top Paid charts too.

Ready to see the dataset?

Browse the live trending list, filtered by category and release window.

We use cookies to improve your experience.View our cookie policy