An estimate of downloads is built, not read off a store

The figure or the record

Sensor Tower publishes download and revenue figures for the short-drama app category, but its own pages describe how those figures are built rather than counted outright. On its data-sourcing page, retrieved 16 September 2026, the firm states it draws on 'more than 10 million consumers' through its own privacy-compliant apps, combined with 'first party data, and publicly available data, like earnings releases'. It says it applies 'a combination of modeling and machine learning to fit our models and deliver the most accurate estimates possible', in the sourcing page. A separate report shows what that process yields for one metric: the state-of-short-drama report, also retrieved 16 September 2026, states that its download figures are 'based on estimated downloads from the App Store and Google Play, excluding pre-installs, re-downloads, and downloads from third-party Android marketplaces'.

What the documents establish

The sourcing page establishes three named inputs, panel data, first-party data and public data such as earnings releases, merged through modelling, and it concedes plainly that 'no dataset represents 100% of all digital user behavior'. The report adds a narrower fact: a stated exclusion list attached to one metric, downloads, in one release. Read together, the two pages establish that a Sensor Tower download count is a defined, bounded estimate with a stated store scope, App Store and Google Play only, and stated exclusions, rather than a raw export from either storefront. Neither page states the panel's size relative to the platforms it estimates for, and neither breaks out how an in-app purchase figure is derived by the same process.

Scope and caveats

Both pages are living documents; this description reflects what they stated as retrieved on 16 September 2026 and may change without a dated revision notice. The sourcing page speaks about the company's methods in general, not about any one figure, so it cannot certify a specific number in a specific report. The exclusions named for downloads, pre-installs, re-downloads, sideloaded installs, do not automatically apply to a revenue or in-app-purchase figure quoted elsewhere unless that release states the same scope.

What to watch

This is an editorial checklist, not a Sensor Tower statement: before repeating a Sensor Tower figure, check whether the specific release names the metric, downloads, in-app purchases, or ad spend, the store scope, and any exclusion list, rather than assuming the general sourcing page covers every number the firm publishes.

• Does the release name the exact metric, downloads, in-app purchases, or consumer spend, and the store scope it covers?
• Does it state an exclusion list, such as pre-installs, re-downloads, or third-party marketplaces?
• Is the same metric defined the same way in a comparison period, or has the exclusion list changed?

A panel-and-model estimate can still be useful evidence, provided a reader can see what it was built from. The two pages above show what Sensor Tower itself is willing to disclose about that construction, and what it leaves for a specific report to define.