Push Notification Tactics for Engaging Customers in Braze

Push notification tactics in Braze work best in a fixed order: earn permission with a primer, protect reach with in-app subscription controls, then set pressure rules with frequency caps and quiet hours. After that, measure conversions and retire unresponsive users. This post sets out the sequence and what the Braze documentation says about each step.

‍

Key Takeaways

• The native push prompt can be displayed only once per install, so the primer carries the case for opting in.
• The no-code primer suppresses itself by device state, so you don't add push status filters.
• Braze checks the frequency cap before quiet hours, and a capped user is skipped rather than held.
• Conversion events can count for up to 30 days, and a fixed deadline gives comparable results.
• A sunset policy stops push to users with no direct or influenced open and hands them to email or in-app messages.
• We recommend setting the pressure rules and the exit rule before the first campaign launches.

‍

Which Braze push notification tactics come first?

As a Braze implementation partner, we recommend sequencing push work in the order a user meets it: permission, reach, pressure, measurement, exit. Each stage depends on the one before. A well-timed message does nothing for a device that never granted permission.

‍

We recommend building stages three and five before the first campaign goes out. Both are cheaper to set up early than to retrofit once a programme is live.

‍

How should you ask for push permission?

The Braze push best practices page says you only get one chance to ask for push permission. It adds that after a user declines, it's very hard to convince them to switch push back on in device settings. The push primer is an in-app message that explains what people can expect before the system prompt appears.

The operating system enforces the limit: the native prompt can be displayed only once per install. Google's Android documentation says Android 13 (API level 33) and higher supports a runtime permission for sending non-exempt notifications from an app. Braze documents that two denials on Android 13 and later block further prompts, including Braze primer messages.

Braze suggests waiting until a user completes a high-value action, or until there's a compelling need push can address, such as shipping tracking after an order. So the primer is where you make the case, and timing is the larger part of the tactic. To build one, follow the push primer guide:

1. Create an in-app message with a fullscreen or modal layout, so there's room for copy and two buttons.
2. Say which types of notification you'll send and what value they give.
3. Add a "Not now" button set to Close Message and an "Allow notifications" button set to Request Push Permission.
4. Schedule it as an action-based message with Perform Custom Event as the trigger.
5. Ask your developers to remove any existing code that requests push permission, so the primer is the first request users see.

‍

Targeting needs care because Braze holds user data at the profile level, while permission lives on each device. A user-level filter such as Push Subscription Status is not Opted In excludes people already opted in on another device. They never see the prompt on a new one.

With the no-code primer, the SDK checks the permission state of the device itself. It suppresses the message, so you don't add push status filters.

That suppression depends on using the Request Push Permission button action. Custom logic or a deep link displays the message whatever the device's state. If a team has built its own primer, we recommend checking this before assuming the suppression applies.

‍

How do you keep people opted in once they say yes?

Braze notes that turning notifications off at device level completely removes the foreground push token. Its recommended alternative is to let users control their push subscription directly within your app. A settings page in your app is one way to offer that control.

A common approach is a boolean custom attribute in Braze that mirrors each app setting. The documented example is a news app with subscription settings for breaking news, sports news and politics, each usable as a segment filter.

We suggest treating the settings page as a relevance tool too, because users tell you what they want instead of leaving you to infer it. It gives people a smaller step than switching push off altogether.

‍

How much pressure is too much?

Frequency capping is switched on by default when new campaigns are created. You set the rules in your workspace, capping by channel or by tag over minutes, days or weeks, to a maximum of 30 days. The documentation allows up to 10 rules per workspace.

Its example caps users at one push per day and three pushes per week. The frequency capping page also gives transactional messages as a case that should always reach the user.

API campaigns can ignore caps by setting override_frequency_capping to true. By default, a campaign that doesn't obey caps doesn't count toward them either.

If you also use rate limiting, Braze applies the rate limit first and the frequency cap second. It doesn't backfill users once the cap removes them. In the documented example, a rate limit of 500 with 200 users capped sends 300 messages.

Quiet hours sit alongside both. Braze checks the cap before quiet hours, so a user already at cap is skipped rather than held. Otherwise the message is held until the window ends in the user's local time zone, and the cap is checked again then.

Because held messages all send at once when the window closes, we recommend that time-sensitive campaigns don't rely on quiet hours to spread the load. Braze also recommends choosing either quiet hours or Intelligent Timing rather than both, unless policy or compliance requires quiet hours.

‍

Which delivery settings change how a push reaches the device?

By default, Braze sends to every device with a valid push token. The Push destination setting can narrow that to one device, but the choice is technical rather than behavioural. It picks the device with the newest push token, not the one with the latest session.

A token added through the API makes that device the chosen one immediately, even before the user has opened a session on it. If that device isn't push enabled, the message doesn't send.

