Understand push notification delivery
Learn about push notification delivery, including how notifications are delivered and why delivery might fail.
Push notification delivery
Klaviyo records a Received Push event when Apple’s or Google’s push notification service accepts a standard push notification for delivery. This does not confirm that the notification reached the recipient’s device.
A profile may have more than 1 push token if they have your mobile app installed on multiple devices. By default, Klaviyo attempts delivery to all eligible devices. In Push delivery, you can select Both, iOS, or Android and choose All devices or Primary Device (1 device per profile). If you select Primary Device and that device does not match the selected platform, the profile is skipped.
The concept of deliverability does not apply to push notifications like it does for email, as push notifications do not have email inbox or spam-folder placement. A device’s notification settings can still affect when and how a notification appears.
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. A notification can be skipped before it reaches these services, for example, if the profile has no push token or has denied permission for standard push notifications.
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, open the event’s menu in the profile’s activity log and select Activity details.
Silent push
You can see the delivery rate and bounce rate for an individual silent push notification. Silent push notifications use separate delivery and bounce metrics and do not contribute opens or attributed conversions to standard push performance reporting. You can also select silent push metrics in a multi-metric report.
Please note that you will see different events for silent push than for standard push, namely Received Silent Push and Bounced Silent Push.
If you are having issues with silent push notifications being delivered on iOS, note that iOS does not guarantee the delivery of silent push notifications. They may not deliver them based on the device's current state, like battery level and network connection.
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. |
A profile with no push token is skipped before Klaviyo contacts APNs or FCM. If a service rejects an invalid or expired token, Klaviyo records a Bounced Push event. Tokens can become invalid after someone uninstalls your app. Klaviyo removes tokens that the service reports as unregistered or expired.
Best practices
Collect user consent
In order to send a standard push notification to a profile, you must collect their explicit consent first.
To collect push notification consent, prompt customers to enable notifications through your app’s native permission prompt. Choose a point when customers can understand why they would receive notifications.
It is best practice to use clear consent language in your app and let customers choose whether to enable push notifications. Explain the following:
- What types of notifications your brand sends
Include details about the different push notifications your brand plans to send (for example, 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 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 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 resources
- Understanding push notification consent
Learn about push notification consent and best practices for compliance. These guidelines can help you be compliant in your consent collection practices and maintain a positive relationship with your customers.
- How to send a push notification campaign
Learn how to use Klaviyo to send push notification campaigns via your iOS or Android app.
- Understanding your push notification settings
Learn about the push notifications settings page, where you can set up push notifications for your mobile app and adjust the Smart Sending window.