Braze Push Notifications: Complete Guide

What Are Braze Push Notifications?

Push notifications are device-level alerts delivered outside the app itself -- appearing on a user's lock screen or notification center, designed for immediate visibility and urgency in a way that a persistent in-app channel like Content Cards isn't. Push depends entirely on the SDK's device registration capability and requires explicit user permission at the OS level before any notification can actually be delivered.

Push Notification Types

Core Capabilities

Personalization: The same Liquid, Connected Content, and Catalog capability available across other Braze channels extends to push, letting notification content adapt per recipient.

Deep Linking: Notifications can direct users to a specific in-app screen or content, rather than just opening to a generic default view -- meaningfully improving the post-tap experience.

Intelligent Timing: Where available, send timing can be optimized per individual user based on their historical engagement patterns, rather than a single fixed send time for the entire audience.

Action Buttons: Supported formats let users respond directly from the notification, reducing friction for simple actions that don't require opening the full app.

How to Get Started

1. Confirm SDK integration is complete, including device token registration for push delivery.

2. Design your permission request flow thoughtfully, since users who deny permission can't receive push at all.

3. Build your first push campaign or Canvas step, using personalization where relevant.

4. Configure deep linking so taps take users to genuinely relevant in-app content.

5. Test across both standard and rich formats, and consider A/B testing copy and timing.

Rich Media and Engagement

Rich push (including an image) generally outperforms plain text in engagement, but the effect isn't automatic -- a few practices affect whether rich media actually helps.

Relevance over decoration: An image that directly reinforces the message content (a product photo for a product-related notification) performs better than a generic decorative image that doesn't add genuine informational value.

Load time and reliability: Rich media depends on the image loading successfully on the device -- a template should degrade gracefully to text-only if the image fails to load, rather than resulting in a broken or blank notification.

Platform-specific rendering: Image display can vary somewhat between iOS and Android, worth testing across both rather than assuming identical rendering.

Key Metrics to Track

Opt-in rate: What percentage of users who could receive push actually granted permission -- the ceiling on your entire addressable push audience.

Delivery rate: Of push notifications sent, how many actually reached the device (accounting for uninstalls, token expiration, and other delivery failures).

Open/interaction rate: How many delivered notifications were actually tapped or acted upon, the core engagement signal for evaluating message effectiveness.

Uninstall correlation: Whether push frequency or content correlates with subsequent app uninstalls -- a signal that's easy to overlook but genuinely important, since over-aggressive push can drive users away from the app entirely, not just toward disabling notifications.

Since push notifications require explicit OS-level permission, when and how you ask for that permission meaningfully affects your total addressable push audience. Asking immediately on first app open, before a user has experienced any value, often results in a lower opt-in rate than asking after a meaningful moment -- completing onboarding, or right before a genuinely relevant feature (like order tracking) that push would enhance. Some apps use a soft pre-permission prompt first, explaining the value of notifications before triggering the actual OS permission dialog, reserving that harder, one-shot ask for when opt-in likelihood is genuinely higher.

A Real-World Example

A food delivery app wants to notify users the moment their order status changes -- confirmed, preparing, out for delivery, arrived. Rather than requesting push permission immediately at signup (before the user has any order to track), the app waits until the first order is actually placed, presenting a soft explanation of order tracking notifications right before the OS permission prompt. This timing, combined with deep links taking users directly to their live order tracking screen rather than the app's home screen, drives meaningfully higher opt-in and engagement than a generic "enable notifications" ask at first launch would have.

Six months after launch, the team notices delivery rates for one notification type -- the "arrived" alert -- are noticeably lower than the others. Investigation reveals the issue: this specific notification was configured without proper fallback handling for a rare edge case in the order data, causing silent send failures for a meaningful subset of orders. Because the team was tracking delivery rate per notification type rather than only aggregate push performance, they caught and fixed this specific gap quickly -- a level of granular monitoring that a simpler, single aggregate metric would have masked entirely.

Frequently Asked Questions