Learn about push notification delivery, including how it is delivered and why it might fail.
Push notification deliveryPush notification delivery
Push notification delivery refers to when a push notification is successfully delivered to a recipient’s device.
A profile may have more than 1 push token if they have your mobile app installed on multiple devices. Push notifications will be attempted for all the devices with a token stored on the profile.
The concept of deliverability does not apply to push notifications like it does for email, as there is no sorting performed once the recipient’s device successfully receives the notification.
When you send a push notification through a campaign or flow, Klaviyo checks the push and then sends it to Apple Push Notification Service (APNs) for iOS, or Android’s push notification service, Firebase Cloud Messaging (FCM) for delivery to the recipient’s device. You may see some push notifications skipped if there is an issue with delivery.
APNs and FCM will either accept the notification and attempt to deliver it to the recipient's device, or reject the notification with a series of possible errors.
Klaviyo only has insight into whether these services accept the notification or reject it. Klaviyo cannot confirm if the notification fails after APNs or FCM accepts the push.
Want to request a feature for Klaviyo push notifications? Fill out this Google form to tell us about it!
Reasons for rejection
If Klaviyo receives an error response from APNs or FCM after sending a notification, an event called Bounced push is created for each token affected by the failed delivery. This will appear in the receiving profile’s activity feed along with the recipient activity for the respective flow or campaign the notification was sent from.
The Bounced push event includes metadata that shows the error code message (e.g., ExpiredToken) returned by APNs or Firebase. If you are seeing delivery issues, work with your app developer to resolve the error based on the description in the event.
To view the metadata for an event, click on Activity details for the event on the profile’s activity log.
iOS
For iOS push notifications sent through APNs, rejections may occur for at least one of the reasons listed in Apple’s reference for handling notification responses from APNs.
| Status code |
APNs error string |
APNs description |
|
400 |
BadDeviceToken |
The specified device token was bad. Verify that the request contains a valid token and that the token matches the environment. |
|
400 |
BadTopic |
The apns-topic value is invalid. |
|
400 |
DeviceTokenNotForTopic |
The device token does not match the specified topic. |
|
400 |
DuplicateHeaders |
One or more headers were repeated. |
|
400 |
IdleTimeout |
Idle time out. |
|
400 |
InvalidPushType |
The apns-push-type value is invalid. |
|
400 |
PayloadEmpty |
The message payload was empty. |
|
403 |
BadCertificate |
The certificate was bad. |
|
403 |
BadCertificateEnvironment |
The client certificate was for the wrong environment. |
|
403 |
InvalidProviderToken |
The provider token is not valid or the token signature could not be verified. |
|
404 |
BadPath |
The request contained a bad :path value. |
|
405 |
MethodNotAllowed |
The specified :method was not POST. |
|
410 |
ExpiredToken |
The device token has expired. |
|
410 |
Unregistered |
The device token is inactive for the specified topic. |
|
429 |
TooManyProviderTokenUpdates |
The provider token is being updated too often. |
|
500 |
InternalServerError |
An internal server error occurred. |
|
503 |
ServiceUnavailable |
The service is unavailable. |
Android
For Android push notifications sent through FCM, rejections may occur for at least one of the reasons listed in Google’s reference for FCM error codes.
|
Status code |
FCM error string |
FCM description |
|
400 |
INVALID_ARGUMENT |
Check the format of the registration token you pass to the server. Make sure it matches the registration token the client app receives from registering with Firebase Notifications. Do not truncate or add additional characters. |
|
400 |
INVALID_ARGUMENT |
Make sure the message was addressed to a registration token whose package name matches the value passed in the request. |
|
400 |
INVALID_ARGUMENT |
Check that the total size of the payload data included in a message does not exceed FCM limits: 4096 bytes for most messages, or 2048 bytes in the case of messages to topics. This includes both the keys and the values. |
|
400 |
INVALID_ARGUMENT |
Check that the payload data does not contain a key (such as from, or gcm, or any value prefixed by google) that is used internally by FCM. Note that some words (such as collapse_key) are also used by FCM but are allowed in the payload, in which case the payload value will be overridden by the FCM value. |
|
400 |
INVALID_ARGUMENT |
Check that the value used in ttl is an integer representing a duration in seconds between 0 and 2,419,200 (4 weeks). |
|
400 |
INVALID_ARGUMENT |
Check that the provided parameters have the right name and type. |
|
403 |
SENDER_ID_MISMATCH |
The authenticated sender ID is different from the sender ID for the registration token. |
|
404 |
UNREGISTERED |
App instance was unregistered from FCM. This usually means that the token used is no longer valid and a new one must be used. |
|
429 |
QUOTA_EXCEEDED |
Sending limit exceeded for the message target. An extension of type google.rpc.QuotaFailure is returned to specify which quota was exceeded. |
|
500 |
INTERNAL |
An unknown internal error occurred. |
|
503 |
UNAVAILABLE |
The server is overloaded. |
You will also see a Bounced push event if the recipient is missing or has an invalid push token.
Best practices
Collect user consentCollect user consent
In order to send a push notification to a profile, you must collect their explicit consent first.
To collect push notification consent, you must provide customers with a permission screen prompt during their first interaction with your mobile app.
It is best practice for your permission screen prompt to include consent language that provides the following information and allows them to opt in or opt out:
-
What types of notifications your brand sends
Include details about the different push notifications your brand plans to send (for example, account changes, account changes, reminders, and special discounts). -
Why users should opt in
Include information around why a customer should provide permissions (for example, to receive important updates or early access to sales).
Learn more about collecting push notification consent.
Send relevant notificationsSend relevant notifications
When sending push notification campaigns, it is important to take advantage of Klaviyo’s segmentation to send content that is personalized and relevant to your subscribers.
For example, if you know that you have a segment of dedicated repeat customers, you could use push notifications to alert them to new deals or promotions before anyone else.
By ensuring that the content you send customers is relevant to their interests and preferences, you can reduce the likelihood of customers opting out and maximize your ability to reach your customers with push notifications.
Monitor and analyze performanceMonitor and analyze performance
It is essential to continually monitor your push notification performance with Klaviyo to quickly identify delivery issues and drops in key push metrics.
The best way to do so is to monitor the following push notification events:
- Received push
- Opened push
- Bounced push
You can set up a multi-metric report in Klaviyo to monitor how your performance with these events changes over time.
Additional resourcesAdditional resources
Understand push notification consent