.svg)
Push subscription state and push registration are two different things in Braze. A segment can look healthy while part of it cannot be reached at all. State records a preference across the whole profile. Registration records whether a device has a valid foreground token. Segment on one and you will miss the other.
Key Takeaways
- Subscription state is a preference held at the profile. Push registration is a fact about a device. The two move independently.
- Every new profile starts as Subscribed, which records that nobody has said otherwise, not that anyone agreed.
- Read Subscribed, Opted-In and Unsubscribed alongside token registration and current operating-system permission. An OS-level change does not necessarily update the Braze subscription field; maintain the intended preference behavior in your integration.
- A user can be Subscribed with no valid token, which is why a segment can be larger than its Reachable users count.
- Foreground Push Enabled is the filter that combines both halves, the token and the preference.
- Permission behavior depends on the platform and target SDK. Explain the benefit before asking, respect refusals, and follow the current operating-system rules for any later prompt.
What does a push subscription state actually tell you?
State is a preference held at the profile, not at the device. Braze holds three values: Subscribed, Opted-In and Unsubscribed. Subscribed is what every new profile starts as.
That default is the part worth sitting with. Subscribed does not mean anyone agreed to anything. It means nobody has said otherwise yet, and Braze moves the profile to Opted-In only when the user accepts an OS-level prompt.
Read Subscribed, Opted-In and Unsubscribed alongside token registration and current operating-system permission. An OS-level change does not necessarily update the Braze subscription field; maintain the intended preference behavior in your integration.
Why is your segment bigger than your reachable count?
Because they measure different things, and both numbers are correct.
Segment membership follows your filters. Reachable users follows push registration, which means a valid foreground token sitting on the profile. A user can be Subscribed with no token at all, and that user stays in the segment while counting for nothing.
The iOS install path shows how ordinary this is.
User actionForeground Push EnabledRegistrationStateInstalls, logs a sessionfalseBackgroundSubscribedTaps Allow on the prompttrueForegroundOpted-InTaps Don't AllowfalseBackgroundNot updatedTurns push off in settingsfalseBackgroundNot updatedDeletes the appNot updatedRetired with the tokenNot updated
Three of those five rows leave the state untouched. A segment built on state alone treats all five identically, which is where the gap between audience size and delivery comes from.
Which filter should each segment use?
Match the filter to the question you are actually asking.
QuestionFilter to useCan we deliver a visible push to this person anywhereForeground Push EnabledCan we deliver it in this specific appForeground Push Enabled for AppCan we send a silent push for background workBackground or Foreground Push EnabledHas this person told us to stopPush subscription state
Foreground Push Enabled is the workhorse because it combines both halves: the token and the preference. It counts foreground push only and leaves out anyone unsubscribed.
Foreground Push Enabled for App is narrower and easier to misread. It looks at token presence for one app, so a multi-app workspace can show a user enabled in one place and absent in another. That is correct behaviour, and it reads as a bug if you expect a profile-level answer.
What order should you build push segments in?
- Read Subscribed, Opted-In and Unsubscribed alongside token registration and current operating-system permission. An OS-level change does not necessarily update the Braze subscription field; maintain the intended preference behavior in your integration.
- Add the registration filter that matches the app or apps you are sending from.
- Layer behaviour and lifecycle filters on top of those two.
- Compare segment membership against Reachable users before launch, and expect a gap.
- Write down what the gap should be, so a change in it becomes a signal.
Step four is the cheapest diagnostic here, and the easiest one to leave out. The gap is not an error. It becomes one when nobody knows what size it usually is.
Where does state drift from reality?
1. A shared device
Tokens belong to a device and an app, so they cannot tell two people apart. When one user logs out and another logs in, the token moves to the new profile. The old profile keeps its state and loses its route with no visible change.
2. An uninstall
Deleting the app leaves the state untouched. Braze treats an Android user as push disabled after an uninstall, a bounce, a failed registration with Firebase Cloud Messaging, or a settings change followed by a session.
3. An expiring web token
A 410 error can mean the browser invalidated the token, which happens periodically. State says nothing about it.
4. A user on Android 12 or earlier
Permission was not required before Android 13, so those profiles sit at Subscribed from their first session without anyone choosing it.
The pattern is consistent: state changes when a person acts inside your product, and registration changes when a device does something. Your retention campaigns should read both, since a lapsing user and an unreachable one need different treatment.
How does this change what you send?
Permission behavior depends on the platform and target SDK. Explain the benefit before asking, respect refusals, and follow the current operating-system rules for any later prompt.
That makes early lifecycle work the highest-leverage moment for push. Your onboarding journey and your activation campaigns decide how much of your base is reachable for everything that follows.
For the users you can reach, the segment defines the audience and the message still has to earn attention. That is where personalisation and dynamic content do their work.
Test preference and registration separately
A profile's subscription preference and a usable token for the intended app answer different questions. Test an eligible user, an explicitly unsubscribed user, OS-level notifications disabled and a multi-device user.
Permission rules vary across iOS, Android and web. Follow current platform and SDK behavior, respect refusals and verify the intended device scope on real test devices. A profile-level filter is not proof of delivery to one particular device.
| Test case | Expected result |
|---|---|
| Subscribed but no valid token | Treat as unreachable for that push |
| OS permission withdrawn | Verify registration and preference behavior |
| Several devices exist | Check the delivery destination configuration |
The worked example and test cases are illustrative editorial guidance, not measured client outcomes or a claim that a live integration has been tested.
Frequently Asked Questions
1. A user turned push off in their phone settings. Why are they still Subscribed?
Because Braze does not change subscription state from an OS-level action. State reflects a preference recorded in Braze. Registration reflects the device, and that is what changes.
2. Should we set users to Unsubscribed when they disable notifications on the device?
That depends on what you want the value to mean. Treating it as a user-stated preference keeps it useful, and the registration filters already handle reachability.
3. Why does my segment show more users than Reachable users?
Segment membership follows your filters, and users without push registration stay in the segment unless a filter removes them. The two counts are answering different questions.
4. Can two people on one device be targeted separately?
No, because tokens are tied to a device and an app rather than a person. The token follows whoever logged in last.
5. Does an uninstall update the subscription state?
It does not. Registration is updated when the token is retired, and the state stays where the user last left it.
Sources
- Braze, Push subscription states. Retrieved 04 Sep 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 your push audience looks bigger on the dashboard than it does in delivery, let's talk.
.svg)
