How does an in-app message work?
Your product's SDK does the work. Messages are matched to trigger conditions — a specific event, a page view, membership in a segment — and rendered directly in the interface when those conditions are met. Because delivery rides code you already run, there is no permission prompt and no subscription; anyone active in the product can be shown one. Tools like Braze sync eligible messages to the device at session start, then let delivery rules and frequency caps decide what actually appears.
In-app message vs web push: what's the difference?
A web push notification reaches users off-site, through the browser's notification system — but only after an explicit permission grant, which many users refuse. An in-app message is the mirror image: no permission needed, yet no reach once the user leaves. The two channels cover each other's blind spot — push brings people back, in-app guides them once they arrive. The guide to web push and in-app messaging covers how to run them as one program.
When should you use an in-app message?
Whenever the person you want to reach is already in the product: onboarding checklists, feature announcements, upgrade prompts, contextual tips, short surveys. In-app messages also work well as steps in a broader customer journey — a tooltip that fires only for users who reached the dashboard but never created a project, for example. The targeting is the point; a message everyone sees is just UI.
What are the limits of in-app messages?
- Session-bound reach: a churned or dormant user will never see one — win-back belongs to email, SMS, or push.
- Attention cost: a modal at the wrong moment interrupts real work; default to banners and tooltips, escalate only when the message warrants it.
- Rendering risk: content is injected into a live page, so the platform must sanitize message HTML — XSS-safe rendering is a requirement, not a feature.
- No archive: once dismissed, the message is gone; anything the user may need later also belongs in email or the docs.