48.4k Log in Get started
Overview · Integrations

How do you analyze App Store and Google Play data in Metabase?

Apple and Google each report their own store, in their own shapes, using their own vocabulary — and neither console will ever show you both. A unified install-to-proceeds view across stores only exists if you build it. In Metabase, that means landing both stores' report files in a SQL warehouse under one model — daily store metrics, subscriptions, and quality — and then, because the data is finally in a warehouse, joining it to ad spend and in-app behavior, which no store console can do.

TL;DR — Neither store has an official MCP server or a friendly API. Apple's Analytics Reports API is asynchronous (request, wait 1–2 days, list instances, download gzipped TSV segments); Play's installs, conversion, and earnings are monthly CSVs in a Cloud Storage bucket, with only vitals available over an API. Fivetran connectors plus dbt_app_reporting are the shortcut. Whichever route you take, name your install definition before you put both stores on one chart.

Which tools does this cover?

  • App Store Connect — daily store analytics rows, downloads and redownloads by source type, product page views and impressions, purchases and proceeds
  • Google Play Console — daily store report rows, store listing visitors and acquisitions, installs and uninstalls by dimension, earnings and refunds

The stores are only the acquisition end of the mobile stack. For the pieces on either side, see RevenueCat for cross-store subscription revenue normalized into one subscriber model, AppsFlyer for install attribution and campaign-level spend, and Amplitude for what people do inside the app once they're there.

What is the shared app store data model?

Three tables carry both stores. Each keeps a store column so Apple and Play rows coexist, and store-specific columns stay store-specific rather than being forced into a fake shared name.

TableGrainCarries
app_store_daily_metricsOne row per day per app per store per dimension slice (country, device, source)Apple: impressions, product page views, first-time downloads, redownloads, units, sales and proceeds. Play: store listing visitors and acquisitions, device and user installs, uninstalls, proceeds. The acquisition and money core.
app_store_subscriptionsOne row per day per app per subscription productActive subscriptions, new subscriptions, cancellations, renewals, trial starts, proceeds. Apple adds product IDs; Play adds base plan IDs.
app_store_qualityOne row per day per app per versionApple: sessions, crashes, crash rate, average rating, rating count. Play: daily crashes, ANRs, average rating. Read against install growth, never alone.

Modeling rules that save arguments later:

  • Keep Apple's first-time downloads and redownloads in separate columns. Conflating them inflates acquisition and hides a retention problem.
  • Pick one Play install definition and document it. daily_device_installs, daily_user_installs, install_events, and active_device_installs all exist and all mean different things.
  • Never sum Apple's Analytics Reports revenue with Sales & Trends or Finance report revenue. They are different pipelines with genuinely different numbers — pick one for the revenue card and label it.
  • Normalize Play earnings to one reporting currency in the model using the currency_conversion_rate column, and keep refunds as the negative rows they arrive as, reporting gross and net separately.
  • Derive commission from proceeds versus sales rather than the headline rate. The 15% and 30% tiers blend, so the effective platform fee rate rarely matches either.

How do you connect app store data to Metabase?

Metabase reads SQL databases and warehouses, or CSVs uploaded through the CLI — so every route below is really a question of who runs the export.

  1. Scheduled export route — the honest baseline. For Apple, script the four-hop Analytics Reports flow: POST an ONGOING report request, wait one to two days for first generation, list instances by granularity, download and gunzip the tab-delimited segments. For Play, copy the current month's stats/ and earnings/ files out of gs://pubsite_prod_rev_<developer-id> with gcloud storage (gsutil is deprecated), then append and dedupe on date plus dimension.
  2. Connector route — Fivetran has official connectors for both stores, with fivetran/dbt_apple_store and fivetran/dbt_google_play modeling each, and fivetran/dbt_app_reporting unioning them into cross-store models. BigQuery Data Transfer Service also offers a Play connector if BigQuery is your warehouse. Airbyte is not a path here: its App Store source was deprecated in 2024 and it has no official Play source.
  3. CLI route for a first look — download a month of report files by hand and load them with mb upload csv. Good for proving a dashboard is worth building; not good as a standing pipeline, because both stores restate recent data and Play rewrites the current month's file daily.

There is no MCP route worth recommending on either store. Apple has no official server and the most-cited community one is archived; Play's community servers wrap the Developer API and cannot see the bulk statistics or earnings reports where installs and revenue actually live.

What can you analyze across both stores?

  • App store conversion rate— Apple's product page views to first-time downloads, Play's store listing visitors to acquisitions. Same question, two vocabularies; define each once.
  • Platform fee rate— effective commission derived from proceeds against sales, per store and per month.
  • Conversion rate — the generic funnel-step pattern the store metrics specialize; useful when you extend the funnel past the install with your own data.
  • Churn rate — cancellations over active subscriptions, per store product.
  • MRR and ARPU — recurring revenue and revenue per user, cleanest when subscriptions come through RevenueCat rather than two report formats.
  • LTV — only meaningful once acquisition cost from attribution sits next to store proceeds in the same warehouse.
  • Net install growth — installs against uninstalls, the line acquisition dashboards usually leave off. Play reports uninstalls; Apple does not.
  • Quality against growth — crash rate and ANR rate plotted on the same timeline as installs and ratings, so a release regression shows up as the acquisition dip it causes.

