What is mobile app analytics, and how do you build it in Metabase?

Mobile app analytics covers the full arc of an app: store impressions and listing views, installs, what people do once inside, subscriptions, revenue after platform fees, and the crash and rating quality underneath it all. The structural problem is that Apple and Google each report their own store in their own shapes and their own vocabulary, and neither will ever show you both. A unified install-to-proceeds view across stores only exists if you build it — and once the data is in a warehouse it can also be joined to ad spend and in-app behavior, which no store console can do.

What does mobile app analytics measure?

• How many people see the listing, how many open it, and how many install — per store, per country, per source.
• Which store converts better, and whether the gap is real or a definition artifact.
• What the platforms actually keep: proceeds against gross sales, blended across the 15% and 30% tiers.
• How subscriptions move — trials, starts, renewals, cancellations — across both stores at once.
• Whether installs stick: net install growth against uninstalls, and retention from your own event data.
• Whether a release broke something: crash rate and ANR rate read against install and rating trends.
• What an install costs and what it returns — the join of ad spend, attribution, and store proceeds that no console offers.

Which tools feed mobile app analytics?

The boundary is worth stating plainly, because it decides which tool answers which question: store data ends at the install. Both stores publish aggregated counts with no identifier to join on, so nothing that happens inside the app can be traced back to a download. Attribution supplies the campaign that produced the install, product analytics supplies the behavior after it, and RevenueCat supplies subscription revenue normalized across both stores.

What shared data models should you build?

Three tables carry both stores. Keep a store column on each so Apple and Play rows coexist, and leave store-specific columns store-specific rather than forcing them into a shared name that means two things.

• app_store_daily_metrics — one row per day per app per store per dimension slice (country, device, source). Apple contributes impressions, product page views, first-time downloads, redownloads, units, sales and proceeds; Play contributes store listing visitors and acquisitions, device and user installs, uninstalls, and proceeds. This is the acquisition and money core.
• app_store_subscriptions — one row per day per app per subscription product: active subscriptions, new subscriptions, cancellations, renewals, trial starts, and proceeds, with Apple's product IDs and Play's base plan IDs preserved.
• app_store_quality — one row per day per app per version: Apple's sessions, crashes, crash rate, average rating and rating count; Play's daily crashes, ANRs, and average rating. Only meaningful read against install growth.

The rules that keep those three tables trustworthy:

• Apple's first-time downloads and redownloads stay in separate columns — conflating them inflates acquisition and buries a retention problem.
• Pick one Play install definition, document it in the model, and stick to it.
• Apple's Analytics Reports and its Sales & Trends / Finance reports are different pipelines with genuinely different numbers. Never sum them as one revenue source; use the funnel from one and the money from the other, each labeled.
• Normalize Play earnings to one reporting currency with the currency_conversion_rate column, keep refunds as the negative rows they arrive as, and report gross and net separately.
• Play writes per-dimension files — a country file and a device file, but no country-by-device file. Don't promise a cross-tab the source cannot produce.
• Apple's Standard reports omit Campaign, Source Info, and Page Title; only Detailed reports carry them. An empty conversion-by-campaign model usually means the wrong report tier was requested.

Which mobile app metrics matter most?

• App store conversion rate— Apple's page views to downloads, Play's visitors to acquisitions. Defined per store, compared with a caveat.
• Platform fee rate — the effective commission, derived from proceeds against sales rather than the rate card.
• Conversion rate — the generic funnel-step pattern the store metrics specialize, and the one to reach for once the funnel continues past the install in your own data.
• Activation rate — the first in-app milestone after install, from your event tables. The store cannot see it.
• Churn rate — cancellations over active subscriptions, per store product or normalized cross-store.
• MRR — recurring subscription revenue, cleanest when it comes from one normalized subscriber model.
• ARPU — proceeds per active user, which needs the store's money next to your own active-user counts.
• LTV — only meaningful once acquisition cost from attribution sits in the same warehouse as store proceeds.

How do you connect tools to Metabase?

Metabase reads SQL databases and warehouses, or CSVs loaded with the CLI. So the work is getting the store report files somewhere Metabase can query.

1. Scheduled exports — Apple's four-hop asynchronous Analytics Reports flow (request, wait one to two days, list instances, download gzipped tab-delimited segments), and a gcloud storage copy of Play's monthly stats/ and earnings/ CSVs. Poll Apple on a schedule: an unpolled request is marked stopped due to inactivity and the gap cannot be backfilled.
2. Connectors — Fivetran has official connectors for both stores, with fivetran/dbt_apple_store, fivetran/dbt_google_play, and the combined fivetran/dbt_app_reporting package for cross-store models. Airbyte's App Store source was deprecated in 2024 and it has no official Play source.
3. CLI for a first pass — download a month of files and run mb upload csv to see whether the dashboard earns a pipeline. Not a standing solution: both stores restate recent data, and Play rewrites the current month's file every day.

There is no useful MCP route on either store — neither vendor ships a server, and Play's community servers cannot see the bulk reports where installs and revenue live. The app stores category walks through both export paths in detail.

Which dashboards should you build first?

• App store performance — conversion, installs, and proceeds by store and country. Needs only app_store_daily_metrics, so it ships on day one.
• Subscription analytics — starts, renewals, cancellations, and trial-to-paid by product.
• Product retention — what happens after the install, built on your own event data rather than store reports.
• MRR and churn & retention — the subscription business view, once cross-store subscriptions are normalized.

Common mistakes

Related

Integrations

Analytics

Dashboards

FAQ