Metrics

The Metrics page (/metrics) is the full read of your subscription business: the MRR chart, App Store reach, revenue totals, the trial funnel, a year-to-date chart and MRR broken down by product and country. This page lists every tile, where its number comes from, and the exact formula behind it. If the code changes, this page changes with it.

Where the numbers come fromCopy Anchor Link

RevenueHog reads two kinds of Apple data, and they have different strengths.

Apple's daily reports (Sales and Trends, plus the Subscription and Subscription Event reports, pulled with your App Store Connect API key) are the authoritative once-a-day record: revenue per day, and a daily snapshot of your active subscriptions per product, state and country. They lag about one day, and on import they reach back about a year. That year is Apple's daily-report limit, not a RevenueHog limit.

App Store Server Notifications V2 (once wired, see server notifications) are the real-time stream: individual purchase, renewal, cancellation and refund events, each signed by Apple. They power the live feed, per-customer LTV, the intraday part of MRR, the live edge of revenue totals, and the cancelled-trial adjustment described below, which reports alone cannot make. Stripe events and Google Play notifications feed the same stream for those sources.

There are two kinds of metric, and keeping them apart matters:

Mixing the two up is the most common way MRR dashboards go wrong, so every metric below says which it is.

Scope and periodCopy Anchor Link

The page honors both topbar controls:

• App filter (?app=): every tile is recomputed for that one app, except the four subscriber read-model tiles (NET MRR, ACTIVE CUSTOMERS, NEW CUSTOMERS, ARPU) and the MRR BY PRODUCT / MRR BY COUNTRY breakdowns, which are org-wide only and are hidden while an app is selected. The footnote then reads "Product & country breakdowns are org-wide. Clear the app filter to see them."
• Period (?period=24h|7d|30d|90d, default 30d): sets the MRR chart span, the delta comparison point, the revenue window, the revenue-per-day bars and the funnel window. The YTD, all-time and ARR tiles do not depend on the period.

The header line reads Metrics · 30d, plus · filtered to one app when the app filter is set. The ↓ CSV link beside it downloads the revenue lines for the same scope (see exports).

MRRCopy Anchor Link

MRR is a level: the monthly recurring value of every subscription in a paying state on the most recent snapshot day, plus the intraday change from live events since that day.

Each subscription's price covers its whole billing period, so the price is divided by the period's length in months to get a comparable monthly figure, then multiplied by the subscriber count:

# for every subscription snapshot row in a paying state on the day:
row_mrr  = (price_per_billing_period / period_in_months) * quantity
MRR      = Σ row_mrr          # over all paying rows, all products
net MRR  = same, using proceeds (after Apple's commission) instead of price

# a row whose period_in_months is 0 or less contributes 0

# examples
$4.99/mo monthly       → 4.99 / 1  = $4.99 per subscriber
$39.99/yr annual       → 39.99 / 12 ≈ $3.33 per subscriber
$1.99/wk weekly        → 1.99 / 0.23 ≈ $8.65 per subscriber

Which subscriptions count as paying. The snapshot states active, intro_offer (paid intro offers), promo_offer and grace (billing grace period). Grace is in because Apple extended the term and the subscriber still has access.

Billing retry is out, deliberately. By the time a subscription enters retry the term has already ended and Apple has already cut access. It also keeps the two halves of RevenueHog consistent, because the live event stream drops MRR at the same moment (the EXPIRED and GRACE_PERIOD_EXPIRED notifications). Counting retry as paying made the snapshot and live MRR disagree by exactly the retrying subscriptions.

Free trials are excluded from MRR entirely. They contribute $0 and are counted as their own metric.

Live MRR. The headline value is the snapshot MRR on the anchor day plus the net monthly-recurring change from live server notifications received after that day:

headline MRR = snapshot MRR (anchor day) + live intraday MRR delta

Only the headline moves. The chart series stays snapshot-derived. The same live value appears in the Overview MRR tile, the apps table and the feed header, so the surfaces agree.

Delta. The ▲ +x.x% / ▼ x.x% beside MRR compares the headline value with the gap-filled snapshot MRR one period earlier:

MRR delta % = (headline MRR − MRR at (anchor day − period days)) / MRR at that day × 100

When the prior value is zero or less (a newly launched product), the delta is absent instead of a misleading +∞.

Gap days, anchors and deltasCopy Anchor Link

Apple's reports lag about a day, so "today" usually has no snapshot yet. All level metrics are therefore anchored to the most recent day that has a snapshot. Per-app and per-product views anchor to the same org-wide day, so drill-downs always agree with the dashboard they came from.

Subscriber levels persist on days Apple did not report: a missing day does not mean zero subscribers. Daily level series therefore carry the last observed value forward across gaps (last observation carried forward, LOCF):

day        reported   series value
07-01      $1,204     $1,204
07-02      (no rows)  $1,204   ← carried forward, not zero
07-03      (no rows)  $1,204   ← carried forward
07-04      $1,310     $1,310

Days before the first observation are 0. Flow series (new customers, revenue per day) are the opposite: a missing day really is zero and is never filled.

Deltas compare the current level against the gap-filled level one window earlier. The generic delta rule, used by every relative delta on the dashboard:

delta = (current − prior) / prior      # null when prior ≤ 0

Per-product deltas are built from each product's own gap-filled series, so a day Apple skipped for one product cannot fake a jump.

App Store reach tilesCopy Anchor Link

A row of four tiles appears only once Apple has delivered App Store analytics for the current scope. Until then it is hidden, rather than showing a row of zeros.

These come from Apple's Analytics Reports, which run about two to three days behind live. See data freshness.

Stat tilesCopy Anchor Link

ACTIVE SUBSCopy Anchor Link

ACTIVE SUBS = Σ quantity over paying-state snapshot rows on the anchor day
subtitle    = ACTIVE SUBS − ACTIVE SUBS at (anchor day − period days), shown as "+N / period"

IN TRIALCopy Anchor Link

IN TRIAL     = Σ quantity over "trial" snapshot rows on the anchor day
expire 48h   = trial starts (SUBSCRIBED, free-trial offer, last 45 days, newest 500)
               whose own expiry falls within the next 48 hours

On the Overview and Metrics tiles, IN TRIAL is the whole unexpired-trial count from Apple's snapshot. The Count cancelled trials as active preference only decides whether cancelled-but-unexpired trials are left out of the 48-hour expiry nudge. See trials and cancelled trials.

The expiry count is approximate: a converted trial can still be counted until its conversion event arrives. It is good enough for the amber nudge.

ARRCopy Anchor Link

ARR is annualized MRR, a run rate ("a year at today's MRR"), not a sum of signed contracts. On this tile it annualizes the live MRR shown above it, so the two always agree and the tile survives an app filter.

ARR = live MRR × 12

THIS YEAR, GROSS / YTD, ALL TIMECopy Anchor Link

THIS YEAR   = Σ proceeds_usd  over revenue days from Jan 1 (UTC) to today
GROSS / YTD = Σ gross_usd     over the same days
ALL TIME    = Σ proceeds_usd  over every revenue day ever reported, plus the live edge
Apple's commission (YTD) = GROSS / YTD − THIS YEAR

The days Apple's sales report has not reached yet (normally one or two) are filled from live events, the live edge, so a purchase made today counts right away. When Apple publishes the day, it moves from the live estimate to the report figure and the total barely moves. Live Stripe rows estimate proceeds with Stripe's blended processing cost, and live Google Play rows at the 15% service fee tier, until their daily rollup records the real figure.

AVG / DAYCopy Anchor Link

AVG / DAY = REVENUE (period total, see below) / period days    # 1, 7, 30 or 90

NET MRRCopy Anchor Link

NET MRR = Σ (proceeds_per_billing_period / period_in_months) × quantity   # paying rows, anchor day

Snapshot-only and org-wide: it does not include the intraday live delta.

ACTIVE CUSTOMERSCopy Anchor Link

ACTIVE CUSTOMERS = active (paying) subscribers + current trials

Here the trial count honors the Count cancelled trials as active preference: with it off (the default), cancelled-but-unexpired trials are subtracted from the current value.

NEW CUSTOMERSCopy Anchor Link

A flow, not a level: the count of brand-new subscription starts per day, summed over the trailing 30 days ending at the anchor day.

NEW CUSTOMERS = Σ quantity of Subscription Event rows with event type in
                { subscribe, trial_start, start_introductory_offer }
                over days (anchor − 29) … anchor
delta         = vs the 30 days before that

A first paid subscribe or a free-trial/intro-offer start counts. Renewals, trial conversions, plan changes and reactivations are existing customers and are excluded. Days with no starts count as zero and are never carried forward. The window is always 30 days, whatever the period control says.

ARPUCopy Anchor Link

ARPU = MRR / active subscribers     # snapshot MRR, org-wide; 0 when there are no paying subscribers

ARPU is 0, not a division error, when nobody is paying.

TRIAL CONVCopy Anchor Link

trials     = Σ quantity, event type in { trial_start, start_introductory_offer }, within the period
paid       = Σ quantity, event type in { trial_convert,
                                         paid_subscription_from_introductory_offer,
                                         upgrade_from_introductory_offer }, within the period
TRIAL CONV = min(100, paid / trials × 100)        # null (shown as a dash) when trials = 0

This is a same-window approximation: paid and trials are different groups of people, because a trial converts roughly one trial period after it starts. When conversions from an earlier, larger cohort land in a window with fewer new starts, paid can exceed trials, so the rate is capped at 100%. For the real cohort rate, see the Funnel.

RevenueCopy Anchor Link

revenue per day = Σ proceeds_usd over that UTC day's sales-report rows (+ live edge for unreported days)
REVENUE         = Σ revenue per day over the period's days ending today
REVENUE delta % = (REVENUE − prior equal-length window) / prior window × 100
                  # null when the prior window had no revenue

Daily revenue is the sum of developer proceeds (net of Apple's commission) across that day's sales-report rows. One-time purchases and annual prepays are included, which is exactly what MRR by definition hides. Periods end today, with the days Apple has not reported yet filled from the live edge.

The REVENUE / DAY card draws one bar per day over the selected window (up to 90), with the caption Nd · UTC and the last day's value underneath. Hover the label for "Net proceeds (after Apple's cut)". With nothing in the window it reads "No revenue in this window."

Funnel cardCopy Anchor Link

The FUNNEL / 30D card shows the App Store funnel for the same scope and period: Impressions, Product page views, Downloads, an optional Onboarding stage, Trials and Paid. Each bar is the share kept from the stage above, and the percentage beside each label is what dropped off. A negative drop-off (shown with a +) means the stage outran the one above it, which is real: a download needs no page view. When Apple has not delivered store analytics yet, the funnel starts at trials. Full details are on the Funnel page.

Year to date by monthCopy Anchor Link

Shown once there are at least two months of the current year. Each bar is a month's gross, with the net share filled inside it, on one shared scale, so the unfilled part above the net is Apple's commission. Hover a bar for Mar · gross $X · net $Y.

MRR by product and by countryCopy Anchor Link

Org-wide only (hidden with an app selected), from the anchor day's snapshot.

product MRR   = Σ (price / period_in_months) × quantity over that product's paying rows
product delta = (product MRR − its gap-filled MRR 30 days earlier) / that prior value
country MRR   = the same sum grouped by storefront country

MRR BY PRODUCT lists the top 10 products with N subs and the 30-day delta (absent for a product with no positive prior MRR). MRR BY COUNTRY lists every country.

Trials and cancelled trialsCopy Anchor Link

The trial count comes from Apple's daily snapshot, which lumps every unexpired trial into one bucket. Apple's reports carry no auto-renew breakdown, so the report alone cannot tell a live trial from one whose user already pressed cancel.

The live event stream can, for apps with notifications wired: a free-trial SUBSCRIBED whose latest lifecycle event is auto-renew being turned off (and whose trial period has not lapsed yet) is a cancelled-but-unexpired trial. With the Count cancelled trials as active preference off (the default, under Settings → Notifications → DATA), RevenueHog subtracts these where a current trial count feeds a metric that predates the separate callout: ACTIVE CUSTOMERS, the TRIALS column of the apps tables, and the expiring-in-48h nudge. Turning the preference on restores Apple's raw counting. The adjusted count is clamped at 0, since the report and the live stream run on different clocks.

ChurnCopy Anchor Link

Churn shows up two ways. In the live feed it is event volume: each individual churn event. On the Overview and apps tables it is a rate:

churn % (per app) = churned in the last 30 days / active subscribers 30 days ago × 100
churned           = Σ quantity of Subscription Event rows with event type in
                    { cancel, expire, canceled_from_billing_retry }
churn delta (pts) = churn % − the same rate for the 30 days before that
                    (that window divides by the level 60 days ago)

That is the standard definition, and the denominator matters: dividing by the current count would let subscribers who joined mid-window inflate the base, quietly flattering a growing app. It also means an app can exceed 100% when someone joins and churns inside the same window. That is real, and it is not capped. The rate is null (shown as a dash), not zero, for an app with no subscribers at the window start, including one whose snapshot history only begins mid-window.

From the live stream, churn events are: subscription expired, billing grace period expired without recovery, access revoked, and auto-renew turned off (cancellation intent: the subscriber keeps access until the period ends). From the report vocabulary: cancels, expirations, and billing retries that ran out. A renewal entering billing retry is churn risk and is deliberately not counted as churn. Most retries recover.

The trial funnel is intro-offer basedCopy Anchor Link

This is an Apple limitation worth being direct about: Apple's subscription-event report does not split free trials from paid introductory offers. One "start introductory offer" event covers both. So the funnel's trials are trial/intro starts, paid are intro → paid conversions (including converting early by upgrading), and the conversion percentage is paid ÷ starts within the selected period. It is a period ratio, not a tracked cohort rate: starts late in the window convert after it closes.

Because that ratio compares two groups of different people, the Funnel page also shows the real cohort for apps with server notifications wired.

Currency conversionCopy Anchor Link

Apple reports revenue per territory in local currencies. Each non-USD amount is converted using the daily ECB reference rate for that sale's date. Only when no published rate exists does a static approximate rate apply, and the row is flagged as estimated (the estimated column in the CSV export). An unknown currency with no rate at all contributes $0 rather than a fake 1:1 conversion, so an unconvertible row can never inflate totals.

All dashboard values are in USD. There is no currency selector.

Small Business ProgramCopy Anchor Link

Apple's daily reports state the Developer Proceeds column at your actual commission rate (Small Business Program members see the 85% share there, not the standard 70%), so every report-derived number here already reflects membership. RevenueHog applies no adjustment on top of Apple's figures, because none is needed: the proceeds column is stored as Apple states it, per proceeds currency, and never rederived from a price and a commission rate.

The live feed is the one estimated surface. Real-time events arrive through App Store Server Notifications, which carry the customer price but not your proceeds, so an event's detail page estimates proceeds from that price. Apple takes 30% by default, or 15% with the Small Business setting enabled (Settings → Preferences → SMALL BUSINESS). If you record your admission date alongside the setting, the reduced rate applies only to events on or after it, because enrolling does not retroactively repay old sales. That label cannot see territory taxes or year-two subscription rates, so treat per-event proceeds as an estimate; reports and payouts remain the truth.

Empty stateCopy Anchor Link

With no MRR, no active subscribers, no revenue and no subscriber data, the page shows "No data yet." and "Metrics appear after your first sync pulls Apple's subscription reports. Connect a key in Settings to get started." See Connect App Store Connect.

RelatedCopy Anchor Link