Which dashboards should you build?

  • App store performance — the cross-store home: impressions and visitors, conversion, installs, proceeds, by country and store.
  • Subscription analytics — starts, renewals, cancellations, and trial-to-paid by product.
  • Product retention — what happens after the install, from your own event data rather than the stores.
  • MRR and churn & retention — the subscription-business view, once store subscriptions are normalized.

Common mistakes

Comparing Apple downloads to Play installs without saying which counter you used.→ Apple counts first-time downloads per account; Play offers device installs, user installs, install events, and active device installs. Name the pair in the column names and caveat the card — otherwise the first person to check the consoles will declare the dashboard wrong.
Summing Apple's Analytics Reports revenue with Sales & Trends or Finance figures.→ Different pipelines, genuinely different numbers. Use Analytics Reports for the acquisition funnel and the finance reports for money that reconciles to payouts, and label every revenue card with its source.
Expecting the Play Developer Reporting API to return installs or earnings.→ It returns vitals only — crash rate, ANR rate, slow starts. Growth and revenue are monthly CSVs in a Cloud Storage bucket. Two systems, no overlap, and no single API that returns Play revenue.
Letting Apple's report request go unpolled.→ A request that stops being polled is marked stopped due to inactivity, and the resulting gap cannot be backfilled through an ONGOING request. Poll on a schedule and alert on a missing day.
Treating the last few days as final.→ Store reports lag and get restated; Play rewrites the current month's file daily and publishes earnings by the 5th of the following month. Hold trend cards back a few days and state the cutoff on the dashboard.
Promising a user-level funnel from store data.→ These are aggregated counts with no identifier to join on. The store data ends at the install; everything after it comes from your own analytics.

Analytics

Mobile app analyticsOverviewRevenue analyticsOverviewE-commerce analyticsOverview

Integrations

App Store Connect + MetabaseApp storesGoogle Play Console + MetabaseApp storesRevenueCat + MetabaseCross-store subscriptionsAppsFlyer + MetabaseMobile attributionAmplitude + MetabaseIn-app product behavior

Dashboards

App store performanceDashboardSubscription analyticsDashboardProduct retentionDashboard

FAQ

Can Metabase pull data from App Store Connect or Google Play?
Not directly — Metabase reads SQL databases and warehouses, or CSVs loaded with the Metabase CLI (mb upload csv). The store data gets there first: Apple's Analytics Reports API generates gzipped tab-delimited segments you download on a schedule, and Google Play writes monthly CSVs into a Cloud Storage bucket you copy with gcloud storage. Land both in a warehouse and every dashboard afterwards is ordinary SQL.
Is there an official MCP server for either store?
No — neither Apple nor Google ships one (verified July 2026). For Apple, the most widely cited community server (JoshuaRileyDev/app-store-connect-mcp-server) is archived with no release since September 2025; maintained community alternatives such as SardorbekR/appstore-connect-mcp and TrialAndErrorAI/appstore-connect-mcp do cover the Analytics Reports flow but are unaffiliated, and one npm name collides with an unrelated repo. For Play, the community servers wrap the Play Developer API — releases, listings, reviews, purchase status — and cannot reach the bulk statistics or earnings reports at all, so an MCP route wouldn't get you installs or revenue even if you trusted it. Scheduled exports you own are the dependable route on both stores.
Why is Apple's export so much work compared to a normal API?
Because the Analytics Reports API is asynchronous: you POST a report request, wait one to two days for the first generation, list the reports and then the instances by granularity, and finally download gzipped tab-delimited segments — sometimes several per instance — and concatenate them. It also has a trap: a request that stops being polled is marked stopped due to inactivity, and the resulting gap cannot be backfilled through an ONGOING request. Automate the four hops once, alert when a day is missing, and keep the one-time snapshot you requested at setup as your history anchor. Full script on the App Store Connect guide.
Which API returns Google Play installs and revenue?
None of them. Play splits its data in two: the Play Developer Reporting API covers vitals only — crash rate, ANR rate, slow starts — while installs, store listing conversion, and earnings live as monthly CSVs under stats/ and earnings/ in a Cloud Storage bucket (gs://pubsite_prod_rev_<developer-id>). There is no single API that returns Play revenue. See the Google Play guide for the copy-and-load script.
Can I compare Apple downloads and Play installs directly?
Only with a stated definition. Apple counts first-time downloads per account; Play reports several different install counts — daily_device_installs, daily_user_installs, install_events, active_device_installs — that measure genuinely different things. Pick the closest pair, name the two columns explicitly in the model, and put the caveat on the card. This is the number-one reason cross-store dashboards get argued with. Track the funnel step itself as app store conversion rate, defined once per store.
What is the least-effort way to get both stores in a warehouse?
Fivetran has official connectors for both App Store Connect and Google Play, with dbt packages on top: fivetran/dbt_apple_store, fivetran/dbt_google_play, and fivetran/dbt_app_reporting, which unions the two into cross-store models. Airbyte is not an option here — its App Store source was deprecated in 2024 and it has no official Play source. Rolling your own is entirely doable, it is just the async flow plus a scheduled bucket copy.
What can't store data tell me?
Anything that happens after the install. Both stores publish aggregated reports — counts by date, country, device, and source — with no identifier to join on, so there is no user-level funnel from this source. In-app behavior comes from your own product analytics (Amplitude), install attribution from AppsFlyer, and cross-store subscription revenue from RevenueCat. The mobile app analytics overview covers how the pieces line up.