If you’re having trouble with the SDK, here are some basic steps to troubleshoot your problems, and solutions to some known issues.
- Update to the latest version: When troubleshooting problems with our SDKs, we generally recommend that you try updating to the latest version. That helps us weed out issues that might have been seen in previous versions of the SDK.
debuglogging: Reproducing your issue with
debugcan help you (or us) pinpoint problems.
Don’t use debug mode in your production app
Debug mode is great for helping you find problems as you integrate with Customer.io, but we strongly recommend that you set
errorin your publicly available, production app.
- Try our test image: Using an image that we know works in push and in-app notifications can help you narrow down problems relating to images in your messages.
We’re here to help! If you contact us for help with an SDK-related issue, we’ll generally ask for the following information. Having it ready for us can help us solve your problem faster.
- Share information about your device and environment: Let us know where you had an issue—the SDK and version of the SDK that you’re using, the specific device, operating system, message, use case, and so on. The more information you share with us, the easier it is for us to weed out externalities and find a solution.
- Share your push or in-app payload: Knowing what images you used, the shape of your payload, and so on helps us reproduce the issue and figure out exactly what went wrong.
- Grant access to your workspace: It may help us to see exactly what triggers a campaign, what data is associated with devices you’re troubleshooting, etc. You can grant access for a limited time, and revoke access at any time.
Logs help us pinpoint the problem and find a solution. To capture logs from the Customer.io SDK:
Enable debug logging in your app.
You should not use debug mode in your production app. Remember to disable debug logging before you release your app to the App Store.
val builder = CustomerIO.Builder( siteId = "YOUR-SITE-ID", apiKey = "YOUR-API-KEY", appContext = this ) builder.logLevel("debug") builder.build()
In Android Studio, build and run your app on a physical device or emulator.
Select View > Tool Windows > Logcat. This shows you your device’s logs.
CIOin the top to find log messages specific to the Customer.io SDK.
Save your log and send it to our Support team at firstname.lastname@example.org. In your message, describe your problem and provide relevant information about:
- The version of the SDK you’re using.
- The type of problem you’ve encountered.
- An existing GitHub issue URL or existing support email so we know what these log files are in reference to.
If you’re having trouble, try using our test image in a message! If it works, then there’s likely a problem with your original image.
Android and iOS devices support different image sizes and formats. In general, you should stick to the smallest size (under 1 MB—the limit for Android devices) and common formats (PNG, JPEG).
|iOS||Android||In-App (all platforms)|
|Format||JPEG, PNG, BMP, GIF||JPEG, PNG, BMP||JPEG, PNG, GIF|
|Maximum size||10 MB*||1 MB|
|Maximum resolution||2048 x 1024 px||1038 x 1038 px|
If your segmentA group of people who match a series of conditions. People enter and exit the segment automatically when they match or stop matching conditions. doesn’t specify people who have an existing device, it’s likely that people entered your segment without using your app. If you send a push notification to such a segment, the “Sent” count will probably show fewer sends than there were people in your segment.
The sent status means that we sent a message to your delivery provider—APNS or FCM. It’ll be marked delivered or opened when the delivery provider forwards the message to the device and the SDK reports the metric back to Customer.io. If a person turned their device off or put it in airplane mode, they won’t receive your push notification until they’re back on a network.
Make sure you’ve configured your app to track metrics
If your app isn’t set up to capture push metrics, your app will never report
When you send a push notification to iOS devices that uses our SDK, you can opt to send the Default system sound or no sound at all. If your audience’s phone is set to vibrate, or they’ve disabled sound permissions for your app, the Default setting will cause the device to vibrate rather than playing a sound.
In most cases, you should use the Default sound setting to make sure your audience hears (or feels) your message. But, before you send sound, you should understand:
- Your app needs permission from your users to play sounds. This is done by your app, not our SDKs. Here’s an example from our iOS sample app showing how to request sound permissions.
- iOS users can go into System Settings and disable sound permissions for your app. Enabling the Default setting doesn’t guarantee that your audience hears a sound when your message is delivered!
We don’t support custom sounds yet
If you want to send a custom sound, you’ll need to handle it on your own, outside the SDK and use a custom payload when you set up your push notifications.
People won’t get your message until they open your app. If you use page rules, they won’t see your message until they visit the right screen(s), so delivery times for in-app messages can vary significantly from other types of messages.
If someone’s opened your app to the right screen and hasn’t seen your message, you should make sure that that your app and message use the same identifier. If your app identifies people by email but your message expects an ID, your message won’t be delivered!