Apple App Store
Source App Stores

Apple App Store

Downloads, proceeds and App Store performance, pulled on a schedule into a database you own.

Apple offers no native export from App Store Connect to any data warehouse — so Insightlytics operates that pipeline for you. We pull Sales and Trends and app analytics reports — units, proceeds, downloads and re-downloads, impressions and product-page views — daily through the App Store Connect API, then clean, normalize and model them into data models where downloads have one definition and proceeds are real money. You get the tables and the accumulated history; we run the requests, the parsing, the re-ingestion and the monitoring. Everything is written to a database you own — BigQuery today, with more warehouses on the roadmap.

What we ingest

Apple publishes no warehouse export, so there is no table to point at — only reports, requested and parsed on a schedule. These are the ones we land.

  • Sales and Trends reports API

    The daily TSVs: units, proceeds and territory splits, downloaded and parsed into tables instead of landing in someone’s inbox.

  • Subscription reports API

    Active subscriptions, renewals and cancellations where your apps have them, on the same daily cadence.

  • App analytics reports API

    Impressions, product-page views and downloads, generated asynchronously by Apple and collected once each report is ready.

  • Report format version Recorded per run

    Apple revises its report formats. The version is stored with every ingest, so a column that moved is a pipeline fix rather than a broken data model.

There is only one route here, and making it durable is the work — covered further down, in how we work with App Store data.

The problems we solve

App Store Connect gives you report files, not answers — and the files have sharp edges of their own. These are the ones every mobile team hits, and the ones this pipeline is built around.

Can you export App Store Connect data to a warehouse?

Not natively — Apple offers no warehouse export at all. Its reporting is delivery-based: request a report, wait for generation, download a gzipped TSV, parse it. That’s fine for a monthly export and hopeless as a reporting backend, which is why most teams’ App Store history lives in a folder of files nobody queries.

We invert the model: the API loop — request, download, parse, load — runs daily as a managed pipeline, the files become tables in your own database, and every question after that is just SQL.

Downloads, re-downloads, units — which number is right?

It depends on the question: growth wants first-time downloads, engagement cares about re-downloads, finance reconciles against units. App Analytics and Sales and Trends mix these flavors freely, and most cross-tool discrepancies are two surfaces picking different flavors without saying so.

The data models keep them as separate named columns, so each question has its own honest answer — and the cross-store alignment step gives them the same shapes as your Google Play models.

Why don’t proceeds equal price times units?

Between the sticker price and the proceeds row sit Apple’s commission, the territory’s price tier and the local currency. A spreadsheet that multiplies price by units will disagree with the report every single day.

The pipeline normalizes proceeds into one reporting currency under a recorded FX policy, which makes revenue a number instead of a negotiation.

Why did yesterday’s App Store report change?

A day’s Sales and Trends data completes about two days after its date, and Apple occasionally regenerates reports after that. Pipelines that ingest each file once drift from App Store Connect, and nobody notices until a finance review.

Ours re-ingests trailing days and replaces regenerated files, so your database converges on the settled numbers.

Why are App Analytics sessions so low compared to downloads?

Usage metrics — sessions, active devices — only include users who opted in to share analytics with developers, so they are structurally lower than reality, and the opt-in share isn’t constant across markets or time.

The data models label opt-in metrics explicitly, so trend analysis stays valid while absolute comparisons carry their caveat with them.

How we work with App Store data

There is no export to enable here — the App Store Connect API is the route, and making it durable is the work.

Every day we request the Sales and Trends TSVs and the asynchronously generated analytics reports, download and parse them, and land the results as tables. Because a day’s data completes about two days after its date — and Apple occasionally regenerates reports — trailing days are re-ingested until they stop changing, so your database converges on the settled numbers instead of freezing the first draft.

The discovery call settles the scope — which apps, territories and report types matter to you — and access is one read-only App Store Connect API key. From there, running the pipeline is our job: no report downloads, no format-version tracking, no parsing scripts to maintain.

Delivered to a database you own

Every table — raw and modeled — is written to your own database, under your billing and your access controls. Our access is read-only, and if we part ways, everything stays with you.

  • BigQuery BigQuery Your data models are built in your own BigQuery project — our access is read-only, and the tables are always yours.

BigQuery is the supported database today. If you run a different warehouse, tell us — the roadmap is driven by requests.

How current the data stays

Data models rebuild every day. Where a platform restates recent numbers after the fact, we re-read those days rather than freezing the first version we saw.

Refresh

Daily, after Apple publishes. Trailing days are re-ingested until they stop changing, and regenerated reports replace their originals.

Backfill

App analytics history loads via Apple’s one-time snapshot mechanism; Sales and Trends backfills as far as your account’s reports reach. Everything accumulates forward under your retention.

Monitoring

Every run is checked for freshness, volume and report-format drift. Apple’s format versions are tracked, and changes are absorbed in the pipeline before they reach your data models.

What lands in your database

Not raw API responses — data models: named, documented tables at a stated grain, rebuilt every day and ready to query. Each one has its own page.

The shipped data models are the starting point, not the ceiling. When your questions need a different shape — another grain, another split, a join against another source — we build additional models for your stack as part of the engagement.

App Store data, without the monthly CSV ritual.

Tell us which apps and reports your team actually uses. We’ll map what the App Store Connect API exposes and how far your account’s history reaches.

Free discovery call · No commitment — leave with a starting point