Metric

What is app store conversion rate?

Definition

App store conversion rate is the share of product page views that turn into installs, with impressions-to-page-views as the upstream step. It is not one metric across stores: App Store Connect reports impressions, product page views, and its own conversion rate, while Play Console reports store listing acquisitions against visitors. The data is aggregated by the stores with no user-level join, so treat it as a funnel of counts, never as something you can attribute to individuals.

Formula: Page-view conversion = first-time installs / product page views × 100; upstream, page views / impressions × 100

What data do you need?

  • Daily store metrics per app, store, and territory: impressions, product page views, first-time installs, re-downloads
  • Source dimension where the store provides it (search, browse, referral, web)
  • A stable app and store key so Apple and Google rows never blend silently
  • Release and store-listing change dates to annotate the trend
  • Subscription starts if the funnel continues past install

SQL pattern

Weekly store funnel by store, lag-trimmedPostgreSQL
WITH daily AS (
  SELECT
    store,
    app_id,
    date_trunc('week', metric_date) AS week,
    SUM(impressions) AS impressions,
    SUM(product_page_views) AS page_views,
    SUM(first_time_installs) AS first_time_installs,
    SUM(redownloads) AS redownloads
  FROM app_store_daily_metrics
  -- Both stores restate recent days. Cut the unstable tail or every
  -- Monday review will show a fake decline.
  WHERE metric_date < CURRENT_DATE - INTERVAL '3 days'
  GROUP BY 1, 2, 3
), rates AS (
  SELECT
    store,
    app_id,
    week,
    impressions,
    page_views,
    first_time_installs,
    redownloads,
    100.0 * page_views / NULLIF(impressions, 0) AS view_rate_pct,
    -- First-time installs only. Re-downloads are returning users and
    -- belong in a retention view, not in an acquisition conversion.
    100.0 * first_time_installs / NULLIF(page_views, 0) AS conv_pct
  FROM daily
)
SELECT
  week,
  store,
  app_id,
  impressions,
  page_views,
  first_time_installs,
  redownloads,
  ROUND(view_rate_pct, 2) AS impression_to_page_view_pct,
  ROUND(conv_pct, 2) AS page_view_to_install_pct,
  ROUND(conv_pct - LAG(conv_pct) OVER w, 2) AS conv_change_pp,
  -- 4-week trailing mean smooths feature placements and paid bursts.
  ROUND(AVG(conv_pct) OVER (
    PARTITION BY store, app_id ORDER BY week
    ROWS BETWEEN 3 PRECEDING AND CURRENT ROW
  ), 2) AS conv_pct_4w_avg
FROM rates
WINDOW w AS (PARTITION BY store, app_id ORDER BY week)
ORDER BY store, app_id, week;

Common pitfalls

Putting Apple and Google conversion on the same line as one number.→ The stores count different things — Apple's impressions include search-results appearances, Play's acquisition reporting is built on store listing visitors. Keep a store dimension and never sum the rates.
Counting re-downloads as conversions.→ Re-downloads are existing users reinstalling. Split first-time installs from redownloads; a device-refresh season can otherwise look like an acquisition win.
Reading the last two days of data as a trend.→ Store reporting lags and restates. Trim the unstable tail from trend charts and label the data-freshness date on the card.
Expecting to join store metrics to your own users.→ The stores deliver aggregated counts with no user identifier. Model the store funnel as its own layer and connect it to in-app behavior at the cohort level, by install date and territory.

Where does this metric apply?

This metric commonly uses data from Apple App Store Connect, Google Play Console, AppsFlyer, Adjust, plus any warehouse models built at the same grain.

Dashboards

Integrations

Metrics

Analytics

FAQ

Why does my store dashboard disagree with the store console?
Almost always definitions and time zones. Apple reports in a fixed time zone with its own conversion denominator; Play uses a different visitor basis. Recreate the console's exact definition once, note it on the card, and stop trying to make two different metrics match.
What comes after install in the funnel?
Install is the top, not the end. Continue into activation, trial start, and paid subscription — join app_store_daily_metrics to app_store_subscriptions by install date and territory, then read the result against ARPU and churn rate. The app store performance dashboard lays out the whole chain.
Can Metabase pull this from App Store Connect directly?
No — Metabase queries SQL databases and warehouses. Land the daily App Store Connect and Play Console reports in your warehouse on a schedule (or upload the CSV exports), then build the funnel on those tables.