App Analytics
App Analytics is the built-in analytics dashboard in App Store Connect, answering three core questions: how many people saw you, how many downloaded, and how many stayed after downloading.
Core Metrics & Definitions
| Metric | Meaning | Notes |
|---|---|---|
| Impressions | Times your app was shown in the App Store | Measures “being seen” |
| Product Page Views | Times users opened your product page | Measures “interest” |
| App Units | Actual installs/downloads | Measures “conversion outcome” |
| Active Users | Unique users who used the app | DAU/WAU/MAU |
| Retention | % of users still using after a period | Measures “staying power” |
| Crashes | Crash session share | Measures “stability” |
| Conversion Rate | Product page views → downloads | Measures “page appeal” |
First distinguish the chain “impressions → views → downloads → active → retention”: high downloads with poor retention means you acquire well but the product doesn’t keep users; high impressions with low downloads points to the product page (screenshots, name, description, rating).
How to Read the Dashboard
- Time dimension: view by day/week/month; combine with version, market, and source filters.
- Version comparison: compare active/retention across versions to judge whether a version caused churn.
- Source dimension: see shares from App Store search, browse, web referrals, etc., to understand acquisition structure.
- Metric definitions: “downloads” in App Analytics may differ from your own tracking — normal (dedup, delayed stats); use one consistent source for trend comparison.
Decision Examples
Scenario 1: high impressions, low conversion. Likely causes: unattractive screenshots, unclear name/subtitle, low rating, opaque pricing. Action: optimize the first two screenshots and the first-paragraph description; run A/B tests (the App Store supports product page experiments).
Scenario 2: high downloads, poor retention. Likely causes: poor onboarding, core value not shown in the first 5 minutes, performance issues. Action: combine “active users” by version with crash reports to locate experience problems.
Scenario 3: active users drop sharply in a version. Action: first check that version’s crash rate and retention, then trace back the changes (UI, permissions, features) and decide quickly on rollback or hotfix.
Division of Labor with Your Own Analytics
| Data | App Analytics | Your own tracking (e.g. Firebase, custom) |
|---|---|---|
| App Store impressions/views | Yes | No |
| Downloads/conversion | Yes (external view) | Partial (first launch) |
| In-session behavior | No | Yes |
| Funnels/feature usage | No | Yes |
| User profile (age/region/device) | Yes (summary) | Depends on collection |
App Analytics gives the “store-side” view; your own tracking gives the “in-app” view. Together they answer the full question of “where users come from, what they do inside, and why they leave”.
Self-Check List
- Can locate and interpret impressions / views / downloads / active / retention / crashes
- Can filter by version, time, and source
- Established the “metrics → hypothesis → action” habit
- Can distinguish App Analytics from your own analytics
FAQ
- How delayed is App Analytics data? Usually 1-3 days, which is normal.
- Why do downloads differ from my backend stats? Dedup and timing differences; compare trends from one consistent source rather than absolute values.
- Can I see individual user behavior? No — App Analytics provides aggregate data only, no personal-level detail (privacy compliance).
PreviousAnalytics & DataUse App Analytics and sales/financial reports to understand downloads, retention, crashes, and revenue — drive product decisions with data.
NextCrashes & DiagnosticsView crash reports and diagnostics, locate affected versions and devices, and build a "discover → locate → fix → verify" stability loop.