Braze In-App Messages: Complete Guide
Quick Summary:
In-app messages are interruption-based alerts -- modals, banners, full-screen takeovers -- triggered during an active session, distinct from Content Cards' persistent, user-checked feed model.
What Are In-App Messages?
In-app messages are triggered, interruption-style content shown during an active app session -- a modal, slide-up banner, or full-screen takeover appearing in response to a specific event, screen view, or Canvas step. Unlike Content Cards' persistent feed, in-app messages actively interrupt whatever the user is currently doing, which makes them well-suited to genuinely timely, important content but genuinely risky to overuse. Getting the balance right between visibility and intrusiveness is the central design challenge this channel presents.
In-App Message Formats
| Format | Interruption Level | Best For |
|---|---|---|
| Full-screen takeover | Highest | Major announcements, critical account actions |
| Modal | High | Important but not maximally urgent content |
| Slide-up banner | Moderate | Supplementary information, softer prompts |
| In-app notification | Lower | Lightweight, low-friction alerts |
⚠️ Interruption-Based Channels Carry Real Friction Risk
Because in-app messages interrupt the user's current activity by design, overusing them -- for content that doesn't genuinely warrant an interruption -- creates real friction and can degrade the overall app experience. Reserve higher-interruption formats (full-screen takeovers especially) for content that genuinely justifies that level of attention, and default to a less intrusive format or channel whenever there's genuine doubt about whether the interruption is warranted.
In-App Messages vs Content Cards
The choice between these two channels comes down to whether the content genuinely needs immediate attention or can wait for the user to check on their own terms. A critical account security notice justifies an interruption; a general feature announcement usually doesn't and is better suited to the persistent Content Cards feed. Using in-app messages for content that could just as easily live in Content Cards trains users to dismiss messages reflexively rather than actually reading them, undermining the channel's effectiveness for the genuinely important moments that need it most.
Design and Timing Considerations
Getting an in-app message's design and timing right meaningfully affects whether it's received as helpful or intrusive. Treating this channel with the same care given to push permission strategy -- thinking deliberately about when and how often to interrupt, rather than defaulting to whatever is technically easiest to trigger -- pays off in sustained user trust over time.
Avoid triggering on app open, every time: Showing an in-app message immediately on every single app launch trains users to reflexively dismiss without reading, defeating the message's purpose. Reserving this trigger for genuinely significant, infrequent moments preserves its effectiveness.
Respect the user's current task: A message triggered mid-task (like during a checkout flow) risks disrupting a valuable action in progress -- trigger conditions should generally avoid interrupting moments where the user is actively working toward a goal your business cares about them completing.
Design for quick comprehension: Since the message is, by nature, an interruption, users should be able to understand its value and required action within a few seconds -- dense, lengthy in-app message copy undermines the format's core strength.
Provide a clear, easy dismissal path: A message that's difficult to close (a tiny or hidden close button) creates genuine frustration and can damage overall app sentiment beyond just that single interaction.
Testing Before Wide Rollout
Because in-app messages interrupt active sessions, testing before a broad rollout matters more than it might for a lower-risk channel. Validating trigger logic against a small internal or limited external audience first catches issues -- a trigger firing too frequently, a message appearing at a genuinely inappropriate moment -- before they affect your full user base and potentially damage trust in the channel for future, genuinely important messages.
How to Get Started
Define the specific trigger -- event, screen view, or Canvas step -- that should display the message.
Choose a format matching the content's genuine urgency, not defaulting to the most visually prominent option.
Scope trigger conditions to relevant screens/contexts where the message actually makes sense.
Personalize content using Liquid or Connected Content where relevant.
Monitor dismissal rates as a signal of whether the interruption is genuinely landing well with users.
A Real-World Example
A banking app needs to alert users immediately if unusual account activity is detected, while also wanting to promote a new savings feature to eligible users. The security alert uses a full-screen takeover -- genuinely warranting maximum attention given the stakes -- while the savings feature promotion uses a Content Card instead, since it's valuable but not urgent enough to justify interrupting whatever the user was doing when they opened the app. This deliberate channel choice, rather than defaulting to in-app messages for everything, keeps the higher-interruption channel meaningful for the moments that genuinely need it.
Early in the product's life, the team had actually used a full-screen takeover for the savings promotion too, reasoning that maximum visibility would drive the best conversion. User feedback and support tickets told a different story -- the takeover, appearing on every app open regardless of context, was actively frustrating users trying to quickly check their balance or complete a transfer. Switching that specific promotion to a Content Card measurably reduced complaint volume while, notably, not meaningfully hurting the feature's actual adoption rate -- interested users found it in the feed just fine, without the cost of an unwanted interruption for everyone else.
💡 Pro Tip
Before defaulting to an in-app message, ask whether the content would work just as well as a Content Card instead -- reserving interruption-based messaging specifically for content that genuinely can't wait keeps the channel's impact intact for when it actually matters most to your users and your business.
Frequently Asked Questions
What\'s the difference between an in-app message and a Content Card?
An in-app message is an interruption -- a modal, banner, or full-screen takeover shown at a specific triggered moment during an active app session; a Content Card lives persistently in a feed the user checks on their own schedule, without interrupting their current activity.
What triggers an in-app message to display?
In-app messages can be triggered by a custom event, a specific screen being viewed, session start, or as part of a Canvas step -- generally tied to something happening in real time during an active session.
What message formats does Braze support for in-app messages?
Common formats include modal (centered popup), full-screen takeover, slide-up banner, and a smaller in-app notification style -- the right format depends on how much attention the specific message genuinely warrants.
Can in-app messages be personalized the same way as other channels?
Yes, Liquid personalization and Connected Content/Catalog data can be used within in-app message content, the same as other Braze channels.
Does showing an in-app message interrupt whatever the user is currently doing?
Yes, by design -- this is the core tradeoff versus Content Cards. In-app messages are meant for genuinely important, timely content that justifies the interruption; overusing them for lower-priority content creates real user friction.
Can in-app messages be limited to specific screens within the app?
Yes, trigger conditions can be scoped to specific screens or contexts, ensuring a message only appears where it's actually relevant rather than potentially interrupting an unrelated part of the user's experience.
Do in-app messages count toward frequency capping the same way as other channels?
Yes, in-app message frequency should be considered as part of your overall messaging cadence and any applicable frequency capping rules, the same as push, email, or other channels.
Can users dismiss an in-app message, and is that tracked?
Yes, dismissal is tracked as an engagement signal, similar to other channel interactions, and can inform future targeting or A/B testing analysis.
What\'s a good use case for a full-screen takeover versus a smaller banner format?
Full-screen takeovers suit genuinely significant moments (a major feature announcement, a critical account action needed) that warrant maximum attention; smaller banners suit lower-stakes, supplementary information that shouldn't fully block the user's current activity.
Can in-app messages be A/B tested?
Yes, A/B testing capability extends to in-app messages, letting you compare different formats, copy, or trigger timing to measure actual performance differences.
Can an in-app message be set to only display once per user, even if the trigger condition repeats?
Yes, display frequency controls let you limit a specific message to a single showing per user (or per some defined window), preventing a recurring trigger condition from showing the same message repeatedly.
Do in-app messages support the same rich media capability as push notifications?
Yes, images and rich formatting are supported within in-app message content, similar to rich push, letting messages be visually engaging rather than plain text only.
Can in-app messages be targeted to only first-time app users versus returning users?
Yes, targeting can be scoped based on user attributes and session history, letting you show genuinely different in-app messaging to new users during onboarding versus established, returning users.
Can an in-app message trigger a subsequent action, like enrolling the user in a Canvas, when dismissed or tapped?
Yes, message interactions (tap, dismiss) can be configured to trigger follow-up actions, including Canvas enrollment, letting a single in-app moment kick off a broader personalized journey based on how the user actually responded.
Related Articles