This article covers the process through which a user gets assigned a push token, and how Braze sends push messages to your users.
Understanding push tokens and what they are is a fundamental piece of understanding how we send push messages here at Braze. A push token is an identifier that senders use to target specific devices with a push notification. If a device doesn’t have a push token, there is no way to send push to it.
Push tokens are generated by push service providers. Braze connects with push service providers like Firebase Cloud Messaging Service (FCMs) for Android and Apple Push Notification Service (APNs) for iOS, and those providers send unique device tokens that identify your app. Each device has one, unique token that is used for messaging. Tokens can expire or be updated.
Push token registration
Platforms deal with push token registration in different ways:
- Android: Automatically registered for push. Receives a token as soon as a user downloads and opens an application.
- iOS: Not automatically registered for push.
- iOS 12 (with Provisional Authorization):
If you have provisional authorization set up, you can send notifications silently to the Notification Center of the device. These notifications may prompt users to decide to continue to receive notifications. Their push subscription state depends on the user’s response to this prompt.
- iOS 11 and later & iOS 12 (without Provisional Authorization):
The native push notification prompt appears for new users to an application. Users respond to this prompt by selecting allow or deny. Deny denies push token registration, therefore denying push notifications to their phone from that application. Allow registers and creates a new push token, then and there.
- iOS 12 (with Provisional Authorization):
- Web: Not automatically registered for push. The native push notification prompt appears for new users to your website. Users respond to this prompt by selecting allow or block. Block denies push token registration, therefore denying push notifications to their phone from that application. Allow registers and creates a new push token, then and there.
|Get a push token||Send a push token|
|Applications must register with a push provider in order to get a push token for a device.||Developers can then target the device using the push token generated by FCM/APNs.|
Check user’s push subscription state
There are two ways you can check a user’s push subscription state with Braze:
- User Profile: You can access individual user profiles through the Braze dashboard on the User Search page. Here, you can look up user profiles by email address, phone number, or external user ID. Once in a user profile, you can select the Engagement tab to view and manually adjust a user’s subscription state.
- Rest API Export: You can export individual user profiles in JSON format using the export Users by segment or Users by identifier endpoints. Braze will return a push tokens object that contains push enablement information per device.
Push token management
Check out the following chart for actions that lead to push tokens changes or removal from user profiles.
|Push error occurs||Some common push errors that lead to token removal include
Check out our full list of common push errors.
|User uninstalls||When a user uninstalls the application from a device, Braze will remove the user’s push token from the profile.|
What does this look like on a broader scale?
When a user opens a new application, if push has been configured correctly, a call is made from the Braze SDK to the push providers. When that call is made, the push provider runs a check to see if everything is set up correctly. If so, a push token gets passed into your device. When that token arrives, the SDK communicates this to Braze. Once Braze has received the token from the push provider, we update or create a new user profile. These users are now considered registered.
If we want to launch a campaign, we create a campaign in Braze that generates a push payload to send to the push provider. From there, the provider delivers the push payload to the user’s device and the SDK passes the messaging state to Braze.
|Registration steps||Messaging steps|
|1. Customer (device) registers to push provider
2. Provider generates and delivers push token
3. Flush tokens in Braze
|1. Braze sends push payload to provider
2. Provider delivers the push payload to the device
3. SDK passes messaging stats to Braze
Frequently asked questions
What happens when an opted-in user deletes and then redownloads my app?
Suppose a user opts-in for push, receives some push messaging, and then later deletes the app. This will remove the push consent at the device level. From here, the first bounced push after the uninstall will automatically result in that user being opted-out of future push messaging. After this, if a user were to reinstall the app but not launch it, Braze won’t be able to send a push to the user because push tokens have not been re-granted for your app.
Additionally, if a user were to re-enable foreground push, it would require a session start to update this information in their user profile to begin receiving push messaging.
Under what circumstances do push tokens expire?
Unfortunately, APNs and FCM don’t really define this. Push tokens can expire when an app is updated, when users transfer their data to a new device, or when they re-install an operating system. For the most part, we don’t really have insight into why push providers will expire certain push tokens.
To account for that ambiguity, our SDK push integrations always register and flush tokens on session start to ensure we have the most up-to-date token.