In-App Messaging for Higher Customer Engagement in Braze

In-app messaging in Braze supports customer engagement when each message has one job, one trigger and a defined place in the display order. Braze downloads eligible messages to the device at session start, shows one message per trigger occurrence and reports impressions and clicks rather than opens. This guide covers the decisions that shape those results, from editor choice to priority and measurement.

‍

Key Takeaways

• Give each in-app message one job, one trigger and a planned place in the display order.
• Only one in-app message displays per trigger occurrence, so campaigns that share session start form a queue.
• Braze checks eligibility when the device downloads messages, usually at session start, and re-evaluation is a per-message choice.
• In-app messages report impressions and clicks, not opens, so agree a downstream success event before launch.
• Plan withdrawal, workspace capacity and offline behaviour before a campaign goes live.

‍

What does in-app messaging add to customer engagement in Braze?

Braze describes the channel this way: "In-app messages deliver content inside your app or website without interrupting users with a push notification." That suits moments when a person is already active, such as a feature announcement, a promotion or a prompt to opt into push. Braze's own use case list includes push priming, sales and promotions, feature adoption and highly personalised campaigns.

The channel also has a design trait to plan around from day one. Braze notes that content cards, in-app messages, Banners and feature flags rely on device connectivity to sync, and it recommends avoiding these channels for critical, time-sensitive updates. We read that as a scheduling rule: in-app messaging serves the next session, not the next minute.

‍

Which editor should you build in?

Braze recommends the drag-and-drop editor as the default for in-app messages. It builds modal and fullscreen messages, with rows, Content Blocks, templates and multi-page flows. The traditional editor is for the cases where you need slideup messages or custom HTML.

Decide the editor when you write the brief. Switching a drag-and-drop message to the traditional editor converts the message to HTML, and you can't switch it back. A message that starts in the wrong editor is a rebuild, so ask what the layout needs before anyone opens the composer.

Multi-page messages suit sequential flows such as a welcome journey. Braze sets a ceiling on the number of pages in one message, and a page that isn't linked to any other page stops the message from launching.

Two planning facts sit beside that. In-app messages aren't available in multichannel campaigns, so a push or email companion is a separate campaign or a Canvas step. Canvas steps that contain in-app messages cannot be action-based.

‍

How do triggers and priority decide what a user sees?

In-app message campaigns support three action triggers: start a session in the app or website, make a purchase, and perform a custom event logged through the SDK. Priority then sets the display order when several eligible messages share a trigger. Braze offers high, medium and low buckets, with medium as the default, and a Set exact priority option for a precise order.

The rule with the biggest planning weight is in the Braze FAQ. Only one in-app message can display per occurrence of a trigger event. For session start, that means one message per session, and the next opportunity for another eligible message is the next session.

When messages share a priority level, the message created last displays first. The table sets the documented behaviour beside what we plan for.

‍

Two campaigns on session start form a queue. The second one waits for the next session, and nobody on the team will see that wait unless someone writes the order down.

When you rank campaigns, we recommend putting the message that unlocks something else ahead of the ones that only ask for something. A push permission prompt or a profile completion step changes what every later message can do.

‍

When does Braze decide whether a user is eligible?

Braze checks whether a user is in the target audience when the device downloads in-app messages, which usually happens at session start. The device stores eligible messages and shows each one when its trigger occurs. Users who become eligible during a session receive the message at their next session start.

For audiences that change quickly, Braze offers Re-evaluate campaign eligibility before displaying. It prevents cached messages from displaying when the user no longer meets the eligibility criteria. The same page states that it requires a network connection and adds a request before display, so it is not for messages that must trigger while the user is offline.

Templated delivery, which applies when that option is on or when the message uses certain Liquid tags, also needs a further network request after the trigger. Our advice is to make this choice for each message separately.

A promotion tied to a live attribute gets the fresh check. A reminder that should appear even on a weak connection stays standard and cached.

Re-eligibility is the other half of the picture. You can allow users to become eligible to receive a campaign again by turning on re-eligibility in Delivery Controls, and if it is off, users generally won't receive that same campaign again.

A one-time education message wants it off. A recurring seasonal prompt wants a deliberate window.

‍

What should each message ask a user to do?

Give each message one job and make the button the job. Braze lets you add up to two buttons and advises using Button 2 for the primary call to action. A second button should be the quiet exit, not a competing offer.

That design choice pays off later in reporting. Body clicks are not automatically collected for messages built in the drag-and-drop editor, so a message whose only action is a tap on the body leaves little to measure. Put the action on a button and you can measure it.

