App Store analytics reference

Which revenue number this is

Apple publishes two revenue figures, and they disagree. Everything Broctic shows today is the first one.

Broctic ingests Sales and Trends. Financial reports are not ingested yet; the store keeps a basis column so they can be, and the two are never added together — a fiscal month and a calendar month overlap in a way that double-counts.

Proceeds, customer spend, and Apple's cut

• Customer spend — what buyers paid, before Apple's commission.
• Proceeds — what Apple pays out, after their commission and before any cost of yours. This is the headline figure.
• The gap between the two is Apple's commission plus, in storefronts where the customer price includes it, sales tax or VAT that Apple remits. It is shown rather than assumed, because the rate depends on the programme you are in — 15% under the Small Business Program, 30% standard — and a constant would be wrong for most accounts.

The word is proceeds, not profit and not revenue. Calling it profit would ignore every cost you have; calling it revenue invites confusion with what customers paid.

Units: four different things in one column

This is the single biggest way an App Store dashboard misleads. Apple counts a first download, a re-download, an app update and an in-app purchase in the same Units column, separated only by a Product Type Identifier. An app with a healthy release cadence can report five to ten times its real download count, and most of the excess is a measure of how often you shipped.

Broctic buckets every row on the way in and keeps Apple's raw identifier beside the bucket. Nothing in the console adds them back together: "downloads" always means first-time downloads.

Trials versus paid subscriptions

Subscription transactions arrive as units at a price. A free trial or an introductory offer is a subscription unit at zero, so Broctic reports trials and paid subscription units separately, and one-off in-app purchases separately again — recurring revenue and one-time revenue behave nothing alike, and a "subscribers" figure that includes free trials is the number every subscription app flatters itself with.

Because these are transactions rather than a subscriber roster, they answer "how many trials started this week", not "how many people are subscribed right now". Active counts, churn and cohorts come from Apple's subscription reports, which are not ingested yet.

Refunds

Refunds are reported as their own count and are not netted out of the unit counts silently. A refund can land days or weeks after the sale it reverses, so a refund rate over a short window is a lagging figure — which is exactly why it is shown as a rate against the same window rather than adjusted into the totals.

Currencies

The App Store bills in the storefront's currency, so an account earns in a dozen of them. Broctic converts per day, at that day's European Central Bank reference rate, and shows the per-currency breakdown next to the converted total.

• Per day matters: a month of sales converted at one closing rate is a different number from the same sales converted daily, and only the second reconciles with what actually happened.
• The ECB quotes about thirty currencies. Anything it does not quote is reported separately, in its own currency — never approximated and never dropped, because dropping it understates revenue with no sign that anything happened.
• The raw per-currency rows are kept, so any blended figure can be taken apart.
• The display currency selector at the top of Analytics changes the presentation, not the underlying data.

Freshness: what 'yesterday' means

Nothing here is live. The console reads Broctic's store, never Apple at page load, and the honest question it has to answer is has Apple published yesterday yet?

• Apple's dates are Pacific dates. Sales close at midnight Pacific and publish by 08:00 Pacific the next morning. Computing "yesterday" in UTC is wrong for eight hours a day and reports Apple as late when it is not.
• Apple answers 404 both for a day it has not published and for a day with genuinely no sales, and nothing in the response separates them — so the clock does. Before 08:00 Pacific the console says not published yet; after it, Apple reported no sales, which is a real zero.
• A day never successfully fetched is drawn as a gap, not a zero. A zero and an absence look identical on a chart and mean opposite things.
• Every sync outcome is recorded per day, so the freshness card can say how far behind the data is, how many gaps exist, and when the last run happened — including its error, if it failed.

Time ranges and comparisons

The range selector offers the last 7 days, 30 days, 90 days and 12 months, and it scopes everything on the page — one filter row above all the cards rather than a control per card, so no two figures on screen can be describing different fortnights.

Changes are stated against the immediately preceding window of the same length. When the previous window was zero, the change is shown as nothing at all rather than as an infinite increase: a first sale is better stated as a first sale.

Breakdowns

What Apple does not give us (yet)

• Impressions, product page views, installs by source, retention and crashes come from App Store Analytics reports — a different API where you request a report and Apple produces it asynchronously over hours or days. Not ingested yet.
• Active subscribers, churn and cohorts come from the subscription reports. Not ingested yet.
• Financial reports — the authoritative, post-commission, fiscal-calendar figure. Not ingested yet.
• Nothing about what happens inside the app. That is what product events are for.