For Android, delivery priority is a campaign-level choice. Normal suits background syncs and may be delayed to conserve battery, while High suits alerts and time-sensitive nudges.

On copy, Braze recommends roughly 30-40 characters per line of title and body. The composer's character counter doesn't account for Liquid, so test on a real device before you send.

‍

How do you measure whether a tactic worked?

Set a conversion event on every push campaign. Braze lets you count a conversion for up to 30 days after the message is received. Conversion tracking counts any open, direct or influenced, up to a fixed deadline such as three days.

An influenced open is different, because its window varies from person to person with their past engagement. We prefer the fixed conversion deadline for comparing campaigns, because it's the same for every user.

The Push Performance dashboards add a channel-wide view of performance, insights and deliverability. The Braze release notes list them as generally available on 17 Sep 2026. Check release status again before you rely on a dashboard, since it can change.

We recommend giving each stage its own measure rather than one blended open rate. Watch grant rate for the primer, token loss for the reach controls, and conversions for the message tactics.

‍

When should you stop sending push to someone?

Braze recommends a sunset policy that eventually stops push to users with no direct or influenced open for a long time. Identify them by those opens and stop gradually. Before removing push entirely, send one final notification explaining why.

That gives people a chance to show they still want it. After the policy takes effect, an in-app message can tell them other channels still deliver useful information. Braze suggests email for people who open emails, and in-app messages for everyone else, which avoid the risk of an uninstall.

The documentation gives no threshold for "a long time". Any number of days or sends is a decision for you and the product team, to be reviewed against what you see.

‍

Where can these tactics go wrong?

In our view, four failure modes are worth designing against, and each is a sequencing slip rather than a product issue. The first is a primer that fires on first launch, before the user has seen any value, so the one native prompt is spent early. The second is a hand-built primer that bypasses the button action and loses the device-level suppression.

The third is a transactional campaign set to count toward caps, which can use up room that marketing sends need. The fourth is a sunset rule with no next channel behind it, which leaves a lapsed user with no route back. Each one is cheap to catch in a pre-launch review and slow to diagnose from results afterwards.

‍

What does a worked example look like?

Imagine a hypothetical retailer launching an app in a new market. It schedules a push primer as an action-based in-app message, triggered by a first completed order. The primer offers delivery tracking as the reason to say yes.

It uses the documented cap of one push a day and three a week. The delivery-update campaign overrides the cap because it's transactional. For people who haven't opened a push for a long time, a sunset flow sends one final notification, then hands them to email or in-app messages.

This is an illustration only. It isn't client work or delivery data, and it uses no results.

‍

How does this connect to the rest of the programme?

Permission and pressure rules set the ceiling for everything else. Once they're in place, push segmentation and personalisation decide who gets what. Send timing then decides when.

Newer users need their own path, covered in push notifications for onboarding completion. Sunsetting works best when the next channel is ready, so see engaging in-app messages. Results are read in push notification analytics.

As a Braze implementation partner, CustomerIK recommends setting the pressure rules and the exit rule before the first campaign launches. Review them each quarter against the limits in the Braze documentation.

‍

Frequently Asked Questions
‍

1. Does a push primer replace the native permission prompt?

It doesn't. The primer appears first, and its Request Push Permission button then triggers the native prompt.

2. Do aborted messages count toward frequency caps?

They don't. Braze documents that aborted messages don't count toward frequency capping.

3. Does Braze hold a capped message until quiet hours end?

It doesn't. If the user is already at cap, Braze skips the send and doesn't hold it. If a message was held, it checks the cap again at the delayed send.

4. How large can a push payload be?

Braze documents a maximum payload size of 3,807 bytes and recommends keeping payloads to a few hundred bytes. Liquid renders per user, so test on a real device.

5. Do app store rules affect push promotions?

Apple's App Review Guidelines, section 4.5.4, restrict push for promotions and direct marketing. Push should not be used for those purposes unless customers have explicitly opted in via consent language displayed in the app's UI and can opt out in the app. This post doesn't settle whether your programme meets that rule or any law.

‍

Sources

• Braze, Push best practices. Retrieved 25 Oct 2026.
• Braze, Push primer in-app messages. Retrieved 25 Oct 2026.
• Braze, Create a push message. Retrieved 25 Oct 2026.
• Braze, Rate limiting and frequency capping. Retrieved 25 Oct 2026.
• Braze, Quiet hours. Retrieved 25 Oct 2026.
• Braze, Release notes. Retrieved 25 Oct 2026.
• Google, Notification runtime permission (2026). Retrieved 25 Oct 2026.
• Apple, App Review Guidelines. Retrieved 25 Oct 2026.
• This post rests mainly on Braze documentation read on 25 Oct 2026. Limits, defaults and release status can change, so check the current pages before you act on them.
• 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're planning a push programme and want permission, pressure and exit rules settled in the right order, let's talk.

‍