Sound in Push Notifications (SDK Implementation for Retention Teams)

Overview

If you’re running push through Customer.io, sound is one of those small levers that can swing outcomes—especially for high-intent moments like cart recovery or back-in-stock. If you want a second set of eyes on your tracking + orchestration so sound is used intentionally (not spammy), book a strategy call.

In most retention programs, sound performs best when it’s tied to urgency and user intent—not as a blanket “make all pushes louder” switch. The real work is getting clean device identity, correct event timing, and consistent payload behavior across iOS/Android so you don’t accidentally create an inconsistent customer experience.

How It Works

Push notification sound isn’t something Customer.io “decides” on its own—it’s driven by the payload you send to Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM). Customer.io ultimately delivers a push payload to the device, and the OS decides whether to play a sound based on (1) the payload, (2) the app’s notification settings, and (3) the device’s Focus/DND state.

• iOS (APNs): sound is controlled via the aps.sound field. You typically use default or a bundled sound file name (e.g., cart_alert.caf) included in your app.
• Android (FCM): sound behavior depends on whether you’re using notification channels. In practice, channels win—if the channel is configured as silent, no payload tweak will fix it. You usually configure sound on the channel, not per-message.
• Customer.io SDK role: the SDK registers the device token, ties it to a person profile, and ensures the correct device receives the push. If identity stitching is messy (anonymous vs logged-in), your “sound push” might go to the wrong device—or not go at all.

A realistic D2C scenario: someone adds a product to cart in your app, bounces, and you send a push 30 minutes later. If they’ve opted into notifications, a subtle default sound can lift opens—but only if the device token is current and the cart event is attributed to the same identified profile that owns the token.

Step-by-Step Setup

Before you touch message settings, make sure your SDK implementation is solid. Sound is a “last-mile” enhancement—if device registration and identity are off, you’ll spend time tuning creative while delivery silently underperforms.

1. Install and initialize the Customer.io Mobile SDK
   • Implement the Customer.io SDK for your platform (iOS/Android/React Native/Flutter, etc.).
   • Confirm the SDK is initializing on app start and can reach Customer.io (watch device registration logs in debug builds).
2. Request notification permission and register for push
   • iOS: request authorization (alerts/sounds/badges) and register for remote notifications; pass the APNs token to the SDK.
   • Android: ensure FCM is configured; for Android 13+, request POST_NOTIFICATIONS permission; confirm the FCM token is captured and forwarded.
3. Get identity stitching right (critical)
   • Call identify as soon as a user is known (login, account creation, or email capture).
   • If you track pre-login behavior (browsing, add-to-cart), capture events as anonymous and then merge/associate once identified—otherwise your cart abandon push may never find the right device.
   • On logout, clear/reset identity per your implementation so devices don’t stay attached to the wrong profile.
4. Track the events that justify “sound-worthy” pushes
   • Send high-intent events like Added to Cart, Checkout Started, Product Back In Stock, Order Shipped.
   • Include useful properties for segmentation and suppression: SKU, category, cart value, item count, and timestamp.
5. Configure sound behavior in your push messages
   • iOS: set the push payload sound value to default (or your custom bundled sound file name).
   • Android: decide your notification channel strategy:
     • Create a “high intent” channel that uses sound (cart/back-in-stock).
     • Create a “low intent” channel that is silent (content, education).
     • Route messages to the right channel consistently—changing sound per message won’t work reliably if the channel is misconfigured.
6. QA on real devices (not just simulators)
   • Test iOS with ringer on/off, Focus modes, and notification settings enabled/disabled.
   • Test Android across OS versions and verify channel sound settings in system UI.
   • Confirm the same user receives the push on the expected device after login/logout cycles.

When Should You Use This Feature

Sound is best treated like a priority flag. If you attach sound to everything, customers will either disable notifications or uninstall—both are retention losses you don’t get back easily.

