“Downloads” is the vaguest number in mobile analytics. Store consoles report a raw download count, attribution platforms report installs, and product analytics report first opens — three numbers that sound like the same thing but rarely match, and nobody owns the gap between them. A user can tap “Get,” start a download, and never open the app; a device can silently re-download an app it already had; a family-sharing install can count as five downloads and one active user. Without tracking the full path from store impression to first open, teams optimise the wrong stage of the funnel — spending on store listing polish when the real leak is post-install onboarding, or vice versa.
This matters more as acquisition costs climb and stores make it harder to distinguish a genuine new user from a reinstall, a device restore, or a bot. If your only download number is the one in App Store Connect or Play Console, you’re flying blind on everything that happens between the tap and the moment a user actually does something in your app.
Data Points to Track
- Store impression to download rate: store page views against download starts, split by traffic source (organic search, browse, paid, referral)
- Download completion rate: downloads started versus finished, since large app sizes and poor network conditions cause silent drop-off mid-download
- First open latency: time between install completion and first app open — installs that never convert to a first open within 24 hours are effectively lost
- Reinstall vs. new install flag: device- or account-level signal distinguishing a genuine new user from someone reinstalling after deletion
- Attribution source and campaign ID: the referring click or impression that drove the install, captured via your attribution SDK (AppsFlyer, Adjust, Branch, or platform-native SKAdNetwork/Play Install Referrer)
- Install-to-signup conversion: whether a first open actually progresses into account creation, the real handoff point between acquisition and product data
Setup Steps
- Wire up platform-native install receipts — the Play Install Referrer API on Android and StoreKit/App Store Connect data on iOS — as your baseline source of truth, since these are the hardest to spoof.
- Layer an attribution SDK on top to capture campaign-level source data, deduplicating against the platform-native install signal rather than trusting either source alone.
- Fire a distinct
app_first_openevent separate from your attribution SDK’s internal install event, so product analytics and attribution data can be joined on a common install ID. - Flag reinstalls explicitly using a persisted device or keychain identifier that survives app deletion, so reinstall volume doesn’t inflate your new-user counts.
- Build one funnel view — store impression → download → install complete → first open → signup — pulling from all three systems, rather than checking each platform’s dashboard separately.
Actionable Insights
Once the full funnel is visible, the leak usually isn’t where teams assume. A high download-start rate with low completion often points to app size or a slow CDN on cellular networks, not creative or listing quality. A high install-complete rate with low first-open rate is an OS-level problem — permission prompts, notification opt-ins, or update dialogs blocking the launch — not an acquisition problem at all. And a gap between attribution-reported installs and your own first-open count is worth investigating directly with your attribution vendor, since it usually means click fraud or misattributed organic traffic inflating paid campaign numbers.
The teams that get this right stop treating “downloads” as one metric owned by marketing and start treating it as a funnel owned jointly by growth and product, with a single shared definition of what counts as a real, attributable install.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert