The 4-Tier Push Notification Fatigue Model

Push notifications are the cheapest way to lose a user. The retention curve at 1 push per day looks fine - industry data from Localytics and Urban Airship clusters around 88 percent three-month retention. At 3 pushes per day the curve drops by 17 percentage points. At 5 pushes per day it drops by 34. The shape is steep and irreversible: 46 percent of users opt out of push entirely when an app sends them 2 to 5 pushes per week they do not want.

Soulwise's response is a 4-tier fatigue model. It detects open-rate decay over a rolling 14-day window and progressively reduces notification volume before the user opts out for good.

This post walks through the design, the thresholds, and the recovery logic.

The four tiers

The state machine is small. Every user is in exactly one tier at a time.

• T0 - Healthy. Full schedule. Morning ritual prompt, mid-morning contextual nudge, evening reflection, plus event-anchored prompts.
• T1 - Demoted. The mid-morning contextual nudge is paused. Everything else continues.
• T2 - Anchor-only. Only the morning ritual prompt and the Sunday retrospective remain. All discretionary pushes are paused.
• T3 - Weekly-only. A single weekly push survives. The daily cadence is suspended.

The order matters. Mid-morning is the first to go because it carries the lowest event weight: it is a contextual nudge, not part of the daily ritual itself. The morning prompt is preserved longest because event-anchored daily pushes produce about 2.85x the retention of generic ones; killing it kills the app.

What triggers a tier change

A rolling 14-day window of open-rate data per user. Each day the model looks at the last 14 days and computes the user's open rate for push notifications sent during that window.

Soulwise's threshold is 30 percent open-rate decay from the user's personal baseline. If a user typically opens 60 percent of pushes and the rolling window drops to 42 percent or lower, the model moves them down a tier. The drop has to persist for at least 3 days to avoid reacting to a single bad week (a vacation, illness, a heavy week at work).

Promotion is symmetric. If a user is at T2 and their open rate climbs back above their baseline minus the 30 percent threshold for 3 consecutive days, they move up to T1. Recovery to T0 takes the same step.

Why event-anchored pushes survive longest

The Localytics / Urban Airship data point that drives the design: event-anchored daily pushes produce roughly 2.85x the retention of generic daily pushes. A generic "check in with us!" at 9 am is forgettable. A morning prompt anchored to today's actual cycle phase ("Soft start. What's on your plate today?") is event-anchored - it has new information.

T2 keeps the morning prompt because removing it removes the entire daily ritual. Everything else in the app is built around the user logging in once in the morning and once at night. Without the prompt, the loop breaks.

The fatigue-banner UX

When a user is demoted, the app surfaces a small banner inside the app the next time they open it:

"We've eased off for 7 days - turn back up?"

That sentence does three things: it acknowledges the change, attributes it to the app's behaviour (not the user's failure), and offers agency. The user can override the demotion with a single tap if they want notifications back.

This matters because a silent demotion feels like the app abandoning the user. A loud one feels like the app caring. The same action with different framing.

Anti-patterns we deliberately did not build

The product spec is explicit on what is forbidden:

• No "don't break your streak" guilt push. Streaks are loss-aversion shaming. The fatigue model demotes users; it does not shame them.
• No "we miss you" reactivation push at the end of T3. A user at T3 is already telling the app something. Adding more pushes is the wrong response.
• No fake counters or scarcity in push bodies. "X people just signed up" is dark-pattern theatre, not a notification.
• No menstrual or astrology content in push titles or bodies. Push goes through a CI lint that rejects builds containing forbidden patterns; the fatigue model never bypasses it.

What the data inside the system actually looks like

The model stores per-user state with three fields:

tier: 'T0' | 'T1' | 'T2' | 'T3'
rolling_open_rate_14d: 0.0 to 1.0
baseline_open_rate: 0.0 to 1.0 (computed from first 30 days)
last_tier_change_at: timestamp

That is the entire fatigue state. No browsing history, no engagement scoring beyond open rate, no machine-learning model trained on the user. The simplicity is the point: the rules are auditable, the thresholds are documented, the UX consequences are predictable.

What this is not

A note on scope.

The fatigue model is per-user, not per-cohort. We do not look at "users like you" or run experiments that demote users to learn about retention. The model serves the individual.

It also does not replace user-controlled settings. Quiet hours, per-category mute, and explicit disable-all-pushes all work independently of the fatigue model. The two systems compose; the user's explicit choice always wins over the model's inference.

Why this matters for the rest of the app

Push notifications are how a daily ritual stays daily. A check-in app that loses push privileges loses its main retention loop. The 4-tier model exists so that the app does not abuse the privilege and lose it the slow way - by being just slightly annoying for just long enough.

The fuller daily-ritual context lives at the Soulwise hub. The fatigue model is one part of why the ritual stays reciprocal instead of demanding.

The shorter version: the right number of pushes is the largest number that does not cause opt-out. The fatigue model is how the app finds that number, per user, every 14 days.