• Cart recovery (high intent): use sound for “you were close” reminders, especially within the first 1–2 hours after abandonment, when purchase probability is still high.
• Back-in-stock / low-inventory: sound makes sense when the customer has expressed intent (viewed product repeatedly, wishlisted, or subscribed).
• Delivery exceptions: if an order is delayed or needs action, sound can reduce support tickets and protect LTV.
• Winback with a hard hook: for churn-risk users, only use sound if the message is genuinely time-sensitive (expiring credit, limited restock). Otherwise keep it silent and rely on timing + personalization.

Operational Considerations

Where teams get tripped up is assuming “sound on” is a creative decision. In practice, it’s a data-flow and orchestration decision—especially across platforms.

• Segmentation: build segments that reflect permission state and engagement, not just lifecycle stage. For example, target “push-enabled AND added_to_cart in last 2 hours AND no purchase event since” rather than blasting all cart abandoners.
• Data flow timing: cart events often fire client-side and can be delayed by app backgrounding. Add a small buffer (e.g., 5–10 minutes) before triggering the journey to avoid false abandons when someone completes checkout right after.
• Identity stitching: if a user adds to cart anonymously and then logs in on a different device, you need a clear merge strategy—or your sound push goes to the wrong place.
• Orchestration reality: coordinate sound pushes with email/SMS so you don’t stack touches. A common pattern is: push (sound) first for app-native users, then email if no open/click, then SMS only for high-value carts.
• Platform differences: iOS sound is message-level; Android is often channel-level. Your journey logic should map “priority” to the right technical implementation per OS.

Implementation Checklist

Use this as your “did we actually implement this correctly?” list before you start optimizing creative or adding more journeys.

• Customer.io Mobile SDK initialized and device tokens successfully registered
• identify called reliably on login/account creation; logout resets handled
• Anonymous-to-known behavior handled (merge/associate strategy defined)
• Core retention events tracked with consistent naming and properties (cart, checkout, purchase)
• iOS push payload includes aps.sound = default (or approved custom file)
• Android notification channels created and mapped to message priority (sound vs silent)
• Segments exclude purchasers and suppress recently-messaged users
• QA completed on real devices across OS versions and notification settings

Expert Implementation Tips

Once the basics are working, the wins come from treating sound like a controlled variable and measuring it like any other conversion lever.

• Create a “sound eligibility” attribute: set a person attribute like push_sound_ok=true only after they’ve opened a push in the last 30 days. In practice, this keeps sound focused on users who actually respond to push.
• Use sound as a tier in your urgency ladder: silent push for browse, sound push for cart, and reserve SMS for high AOV carts only.
• Instrument opens properly: confirm your SDK is capturing push opens/deep links so you can measure whether sound is lifting action, not just deliveries.
• Protect Android channel integrity: once a channel is created, users can override it. If you need a new default behavior, ship a new channel ID (e.g., promo_silent_v2) rather than trying to “fix” the old one.

Common Mistakes to Avoid

Most “sound didn’t work” issues aren’t Customer.io problems—they’re identity, channel configuration, or event timing problems.

• Turning on sound globally: customers disable notifications fast; your deliverable audience shrinks and your cart recovery rate drops.
• Forgetting Android channels: teams set sound in the payload but route to a silent channel—result: no sound, inconsistent QA, and lots of confusion.
• Mis-stitching identities: cart event is anonymous, device token is identified, and the journey never matches the user you think it does.
• No purchase suppression: users who already converted still get the “complete your order” sound push. That’s an immediate trust hit.
• Testing only on one device state: Focus/DND, ringer switch, and OS-level settings will change outcomes. QA across real-world states.

Summary

If you’re already sending push, sound is a high-leverage tweak—but only when your SDK tracking, identity stitching, and Android channel strategy are clean. Treat sound as a priority layer for high-intent moments like cart and back-in-stock, and measure it like an experiment.

Implement Sound In Push with Propel

If you’re tightening up push performance in Customer.io, sound is usually the easy part—the harder part is making sure the right user, on the right device, gets the right priority message at the right time. If you want an operator’s take on your SDK events, identity stitching, and journey suppression logic, book a strategy call.