Funnels, verdicts and recommendations

How Broctic builds a funnel from events, how onboarding A/B tests are assigned and read, which templates fit which app, and where the benchmarks behind each verdict come from.

How a funnel is counted

A funnel is an ordered list of two to twelve steps, each an event name, optionally narrowed by one property — paywall_viewed where placement is onboarding, for instance.

People, not events. Each step counts distinct people who reached it having reached every step before it, in that order. Someone who saw the paywall twice is one person; someone who saw the paywall without finishing onboarding has not reached step 4.
First occurrence. Order is judged on the first time each person sent each event, so a user who loops back through onboarding does not re-enter the funnel.
A window. Every report states the window it covers. A trial started on the last day of the window has not had time to convert, which is why trial-to-paid over a short window reads low and is labelled provisional rather than quietly reported as a decline.
Two rates per step. Conversion from the previous step, and share of the first step — the first tells you where the leak is, the second tells you how much it costs.
Median time from the previous step, for the people who made it. A step people pass eventually but slowly is a different problem from a step they abandon.

Below 50 people, rates are not shown as rates

With fewer than 50 people at the first step, a ten-point swing is one person. The report is marked thin and shows counts instead of confident bars — the honest answer to "is 30% good?" on nine people is that nobody can tell.

Who counted: Broctic or PostHog

Every funnel report says which engine produced it, and the console shows that as a badge. An app with a PostHog project linked is counted by PostHog; an app without one is counted by Broctic, from the rows sent to /v1/events. The Studio kit dual-writes to both, so the same events are in both stores and either can answer.

They agree on people who go through in order, which is nearly everyone. There is one case where they differ, and it is worth knowing before you compare two screenshots:

Re-entry. Broctic judges each person's first touch of every step, so somebody who saw the paywall, then started onboarding properly, then saw the paywall again has not converted — their first visit did not go in order. PostHog walks the event stream and matches the second paywall view, so it counts them. PostHog is therefore equal or higher on later steps, never lower.
The conversion window. PostHog's funnels have one and it defaults to fourteen days. Broctic asks for the report's own window instead, so a 90-day report is a 90-day report. If you run the same funnel by hand inside PostHog and get a smaller number, this is usually why.

What does not change with the source

The 50-person thin rule, the benchmark bands, their citations and the App Store join are Broctic's on both paths. PostHog will draw a confident funnel on six people; the report you are reading will not, whoever did the counting.

Onboarding A/B tests run on Broctic's own data

An onboarding funnel is a designed document — a theme and up to eight screens — that the app ships in lib/funnel.json. A test runs two to four arms of it against each other at the traffic split you choose. No third-party account is needed.

Broctic assigns the arm. When onboarding starts, the app asks GET /v1/experiments with its publishable key in the x-broctic-key header. The arm is a hash of the experiment and the person, so the same person gets the same arm on every launch and nothing is stored. Weights are frozen while a test runs, so nobody is moved mid-test. There is one randomiser and it is this one — two would make a result uninterpretable.
It never blocks onboarding. The app waits a couple of seconds at most, then uses its cached answer, then the funnel it shipped with. The same route is also what lets a funnel edit reach people without an App Store release.
Results come from your own events: exposures from funnel_variant_assigned, drop-off per screen from onboarding_step, and revenue per arm from the purchases Apple reports for the app, per currency.
A winner needs 50 exposures and 5 conversions per arm, the same discipline as the thin rule above. Promoting it writes the winning design back into lib/funnel.json as a new version and ends the test — it is a code change, not an arm left serving 100%.

Session replay lives in PostHog, if you want it

A funnel says where people stop. Watching a session says why. Broctic does not store session recordings and has no player — linking a PostHog project is what turns replay on, and the console links straight into it. Recordings can be filtered to friction: sessions where an error was shown, somebody rage-clicked, or the console logged an error.

