New types should default off, not join existing subscriptions

What it is

Types added later—shopping recommendations, a weekly digest, activity from friends of friends—must default off. They must not ride into the subscribed set because someone once turned "notifications" on or subscribed to "order updates." Past consent covered the types that existed then. Auto-join spends old consent on new content.

Why it happens

Consent is about a known object. A set that grows behind someone's back treats a historical decision as a blank check. The first new arrival feels like "I never asked for this." The repair is often not turning off that one switch in settings—that requires knowing its name—but taking the master switch. Default-off leaves the new type on an optional list; people who want it turn it on, and people who don't are not ambushed by a new channel.

Security types sometimes must default on (a new sign-in alert). That is an exception from the consequence matrix, and it needs an explicit "you will get one more security type," not a quiet mix-in with recommendations. Exceptions must stay rare, or "new types default on" will flow back through the security door.

Studying it

Ship a new type to already-subscribed users, default-on versus default-off. Watch opens of the new type, "I never subscribed" complaints, and OS-permission off.

Independent variables: default state, whether people were told before the first send, how similar the new name is to an old type. Dependent variables: involuntary arrival rate, master-off rate, later voluntary enable of the new type.

Lab "would you like to receive this" yields polite yeses, which are not the same as a surprise on the phone. Watch the first unannounced arrival. Open rate on the new type does not justify default-on—opens include startled taps, and startle converts into disable.

Where it stops holding

Legally required new types (terms changes) may default on, but they belong on the transactional/legal channel and the first arrival should name why. Renames or splits of old types should inherit on/off into the new container; that is mapping, not a new type—a bad map looks like auto-join. Test and employee flags must not leak into a default-on for everyone.

Applying it

• Ship new types default-off; show the item in settings with one line that it is new.
• When a security exception defaults on, the first arrival must say "this is a new security type" and offer a separate off (if law allows).
• Do not treat "notifications already on" as consent records for a new type.
• Verify by shipping recommendations to people subscribed to order updates. The default-off group should not receive recommendations on ship day; if they do, that is auto-join. Then check whether the following week's master-off appears only in the auto-joined group.

Related

• Within the group: H5.09.1 Subscribe by type instead of one master switch · H5.09.2 Categories that are too fine make settings themselves a burden · H5.09.4 Subscription state must stay in sync between the notice and settings
• Adjacent: H4.05 Notification permission · H5.07 Push frequency · H4.07 One-time vs ongoing authorization
• Search terms: opt-in new channel · consent scope · default off