Read this first — the fine print that applies everywhere
- Every chart is timezone-aware. Days and Monday–Sunday weeks bucket in the timezone chosen in the header's selector. Auto uses your browser's own zone; pick a fixed one instead and every day boundary, week boundary and "today" follows it.
- DAU = distinct users with at least one event that day, in the selected timezone. Not sessions, not opens; one user counts once no matter how active they were.
- The Internal switch controls what counts as real traffic. It hides two things by default: your own devices (mark them from the Live tab) and pirated or re-signed copies (flagged by Apple's own install check, see Growth). Flip it on to include them when you want to see your own testing. P&L is the one tab that ignores the switch; it always reads the app's complete revenue history (see Revenue).
- Only instrumented events exist. There is no autocapture. If the agent did not track it, it is not in any chart, by design.
- Most windows are the last 30 days unless a card's title says otherwise.
- Ask answers questions about this app's data from anywhere: press Cmd+K (Ctrl+K on Windows and Linux) or the Ask button in the header. The open tab is saved in the page's URL, so a reload or a bookmark returns to the same screen.
Pulse — the weekly home screen
Pulse is where the dashboard opens. Four stat cards read off one selected week: revenue, new paying customers, new users and average session, each with its change against a comparison period and a six-week trend underneath. A row of buttons above the cards picks which week the whole page describes; it opens on the current week. That week shows how many of its seven days have elapsed and compares itself with the same number of days from last week, never a full week against a partial one. Pick last week or any earlier week for complete numbers.
Week by week
The full table breaks every loaded week into three groups. Getting users: App Store downloads (redownloads as a note; they come from the App Store Connect connection), new users, website visitors, and website to App Store clicks. Using the app: weekly active users, average daily active users, average session, and came back next week (of that week's new users, how many were active the following week; still counting for last week, not yet known for the current one). Revenue: new paying customers, revenue (net of refunds, with the refund amount noted when there are any), MRR at week end, paywall to payer conversion, and trials started when the app has any. Click a metric row to chart it in the panel beside the table across all six weeks; click a week's column header to make it the selected week.
Change is shown the way that fits each metric: counts, money and durations get a percent change ("new" when the prior week was zero, "±0%" under half a point); paywall to payer conversion moves in points ("▲ 3 pts"); new paying customers moves in raw numbers ("▲ +2"). The oldest week loaded has nothing to compare against.
Beside the table: What moved picks out the week's biggest changes in plain language (small numbers are skipped, since 5 users growing to 10 is a real 100% that means nothing), plus an anomaly list of the last 14 days where DAU, revenue or refunds deviated from that metric's own recent baseline. Today shows active users, new users, paying users and 30-day revenue as they stand right now, with a shortcut into Live. Under everything, the weekly brief: an AI analyst reads the past week across every app in the account and writes a summary every Monday, readable in place or stepped back through earlier weeks.
Growth — where users come from
Growth covers acquisition end to end: which source brought each user, which countries they are in, the campaign links you built yourself, the linked landing page if there is one, waitlist leads, and whether an install is genuine.
Sources and countries
Installs by source lists every user since tracking began, one row each, grouped as organic, Apple Ads, referral (website links, ChatGPT and similar), sideloaded, or no verdict, with each group's share of users and how many of them pay. Sideloaded means the app was not installed from the App Store; those users never pay, so treat them as pirated copies, not customers. No verdict means the install predates the attribution checks, or both checks failed to reach one. A daily chart beside the table shows the same split for the last 30 days of new users. Countries toggles between everyone active in the last 30 days and only users first seen today, the same population Pulse's and Engagement's "New today" stat counts.
Campaign links
Type any campaign name and get a working
foliokit.io/l/<code>/<campaign> link back
immediately; there is nothing to set up first. Clicks are logged
server-side before the redirect to the App Store, so ad blockers
cannot hide them. Below the builder, clicks by campaign for the last
30 days, with the countries reached and time since the last click;
open a campaign's row for a day-by-day drill-down that estimates its
install lift by comparing the app's install pace on the campaign's
complete days against its normal pace (clicks cannot be tied to
individual installs, since Apple strips identity at the store, so
lift over the normal pace is the only signal available).
Landing page and waitlist
When a landing page is linked to this app as a child, its 30-day
funnel appears here: page views, store clicks, and App Store installs
(all downloads for the app, not only ones this page can prove), plus
visitor countries, referrers, top pages by views and average visible
time, and the ?ac= campaign breakdown. A second card
steps week by week through the same site, page by page, with each
page's views, clicks, click-through rate, matched installs and
payers, and the change in clicks against the week before.
Waitlist lists every signup, deduped by email,
newest first, with one-click copy of every address and a delete for
stray rows.
Install integrity
The app sends Apple's own signature check once per cold launch. A user comes back verified (a genuine App Store or TestFlight install), unverified (Apple's signature does not check out, a pirated or re-signed copy), or unavailable (Apple could not be reached; unknown, never counted as pirated). This section shows the daily split, which countries the unverified copies concentrate in, and a cross-check against a second signal (whether the install carries an embedded provisioning profile, which re-signed copies almost always do and genuine installs never do) to catch cases where the two signals disagree.
Engagement — how people use the app
Engagement is the last-30-days read on usage: four stat cards (active today, new today, average session, paying users), then activity, the funnel, what people look at, which versions they run, and who comes back.
Activity
Daily active users, with annotations: click a day to pin a note ("2.1 released", "Reddit post") so a spike or a dip explains itself later. Average session length sits beside it; the stat card's own 30-day average is weighted by how many sessions happened each day, so one busy Friday counts more than one quiet Tuesday.
Funnel, screens, versions
The conversion funnel walks onboarding completed, paywall shown, trial started and purchase completed, showing distinct users at each step, that step's share of the first step, and its conversion from the step before. A step your app has never instrumented (zero users, with a later step showing real ones) is hidden rather than drawn as a 0% conversion nobody could reach; a real trailing zero, nobody purchased yet, still shows. Top screens and the app-version and OS-version breakdowns round out the picture; app version is how you watch a release roll out across your users.
Lifecycle and retention
Lifecycle splits each day's actives into new (first ever activity), returning (also active yesterday), resurrecting (back after a gap) and dormant (active yesterday, gone today, drawn below the line as the outflow). Cohorts are event-anchored: a user only appears because they did something, so a record created only by a payment never inflates the bars. Retention is a cohort grid, daily (14 cohorts) or weekly (8 cohorts): each row is the users first seen on that day or week, and each numbered column shows what share of that cohort was active again that many periods later. The mean row is weighted by cohort size, and the most recent cell in each row is faded, since that period is not over yet.
Revenue — overview and profit and loss
The Revenue tab holds two views behind one switch at the top: Overview, what the app earns, and P&L, what the business keeps after costs. Both exist because the SDK and RevenueCat share one user ID: every purchase belongs to a person you can see behaving elsewhere in the dashboard.
Overview
Four stat cards open the tab: 30-day revenue (split into new, renewals, refunds and anything imported from before the RevenueCat webhook connected), 30-day installs (purchases and the new-buyer conversion rate), paying users (currently entitled, reconciled against RevenueCat daily through the RevenueCat connection, with the last-30-day payer count as a sub-line), and 30-day trials (conversion rate and cancellations). "New" revenue is first purchases, non-renewing purchases and trial conversions; "recurring" is renewals, momentum from past decisions rather than current work.
Month forecast
Below the headline stats, a projection for where the current month lands: revenue booked so far, plus renewals due (weighted by how reliably each subscription has renewed and how close the renewal is), trials expected to convert, new buyers at the recent eight-week pace, and refunds at their recent pace, net of Apple's cut. The chart marks what already happened as a solid line, the rest as a dashed projection inside an 80% likely range, with last month's total as a reference line. The card is hidden entirely when the app has no revenue yet or the forecast function is not installed. When an app has fewer than 35 days of RevenueCat history, a note says so directly: subscriptions that have not had the chance to renew since then are missing from the model, so the forecast runs low.
Subscriptions and trends
The subscriptions card shows current MRR (each subscription's last paid price normalized to a monthly figure from its real billing period), active and cancelled-but-still-active counts, a 30-day MRR trend, and a per-product breakdown; trials count as active at $0, and lifetime purchases are excluded. Underneath, the daily revenue, installs and purchases chart; a 7-day rolling install-to-purchase conversion (renewals do not count toward it, so it measures new buyers, not loyalty, and stays blank under 10 trailing installs); App Store downloads split into new installs and redownloads (a reinstall resets the SDK's own user id, which is why new-user counts can run higher than new downloads); a month-by-month table of gross revenue against Apple's actual net proceeds, with downloads and the change from the month before; a revenue-by-weekday heatmap; revenue by product and by country; and the latest transactions, grouped by day.
App Store downloads and Apple's net proceeds come from Apple's own reports. To see them, connect App Store Connect once under Connections in any app's settings and set each app's App Store ID (the steps).
P&L
P&L reads like a spreadsheet: months across the top, revenue rows, cost rows, net income at the bottom, toggled between one app and the whole business (every app's revenue and costs, shared costs counted once). It deliberately ignores the Internal switch and always reads this app's complete revenue history, so nothing here depends on which traffic the rest of the dashboard happens to be filtering. Revenue follows a fixed hierarchy: bank received, entered by hand once the real deposit lands, is the only solid, final number. Until then the cell shows a placeholder, Apple's actual net proceeds once its monthly financial report is published, or an estimate (RevenueCat gross times 0.75, the ratio that has historically survived VAT-inclusive pricing, Apple's cut, currency conversion and withholding) before that. Placeholder cells stay dimmed with a dashed underline and a tag naming the source, so a screenshot is never mistaken for confirmed truth; click any cell to enter or adjust the real deposit. Costs are one-off or recurring, optionally grouped into collapsible categories, and scoped to one app or shared across the whole business; in single-app mode shared costs sit in a memo section and never touch that app's own net. Currency displays in USD or EUR at a rate you set yourself.
Live — the real-time feed
Every event arrives here the moment it happens: time, user, event name, screen or detail, country, app version and OS. Revenue events sit inline in amber with their type and amount; waitlist signups highlight in green. A user's pills mark them NEW (first day is today), PRO (currently entitled, with the plan length), INTERNAL, or PIRATED (failed Apple's install signature). Click any user to filter the feed to only them, see their trail through the app, and mark them internal, the setting that keeps your own devices out of every metric elsewhere in the dashboard. There is a pause button for when the feed moves too fast to read.
Config — change the app without shipping an update
Remote switches the 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; older builds ignore switches they do not know.
- Rating prompt: turn App Store review requests on or off, and set how many sessions before the first ask and the cooldown between asks. Off means nobody is ever asked; Apple adds its own cap on top (roughly three asks per user per year).
- Force update: a minimum required version; the app shows its own "please update" screen to anyone below it. Empty means never, and normal releases should leave it that way.
- Feature flags: switches you name yourself, for a new paywall you can turn on remotely (and back off if it hurts), or an emergency shut-off for a misbehaving feature. Add a flag, write one line on what it should switch, then copy the ready-made agent prompt into the AI coding agent working on the app; the agent wires the check, and from then on the switch lives here. A flag stays off for any build that never got the check.
- SKAdNetwork conversion values: which events signal install quality to ad networks, from 0 to 63, retunable mid-campaign without a build.
- Raw JSON for anything the editors above do not cover.
Ask — question the data directly
Press Cmd+K (Ctrl+K on Windows and Linux) or the Ask button in the header to open a question box over whichever app is selected. It answers from that app's own events, revenue and user records, nothing else, and every answer can expand to show the data calls behind it. Questions and answers save into threads per app, so a follow-up continues the same conversation and past threads stay in a side list you can reopen or delete. Each account has an hourly and a longer-window quota; the input disables with a plain explanation once it is spent, and re-enables on its own when the window resets.
Questions this page didn't answer
"Why is this number different from App Store Connect or RevenueCat" and similar live in the FAQ & troubleshooting guide.