H5.09.1category subscription versus master switchdesignresearch

Subscribe by type instead of one master switch

Aliases: notification channels · per-type opt-in · category toggles

What it is

After OS permission is on, people should not face only a master switch. Category subscription splits receiving by content type: messages, transactions, security, social, marketing—each keepable or droppable on its own. The trade is "do I still want this type," not "may this app make sound." The master switch belongs to permission. Subscription is grain inside a channel already granted.

Why it happens

Value judgments are per type: keep chat, drop promotions. A master switch binds those into one decision, so the disliked type takes the needed type with it. Split them and the loss function can align: keep high miss-cost types, drop types that are not to-dos, and OS permission survives.

Types have to be recoverable from the arrivals themselves. Names like "activity" or "boosts" that mix receipts with pitches cannot be mapped, so people fall back to master-off. A category is a semantic contract: name, example, and actual arrivals agree.

Studying it

Give people who already granted permission two settings: master-only, or per-type toggles. Keep sending a mix and watch OS-permission retention plus opens and dismissals per type.

Independent variables: type toggles present, names matching arrivals, marketing bound to transactions in one type. Dependent variables: OS-permission off rate, single-type off rate, whether transactional arrivals still open after marketing is off.

A lab of one checkbox will not show later permission revocation. Watch over days. Click rate on type toggles is not success—success is permission still on and unwanted types removed alone.

Where it stops holding

A one-type tool (OTP apps) makes categories an empty shell. If the OS already exposes channels and the app adds a second set with different names, the two fight. Before permission is granted, subscription has no object—that is when to ask, not the subscription model.

Applying it

  • With permission already on, split arrivals into a few intelligible types with independent switches.
  • Do not house transactions and marketing in one type; keep security separate and on by default.
  • Illustrate settings with real arrivals, not internal codes.
  • Verify by having someone turn marketing off and still receive orders and security. If turning marketing off also revokes OS permission, or orders stop too, categories never left the master switch.

Related

  • Within the group: H5.09.2 Categories that are too fine make settings themselves a burden · H5.09.3 New types should default off, not join existing subscriptions · H5.09.4 Subscription state must stay in sync between the notice and settings
  • Adjacent: H4.05 Notification permission · H5.07 Push frequency · H5.01 Urgency grading
  • Search terms: notification categories · channel subscription · master switch

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H5.09.1