Stacked permission requests lower overall grant rates

What it is

Stacked (bundled) permission requests throw several system grants into one decision window: location, then notifications, then contacts after launch, or a single checklist that wants every box ticked. The decision is no longer "this capability, yes or no" but "process a pile of authorizations now." Overall grant rate—the share of each permission that ends up allowed—is typically lower than asking the same set on their own features. This entry is only about the cost of crowding several asks into one moment. It is not about whether a single ask should wait for use, and not about offering notification categories instead of a blanket opt-in.

Why it happens

Several grants share one burst of attention and one risk budget. People price the stack by its most sensitive item: contacts look scarier than camera, so camera is refused too. A rapid sequence also habituates—the first dialog is read, the second is tapped Don't Allow to make it stop. Bundling also severs the map from permission to action, so necessity cannot be checked item by item; the only moves left are accept-the-pack or reject-the-pack. Grant rate falls not because every item became less trustworthy, but because the decision decays from evaluating purpose into ending the interruption.

Studying it

Take the same set of permissions and compare "list once / fire in sequence" with "spread across the session on matching features." Compare each permission's final grant state.

Independent variables: number of asks in one screen or one session, order (sensitive item first or later), whether a real task sits between two asks. Dependent variables: per-permission allow rate, pack-level denial, reading-time decay after the first dialog, later ability to pair permission with feature.

Allow rates mix "read and refused" with "refused to dismiss the next sheet." Eye tracking, reading time, or a later explanation have to split those. A drop on the last item is not automatically evidence that the item is sensitive—serial position itself produces decline. A lab that dumps every dialog in one sitting overestimates patience for spread-out asks in a real product.

Where it stops holding

Some hardware capabilities only work as a set (a video call needs camera and microphone). Splitting them lets someone grant the first and fail the second, and the task still cannot start. Ask them in a short interval before joining the call, still one dialog at a time, not a fake combined "media permission." Enterprise mobile management authorizes a bundle by policy, and the handset never shows per-item dialogs. In accessibility or in-car contexts where attention is already scarce, a sequence is worse than on desktop; stacking is even less viable.

Applying it

• List the triggering action for each permission; do not enqueue two permissions before both actions have happened.
• For capabilities that only work as a set, request them one after another in the seconds before that task, joined by a line such as "the microphone is still needed so the other person can hear you"—not a multi-select sheet.
• Do not lead the queue with the most sensitive item if it is not required for the current action; move contacts or precise location to the moment they are actually used.
• Verify with a per-permission allow funnel, looking for a steep drop from the second item that is independent of content. After splitting the queue, each permission's allow rate should rise in the same traffic window; do not score success as "at least one permission was granted."

Related

• Within the group: H4.01.1 Request the permission when the feature is used, not at launch · H4.01.2 A first denial costs more than waiting to ask
• Adjacent: H4.05 Notification Permission · H4.08 Camera and Microphone Permission · O1.05 The Usability Dilemma of Informed Consent · O1.10 Consent Granularity and Withdrawal
• Search terms: permission bundling · stacked permission requests · permission grant rate