18 November 2025 · Metrics
Prompt exposure is not a vanity metric until you inflate it
Exposure belongs in a permission ledger. Without it you cannot tell whether Allow is rare because users refuse, or because they never met the dialog. The vanity begins when exposure is defined as every time a view was constructed, every prefetch, every return from background, or every tooltip that mentions notifications.
Three inflations we keep finding
First, lifecycle callbacks. iOS viewDidAppear and Android onResume fire when the permission screen is covered by a system sheet, a jailbreak warning, or an in-app review prompt. Count visible milliseconds, or at least require an interaction opportunity.
Second, repeat mounts. A user who rotates the phone, or who is returned to onboarding after a crash, can accrue five “exposures” before a single decision. Deduplicate by user and prompt version inside a session, then again inside a day. Report both if you must; do not average them into one cheerful line.
Third, unreachable users in the denominator’s cousin — the numerator of “prompt shown / all new installs.” Installs that never passed KYC, never updated the OS, or never left airplane mode are not a prompt audience. Put them in a reachability bucket. Leave them out of opt-in.
A definition we will defend in a review
Prompt exposure: unique users, on a prompt-capable OS build, for whom the permission UI was unobstructed for at least one second, prior to an OS result or a deliberate dismiss, within the experiment window. It is a dull sentence. Dull sentences survive QBR.
Once exposure is clean, opt-in can fall. That is usually good news. It means you stopped congratulating a screen a third of new users never saw. Permission Funnel Diagnostics spends a full week on this hygiene because every later module inherits the denominator.