Every tab, explained honestly

Read this first: the fine print that applies everywhere

• Days are UTC. Every chart, cohort, and "today" uses UTC day boundaries. If you live far from UTC, "today" rolls over at an odd local hour — that's why an evening spike can land on "tomorrow".
• DAU = distinct users with at least one event that UTC day. Not sessions, not opens — one user counts once no matter how active they were.
• Internal users are excluded from every metric by default. Simulators are flagged automatically at ingestion; you flag your own devices from the Live tab. A toggle lets you include them when you want to see your own testing.
• Only instrumented events exist. There is no autocapture. If the agent didn't track it, it isn't in any chart — by design.
• Most windows are the last 30 days unless the card's title says otherwise.

Live — the real-time feed

Every event, as it arrives: time, user, event name, screen, country, app version, OS. Revenue events appear inline, highlighted, with type and amount. Paying users carry a PRO badge (reconciled daily against RevenueCat entitlements, so the badge means currently entitled). Click any user to filter the feed to just them and see their trail through the app.

Clicking a user also reveals mark as internal — the button that keeps your own devices out of every metric. Do this for yourself on day one. There's a pause button when the feed moves too fast.

Overview — the health check

Four stat cards up top: Active today (DAU so far this UTC day), Avg session (30d), Paying users (currently entitled, per the daily RevenueCat reconciliation), and Revenue (30d). Below them:

• Daily active users — 30 days, with annotations: click a day to pin a note ("2.1 released", "Reddit post") so future you knows why the line moved.
• Average session duration — 30 days. Session length comes from event timestamps within a session; a session ends when the app is backgrounded.
• Conversion funnel — onboarding → paywall → trial → purchase. Distinct users per step in 30 days, each step shown as % of the first step and % of the previous step. Steps are the standard events, which is why the agent instruments those exact names.
• Most common screens — where users actually spend time.
• Breakdowns by country, app version, and OS version (active users, 30d). The app-version breakdown is how you watch an update roll out.
• Landing card — if a landing page is linked to this app: the page-view → store-click → install funnel, per-page views and visible time, countries, referrers, and ?ac= campaigns. Installs come from App Store data, so the web→install step is honest, not inferred (see the web tracking guide for what the snippet can and can't see).

Lifecycle — who makes up each day's actives

The 30-day stacked chart splits every day's users into four kinds:

• New — first ever activity today.
• Returning — active today and yesterday.
• Resurrecting — back today after a gap.
• Dormant — active yesterday, gone today (drawn below the zero line: it's the outflow).

Cohorts are event-anchored: a user exists here because they did something, so ghost records (e.g. someone who only appears via a payment) never inflate the bars.

Retention — do they come back?

A cohort grid: each row is the users first seen on a given day (or week — toggle between 14-day daily and 8-week weekly views). D0 is their first day; D1, D2, … show what percentage of that cohort was active again that many days later. Hovering a cell shows the raw fraction (e.g. "4/13 users"). The Mean row is weighted by cohort size, so big cohorts count more. Each row's most recent cell is faded — that period isn't over yet, so its number is still moving.

Revenue — the money, joined to the people

Everything here exists because the SDK and RevenueCat share one user ID — each purchase belongs to a person you can see behaving.

• New vs renewals: "new" is first purchases, non-renewing purchases, and trial conversions; "recurring" is renewals. The split matters — renewals are momentum from past decisions, new revenue is what your current work produces.
• Imported history: revenue from before the webhook was connected can be imported so charts don't start at a cliff; imported days carry their note (e.g. "2 new + 1 renewal"), and days without a split report zero new — conversion stays honest, never inflated.
• Daily trend — revenue vs installs vs purchases: installs prefer real App Store download numbers when the App Store Connect connection exists; otherwise the SDK's first-seen users are the fallback (labeled accordingly).
• Install → purchase conversion per day, plus monthly downloads & revenue — where RevenueCat gross and Apple's actual net proceeds share one chart so you can see the gap (why they differ).
• Revenue heatmap (week × weekday), by product, by country, and the latest transactions list — trials, conversions, cancellations included.

P&L — is this app actually profitable?

A monthly spreadsheet: revenue on top, your real costs underneath, net at the bottom. The revenue line uses a strict source hierarchy — each month shows the most truthful number available:

1. Bank received — what Apple actually transferred. You enter it by clicking the cell; it's final truth and overrides everything.
2. Apple net (actual) — from Apple's monthly financial reports, net of Apple's cut, when the App Store Connect connection exists.
3. Estimate — RevenueCat gross × 0.75, used only while a month has neither of the above (typically the current month). The 0.75 reflects what historically survives VAT-inclusive pricing, Apple's commission, currency conversion, and withholding — an estimate, clearly marked as one.

Each month's cell is labeled with which source it used, so you always know whether you're looking at truth or estimate. Costs can be one-off or recurring, and shared costs (your Mac, your developer account) count against every app's P&L.

Config — change the app without shipping an update

Remote switches your app checks on every open — changes reach users on their next app open, no App Store review. Each switch only has an effect once the app has the matching hook built in (the integration wires the standard ones; older builds simply ignore switches they don't know):

• Rating prompt: turn App Store review requests on or off, set how many sessions before the first ask and the cooldown between asks. When off, nobody is ever asked. Apple adds its own cap on top (roughly 3 asks per user per year).
• Force update: set a minimum required version; the SDK exposes it to the app, which shows its own "please update" UI. Empty = never.
• Feature flags: named on/off switches for whatever the app has wired to them.
• SKAdNetwork conversion values: which events signal install quality to ad networks, retunable without shipping a build.
• Raw JSON for anything advanced.

Insights — the Monday brief and the anomaly watch

Every Monday morning, an AI analyst reads the week's data across all your apps and writes a brief: TL;DR, highlights, concerns, revenue, and what to focus on — the exact format is in the full sample. It flags instrumentation bugs when the numbers smell wrong, and it never invents data.

Above the briefs, Anomalies — last 14 days checks DAU, revenue, and refunds daily against each metric's own recent baseline and lists the days that deviated significantly, with the observed vs expected value. An empty card means nothing unusual — quiet is good.

Questions this page didn't answer

"Why is this number different from App Store Connect / RevenueCat?" and friends live in the FAQ & troubleshooting.