Skip to content
Communication & Notifications

05.02 · Concept

Email, Push & In-App

Pick a channel per message type by what the channel guarantees, not by what is easiest to send.

Email, push and in-app messaging provide different guarantees, so channel choice should start with persistence, urgency, user context and interruption cost. Use email when a durable record matters, push when immediate attention is justified, and in-app messaging when the user is already active and needs contextual guidance.

What this lesson answers

  • when should I use push instead of email
  • how to choose between email push in-app messages
  • what notifications need a durable user record

Notes

Email, push, and in-app messages are not interchangeable delivery mechanisms. Email is durable, searchable, and works even when the user is not currently using your product, but it is slow, crowded, and often ignored. Push is immediate and attention-grabbing, but depends on device permissions, platform rules, user settings, and token health. In-app messaging is controlled and contextual, but only works when the user is already inside the app or website.

The useful mental model is to choose the channel based on the guarantee the message needs.

Common questions

Is push a reliable replacement for email?
No. Push is useful for timely alerts, but it depends on permissions, platform behaviour, user settings and valid device tokens. It is also easy to dismiss and poor as a long-term reference. If the user must be able to find the message later, email is usually the safer baseline.
What kinds of messages belong in-app?
In-app messages fit situations where the user is already inside the product and the message helps with the current context. Examples include workflow guidance, feature discovery, warnings about the current action, or recovery from confusion. They are not suitable for reaching users who are absent.
How should I decide the notification channel for a message?
Classify the message by what it needs to guarantee. Ask whether it must be kept, whether it matters only right now, whether the user is currently active, and how costly interruption would be. The channel should follow those constraints, not the convenience of an SDK call.