What are in-app notifications?

How they differ from push

Push notifications reach a user who is elsewhere and require an explicit permission that can be revoked permanently. In-app messages reach a user who is already here, need no permission, and cannot be turned off.

That makes in-app the safer channel and the less powerful one. It cannot bring anyone back; it can only work on people who already returned. The two are complements rather than alternatives — push for reactivation, in-app for direction once they arrive.

What they are good at

• Feature discovery, shown at the point the feature would help rather than in a tour on first launch.
• Contextual guidance when a user appears stuck.
• Upgrade prompts triggered by hitting a limit, which is when the value of upgrading is self-evident.
• Time-sensitive offers to users already engaged.
• Changes that affect the user, such as pricing or policy updates.

How they go wrong

The absence of a permission control removes the user's veto, and teams over-use them precisely because there is no opt-out rate to serve as a warning signal.

Three patterns account for most of the damage. Launch-time stacking, where three messages queue on open before the user has done anything. Interrupting an active task, which is the in-app equivalent of a badly-timed interstitial. And repetition, where a dismissed message returns on the next session because dismissal was not recorded as an answer.

The discipline is the same as for every interruption format: trigger on behaviour rather than on arrival, cap centrally across teams, and treat a dismissal as a decision.