Crossing a frequency threshold shuts the whole channel

What it is

People hold a global tolerance for an app's pushes. Past it, the next move is often not "less of this type" but shutting the whole channel: OS permission off, in-app master switch off, uninstall. The threshold is calibrated on recent density of annoyance, not on a planned weekly quota. This entry is the disable funnel after the threshold is crossed—not per-type caps, and not how quiet hours let urgency through.

Why it happens

Disable is a decision-saving strategy. Tuning type by type costs understanding and finding controls; one master off zeros future judgment cost. When arrival density is high enough that sorting is no longer worth it, master-off is cheaper than sorting. Disable is also asymmetric: turning permission on pays a system prompt and an explanation; turning it off is usually one switch. The funnel is therefore one-way—density pushes people over a lip, and coming back costs a separate trust payment.

The threshold is experiential density, not a server count. The same volume, ringing at night versus sitting silently in the afternoon shade, crosses the lip at different speeds. Arrivals with no corresponding action also count: open rate can look fine while opens find nothing to do, and aversion still accumulates.

Studying it

Draw disable as a funnel, not as DAU. Trace arrive → dismiss without open → turn this type off on the notice → master switch → revoke OS permission → uninstall, and read the density that precedes each hop.

Independent variables: arrivals per unit time, share with no downstream action, whether an exit closer than master-off exists. Dependent variables: conversion at each hop, days from high density to master-off, whether permission is later re-granted.

Labs rarely produce real OS-permission revocation. Use production logs, or at least allow "turn it off as you would on your own phone." A rise in open rate after sending less is not proof the threshold was respected—open rate can rise because the remaining audience is more tolerant; the disabled have left the sample.

Where it stops holding

On-call, support, and trading treat arrival as the job; tolerance is high and master-off almost never happens—optimizing that funnel will maim the product. Legally required delivery cannot stop for fear of disable, but it should ride a separate channel so it is not bound to the same counter as marketing density. The first days after install burn tolerance quickly if "introduce more" is the policy; watch density on a shorter window. On multi-device accounts, disable happens on the device that was bothered; server-side "user still enabled" can be wrong.

Applying it

• Draw a per-user disable funnel and read arrival density and no-action share in the week before master-off; treat that band as the warning line.
• Near the line, cut no-action types first rather than hitting the switch with the same total volume.
• After master-off, do not chase with more frequent "we miss you" pushes; that confirms disable was right.
• Verify by comparing daily arrivals in the 7 days before disable against users who stayed on. If the disabled side is substantially higher, the threshold is working; cut no-action types on that side and watch the next cohort's master-off rate, not open rate alone.

Related

• Within the group: H5.07.2 Send timing must follow timezone and sleep · H5.07.3 Unsubscribe must be reachable from the notice
• Adjacent: H5.10 Push frequency and quiet hours · H5.09 Category subscriptions · H4.05 Notification permission
• Search terms: notification disable funnel · permission revocation · frequency threshold