Notification Permission Education

This journey is worth building when the system permission prompt appears at first launch or without context, grant rates stay low, and push reach is stuck on a small part of the install base. It needs three things: tracking of the completed action that notifications would help with, a per-user record of whether the system prompt was ever shown, and the real permission state read back from the operating system. If people who grant permission later switch notifications off, the problem is the notifications you send, not the moment you ask; review those first.

Incremental active push permission vs control

Tapping Continue on the pre-permission screen is not permission; what counts is push permission that is actually on in the operating system and has not been switched off since.

How it is counted: Among all users assigned to both groups at entry, the share whose push permission is active in the system at the end of the same follow-up window; because the control group sees neither the explanation nor the prompt at that moment, the gap is the journey's whole effect on the push channel. Seeing the explanation or tapping Continue does not change the denominator.

Also track

• Continue rate from the pre-permission screenOf those shown the explanation, the share who choose to continue; it is the step before the system prompt and tells you whether the explanation convinces.
• Grant rate in the system promptWhere the prompt opened, the share who grant; if most people who continued refuse here, the explanation and the prompt are setting different expectations.
• Opt-out rate after grantingGranted permissions that are later switched off, as a share of all grants; they do not count as active permission, and if the share climbs, the fault lies in the notifications sent, not in the ask.
• Deferral and refusal splitRead the share who did not continue and were deferred separately from the share who refused in the prompt; the first points at the moment or the explanation, the second at the system prompt itself.

• Trigger and entryUsers enter when they complete an action that notifications could follow up on. Eligible users are then split at random into a journey group and a control group that sees neither the explanation nor the system prompt at that moment.
• Who must not enterAnyone who has already been asked for system permission stays out; whether they granted or refused, the existing state is left unchanged. A person who refused is never asked again. One instance covers a user's first notification permission request; without a relevant action, for example on first launch alone, there is no entry.
• Timing and channelsNo wait comes first: as soon as the action completes, the permission history is checked and a single in-app message explains what notifications do for this task. The system prompt opens only if the user chooses to continue; no push or email is involved, since no permission exists yet.
• Exit and handoffFour exits: the existing permission state stays unchanged when permission was asked before, the request is deferred and no prompt opens when the user does not continue, push is enabled when permission is granted, and no further prompt follows a refusal. No handoff exists; the journey ends in its own exits.
• Frequency and consentOne in-app explanation and at most one system prompt per user. The platform's current authorization rules decide when and how often that prompt can open; asking again after a refusal is not part of this journey.

1. 1If active permission in the journey group ends up no higher than in the control group, the explanation screen produced a tap and nothing more; a high continue rate does not count. Judge the explanation by the permission state read from the system, together with the opt-out rate after granting.
2. 2The result holds for this context only: a single explanation shown right after a notification-relevant action completes. Do not build a comparison arm that opens the system prompt directly or without context; this journey's rule forbids it. With no handoff, the permission is credited to this journey alone.
3. 3Because the control group is not asked at that moment, its baseline grant rate can be very low, and a handful of grants makes the gap misleading. Enter the control group's rate and the smallest lift you want to see into the sample size calculator and settle the number of users needed per arm before you start.
4. 4A refused permission is never requested again in this journey, and a refusal must not block unrelated core tasks in the app. A deferred request is not a refusal, but do not promise the system prompt will reopen; the platform's rules decide that.