Conversions are tracked on people, but we indicate which message drove that conversion. They’re attributed to the last email or message sent before the person enters a conversion segment. If you are tracking users performing an action or entering a segment after receiving a push, then the end-user will be marked as converted, regardless of the device we reached them on.
To do this, you’ll need to add some code to your app; first, to detect when it occurs, then to send an event to our API. We are not able to automatically track the “Opened” metric yet. You’ll need to include the
CIO-Delivery-Token parameters from the push, as documented in our Technical Integration Guide.
Push notification services don’t provide a reliable way of detecting this with absolute certainty. However, when you look at a push notification’s status, getting a
Bad Device Token error for a device is a reasonable indicator that this particular person no longer has the app installed.
Because push notifications go to so many devices, their text might get cut off at different points. What looks great on an iPad’s lock screen might get awkwardly truncated in a Pixel’s notification center.
As devices and operating systems change, so do the number of ways a push notification can be seen. The only concrete restriction is a message size limit: 4KB (4096 bytes) for both Apple Push Notification service (APNs) and Android’s Firebase Cloud Messaging (FCM). This isn’t just for the message text, but for the entire payload— this includes any other custom data being sent along with that notification.
To make sure your notifications are as successful as possible, we encourage you to:
You might be receiving an error that looks like this:
Invalid device token (APNs BadDeviceToken)
This means that Apple doesn’t recognize the token you added via our
updateDevice API call as valid for that app or environment. There are a few reasons why that might occur:
Device tokens can also be rotated by Apple for several reasons, one of which is the end-user reinstalling the app or updating their OS. Due to how frequently these tokens rotate, our recommendation is to send us an
updateDevice API call every time your app is launched to ensure that we’ve always got the latest device token.
To fix it, confirm that:
If you’re still getting this error, get in touch with us at email@example.com.
A given user’s “last used device” is the device they last used to access your app. It’s determined by the timestamp in the most recent
identifyDevice API call. We recommend calling this every time your app is launched to keep the “Last Used” value up to date.
This is sometimes a friendlier way of targeting people rather than sending to every device they own, because it means they only receive one message.
iOS and Android’s push notification services don’t generally provide this information. There are some platform-specific ways to add code to your app to detect that a notification was received when the app is in the foreground or background. However, this won’t catch notifications received when your app isn’t running.
You can do this with our custom payloads feature right now, by using raw JSON code. It’s not available in the UI just yet, but is on our roadmap for the feature! Get in touch and tell us what you need! We’re looking to hear more about the types of content you need in the push notifications you’ll be sending.
We recommend that you set up a separate workspace for testing your push notifications, even if (in the case of iOS, for example) you use the same configuration credentials for testing and production.
Device tokens are located on an individual’s Person page:
Find them by searching for a specific person to whom you’d like to send the test, and then heading to the Devices tab. You can then quickly copy and paste the token for the device you’d like to send to:
To do this, we recommend that you create a new workspace, in which push notifications are configured with the certificates for your test app. You can also swap the certificates in your configuration.
Yes, you can! You will see this option in your iOS configuration:
It will be available for you if you have not set up Android as well. If you select this option, you will still need to setup the configuiration for Android if you haven’t yet done so.
Whether or not you should do this depends entirely upon your setup and what’s easier for you. For example, if FCM is a critical part of your infrastructure, and you don’t plan on configuring the Apple Push Notification Service anytime soon, this may be a valuable option.
On the push notification workflow item, you’ll be able to select a specific platform:
A push notification with a platform specified here will only be sent if a customer has a device with that platform!
If you find that push notifications are missing a critical feature, let us know what it is, and what kind of messages you’d like to send using it. As an intermediate workaround, webhooks are really powerful!