Category opt-in beats a blanket grant

What it is

System notification permission is often all-or-nothing. A better authorization structure lets people opt in by category—transactional, social, marketing each on or off—once the system channel is opening (or just before), instead of a single "Allow notifications" valve. This entry is about the structure of the grant. It is not about how subscriptions are managed later in Settings, and not about how dense pushes should be. If categories only exist on a hidden page after the fact, the grant is still blanket.

Why it happens

When high-value and low-value messages share one channel, people answer the most annoying class with the master valve, so shipping alerts die with marketing. Categories split the decision; allow rates diverge by class—security can be high, marketing low—and that split is preference, not failure. A blanket grant postpones the split until regret, when the only tool is still the master valve. Offering only the valve at authorization wastes granularity in the window with the most information and the most specific motive; splitting later is expensive to discover and little used.

Studying it

Compare "system master valve only" with "per-category checks around that valve." Look at each class's on-state and later shutoff.

Independent variables: whether category checks appear at authorization, default all-on versus all-off, number of categories. Dependent variables: enable rate per category, system-valve shutoff rate, uninstall attributed to notifications, how many people later change classes in Settings.

Do not treat master-valve allow rate as success. Under categories it may fall, while high-value classes stay on and global shutoff drops—that is the structure working. When there are so many classes that the ask becomes another form, the measurement is burden; separate "too fine" from "has granularity."

Where it stops holding

A tool with one notification type (calls only, codes only) has nothing to categorize. If the OS will not show channels at the instant of the ask, present category choice immediately before or after the system dialog, not weeks later in Settings. Enterprise-mandated channels cannot be sold as optional marketing classes. Categories are not an urgency-grading UI stuffed into authorization—urgency is how each later item is sent; here the only question is "which classes may send."

Applying it

• In the same flow that allows system notification permission, show category toggles. Default on only the class just experienced; marketing defaults off.
• Category names must match the system channels that will be registered. A class that did not appear in the grant flow must not be auto-enabled later in code.
• The primary button is "Turn on my selections," not "Allow all" covering classes already switched off.
• Verify by reading system channels or in-app subscription state at the end of the grant: unchecked classes must be off. Track thirty-day master-valve shutoff against a blanket version; high-value classes remaining on with fewer global shutoffs is a win. Do not use "total sends after grant" as the metric.

Related

• Within the group: H4.05.1 Ask for notification permission after the product has delivered value · H4.05.2 Say which kinds of notification will be sent
• Adjacent: H5.09 Category Subscriptions · O1.10 Consent Granularity and Withdrawal · H5.01 Urgency Grading
• Search terms: notification channels · category opt-in · blanket authorization