When Does a Push Notification Bring a Player Back — and When Does It Just Get Swiped Away?
Most teams treat push as a messaging problem: write better copy, send more of it, watch the open rate climb. That's the wrong frame. Push is a timing and targeting problem wearing a copywriting costume, and almost every mini-game oversends because the only metric on the dashboard is opens. Here is what actually decides whether a notification earns a session or earns an uninstall.
Q: Why do most push campaigns quietly fail even when the open rate looks healthy?
Because open rate measures the wrong thing. The player who opens your notification at 9am was probably already going to open the game at 9am — you credited yourself with a return you didn't cause. The number that matters is incremental return: notified segment minus a holdout that got nothing. Run that comparison and a surprising number of "successful" pushes show lift near zero. The second failure is send time. A notification delivered at 3am local — because your server runs on UTC — gets swiped, not tapped, and trains the player to ignore you. The third, and the one nobody wants to hear: the notification isn't the product. If the deep link dumps the player on a generic home screen instead of the exact unfinished quest, you spent the attention capital and converted it to nothing.
Q: When do you actually send, and to whom?
You almost never send to everyone. Segment by lifecycle state, because a day-2 player and a day-40 dormant player need opposite messages. Early cohort (D1–D3) gets onboarding nudges — but only the ones who stalled, not the ones already hooked. The dormant segment (D14+) is where push earns its keep and where it gets you uninstalled, so it's the segment that needs the most restraint. Use an RFM-lite lens: recency of last session, frequency before they lapsed, and the value they left on the table — an unfinished quest, a wallet balance, a streak about to expire. Trigger off behavior wherever you can; calendar sends are the lazy default and they show. And honor local quiet hours per timezone, not per your office.
Q: How do you avoid the fatigue that triggers an uninstall?
Fatigue is cumulative and invisible until opt-outs and uninstalls spike — by which point you've already paid for it. The structural bug is that every team owns a trigger and nobody owns the total. One campaign caps at two a week; three other teams each cap at two; the player gets six. You need a single global frequency ceiling across all triggers, expressed per user per week, enforced in one place. Then progressive disclosure: start gentle, and escalate only on high-intent signals (they abandoned a purchase, not they ignored you yesterday). And measure uninstall attributable to push — most dashboards don't, so teams keep oversending into a churn they can't see. If you can't isolate that number, you're flying the most destructive lever blind.
Q: What does a push program look like that actually moves retention?
A controlled experiment, not a newsletter. Hold out 5–10% of users forever and watch incremental D7 and D30 return against them; kill any trigger that doesn't beat holdout. Deep links land mid-loop, never on home. Copy and send-time are localized, not translated-and-forgotten. And here's the uncomfortable part for a casual mini-game: the biggest retention lever is almost always the game's own session design — the loop, the next-thing-to-do — not the CRM. Push is a tax you pay on a leaky bucket, not the repair. Spend the first dollar on the loop; spend push on the players the loop already earned but who drifted.
| Trigger type | Incremental return | Fatigue risk | When it earns its keep |
|---|---|---|---|
| Onboarding nudge (stalled only) | medium | low | D1–D3, behavior-triggered |
| Habit-break reminder | high | medium | D5–D10, before the streak dies |
| Dormant win-back | high | very high | D14+, tightly capped |
| Blast / calendar send | ~zero | high | almost never |