Push priming is the clearest example of a single job. Braze lists it among the channel's use cases: a rich in-app message that shows the benefit of opting into push and presents a prompt to grant permission. The message should say what the person gets and then ask once.

‍

How do you measure whether a message worked?

In-app messages do not use an Opens metric. Braze logs impressions when the message becomes visible on screen and clicks when users interact with the message body or buttons. If a multichannel report includes in-app rows, compare impressions and clicks, and do not expect email-style opens.

Dismissing a message logs an impression but not a click. So a low click count alone does not tell you whether people read the message and chose to move on. Pair the click count with the downstream event the message was meant to cause.

You can also segment on button clicks for up to two buttons. Set the Identifier for Reporting on those buttons so the segmentation filters line up with button one and button two. That gives you a clean follow-up audience without any custom code.

‍

What does a worked example look like?

This example is hypothetical and illustrative. It contains no client data and no results.

Imagine a subscription app with three campaigns on session start: a push priming prompt, a win-back offer for lapsed users and a new feature announcement. A returning user qualifies for all three, but only one displays per session. If nobody sets the order, the message created last wins, and the push prompt may sit behind a promotion for weeks.

Here is how we would set it. The push priming prompt goes in the high bucket with re-eligibility off, so it runs once and does not nag.

The win-back offer goes next, with the fresh eligibility check on, because a user who has already returned should not see an offer meant for lapsed users. The feature announcement goes last with a defined end date.

The success event is agreed before launch. For the prompt it is the permission outcome, for the offer it is the purchase, and for the announcement it is first use of the feature. A click on any of the three is only a step towards that event.

‍

What failure modes should you plan for?

These are the failures we plan for, each tied to documented behaviour. Review them before every launch.

• The starved campaign. A message sits behind a higher-priority one on the same trigger and never appears. Review the priority order each time a campaign launches.
• The stopped campaign that still shows. After a campaign is stopped, users who started a session before it stopped may still see the cached message when they perform the trigger event. Turn on the re-evaluation option for any campaign you may need to withdraw quickly.
• The crowded workspace. The default capacity is 200 active, action-based in-app message campaigns per workspace, though a workspace may have a different capacity. Stop campaigns that have done their job.
• The expected quiet hours. Quiet Hours isn't available for in-app message campaigns, and the Braze FAQ documents a Liquid workaround that aborts a message outside a set time window. Test it with a user in each time zone you serve.
• The offline session. If the device downloaded the payload before going offline, the message can still display. If it did not, the message does not display, so do not use this channel as the only route for critical news.

‍

How does this connect to the rest of the programme?

Triggers are the natural next topic, and our guide to in-app message triggers in Braze covers setup in detail. Audience rules sit beside them, and segmenting users for targeted in-app messaging explains how to build the audiences that decide eligibility.

Once messages are live, measuring in-app message engagement in Braze shows how to read the reports. For creative and layout choices, see how to create engaging in-app messages.

The channel only works as part of a wider plan. Our customer engagement strategy guide places in-app messaging alongside the other channels, and matching job to channel for mobile engagement helps you decide when a message belongs here and when it belongs in push.

As a Braze implementation partner, CustomerIK recommends writing the display order, the success event and the withdrawal plan on one page before any in-app message campaign launches. Keep that page with the campaign brief so the next owner can find it.

‍

Frequently Asked Questions
‍

1. Do in-app messages require push integration?

In-app messages do not require push notifications to function in production. Test sends do require push to be enabled on your test devices.

2. Can a user see more than one in-app message in a session?

Yes, but only one message can display per occurrence of a trigger event. For session start, that means one message per session.

3. Does an in-app message display when the device is offline?

It depends on the payload. If the device downloaded it before going offline, the message can still display, and if not, it does not.

4. Why can't I see opens for in-app messages?

In-app messages do not use an Opens metric. Braze logs impressions and clicks instead.

5. Can I use Quiet Hours for in-app message campaigns?

The Quiet Hours feature isn't available for use with in-app message campaigns. The Braze FAQ documents a Liquid workaround for time windows.

‍

Sources

• Braze, In-app messages. Retrieved 30 Oct 2026.
• Braze, Create an in-app message with drag-and-drop. Retrieved 30 Oct 2026.
• Braze, Create an in-app message. Retrieved 30 Oct 2026.
• Braze, In-app message FAQ. Retrieved 30 Oct 2026.
• Written by CustomerIK, a Braze implementation partner.

‍

CustomerIK is a Braze implementation partner working across onboarding, technical integration, marketing operations and customer data management.

If you want help setting the display order and success events for your in-app campaigns, let's talk.

‍