PostHog is optional. Funnels, reports and A/B tests all work without it; linking a project adds replay and makes PostHog the engine that counts the funnel report, as described above.

The PostHog organization is yours, not Broctic's: your own account, on its own free tier. Connect it once under Settings → Integrations, then link a project per app.

Templates, by what kind of app it is

A subscription app's funnel ends at a first charge; a lead-capture app's ends at a submitted form. These are starting points you edit, not a judgement about what your funnel should be.

App shape	Steps
Subscription app	app_opened → onboarding_started → onboarding_completed → paywall_viewed → trial_started → subscription_started
Lead capture	app_opened → onboarding_completed → signup_started → signup_completed
Marketplace or store	app_opened → signup_completed → purchase_started → purchase_completed
Content app	app_opened → onboarding_completed → feature_used → paywall_viewed → subscription_started
Utility	app_opened → feature_used → paywall_viewed → purchase_completed

Before you send a single event

Apple's own report already contains three of the funnel's hard edges — first downloads, trial starts and paid subscriptions — so these are computed from the store alone and are available from the moment App Store Connect is connected:

Download → trial — trials ÷ first-time downloads.
Trial → paid — paid units ÷ trials. Provisional, for the window reason above.
Download → paid and refund rate.
Proceeds per first download — what a new user is worth in this window, on the store's own numbers.

Events do not replace these. They add the steps between them, which is where the number you can actually change usually lives.

Verdicts: strong, typical, weak, unknown

Each step transition is compared to the published benchmark for that transition in that kind of app, and labelled. Unknown is a real and common answer: it is what you get when a step has no published comparison, or when there are too few people for a rate to mean anything, and it is shown rather than replaced with a guess.

Every recommendation carries five things, and none of them is optional:

The verdict for the step it is about.
The finding — what your numbers say, with the comparison stated, not implied.
The action — what to try, and honest about what the evidence supports.
The source of the comparison figure. Never omitted.
An impact estimate, from how far below the band the step sits and how many people it touches. Biggest first, because a 2-point gain on a step 4,000 people hit beats a 20-point gain on one that 40 people reach.

Broctic does not publish its own benchmark distribution

There are not yet enough apps on the platform for a first-party distribution to mean anything, and inventing one would poison the only thing this product is for. Until there is, every comparison is a published figure with its source attached, marked as seeded. When first-party aggregates replace them, the source string changes — the interface does not.

The benchmarks, and where they come from

Store-side conversion

Measure	Published figure	Source
Download → trial	4.3% – 9.8%median, low-priced apps to high-priced apps	RevenueCat, State of Subscription Apps 2025
Trial → paid	48.7% travel · 43.8% media & entertainmentcategory medians	RevenueCat, State of Subscription Apps 2025
Trial length that converts best	17–32 days (45.7% median trial → paid)	RevenueCat, State of Subscription Apps 2025
Download → paid by day 35	12.1% hard paywall · 2.2% freemiummedians	RevenueCat, State of Subscription Apps 2025
Annual subscriptions cancelled in the first month	~30%	RevenueCat, State of Subscription Apps 2025
Refund rate	3.4% freemium · 5.8% hard paywall · ~4.7–4.9% health and education	RevenueCat, State of Subscription Apps 2025

Medians, not averages, and segment matters more than the headline: a hard-paywall app and a freemium app are not comparable on download-to-paid, and the same study reports them six times apart. Broctic compares like with like, or says unknown.

Reading a funnel without fooling yourself

A step you did not instrument looks like a step nobody reached. Check the Events page for the names you expect before you believe a cliff.
A cliff at the first step is usually instrumentation, not users: app_opened sent once per screen inflates step one and makes everything after it look terrible.
Store-side and event-side counts will not match exactly. Apple counts store transactions in Pacific days; events count people in your window, and a person who downloads today may open the app tomorrow.
A change to the funnel definition changes history. Compare like for like, or note the change.

The instrumentation itself is in events, and the store-side figures are defined in the analytics reference.