Sound in Push Notifications (Mobile SDK Setup for Retention)

Overview

If you’re sending mobile push through Customer.io, sound is one of the few levers that can meaningfully change open rate when timing matters (cart recovery, back-in-stock, delivery issues). If you want a second set of eyes on how to wire the SDK events + identity stitching so sound only hits the right moments, book a strategy call.

Sound isn’t a “growth hack.” It’s an attention tax. Used sparingly, it helps you win the moments where a silent push gets ignored. Used broadly, it drives opt-outs and disables notifications entirely—especially in D2C where you’re already competing with SMS, email, and other apps.

How It Works

Push “sound” is ultimately controlled by the payload your app receives from APNs (iOS) or FCM (Android). Customer.io sits upstream: you configure the push message in Customer.io, and the platform sends a payload to the push provider. Your OS then decides whether to play a sound based on the payload + the user’s device settings.

• iOS: Sound is driven by the sound field in the APNs payload. It can be default or a bundled custom sound file (e.g., checkout_chime.aiff) included in your app.
• Android: Sound is typically controlled by the notification channel (Android 8+). The payload can request a sound, but the channel configuration often wins. If the channel is silent, your push is silent no matter what you do in Customer.io.
• Customer.io’s role: Customer.io passes the sound configuration through in the push notification setup. Your job is to ensure the SDK is installed correctly, devices are registered to the right profile, and events are tracked so you only send “audible” pushes to high-intent situations.
• Identity stitching matters: If your app is still treating a shopper as anonymous when they add to cart, your “sound push” might never fire (or it fires to the wrong profile). The difference between an audible cart recovery push and nothing at all is usually identify timing and device association.

Step-by-Step Setup

Before you touch sound settings, make sure your mobile tracking is clean. In practice, teams try to “fix performance” with louder pushes when the real issue is that events aren’t tied to the right person/device.

1. Install the Customer.io mobile SDK
   Confirm you’re using the official SDK for your stack (iOS/Android/React Native/Flutter/etc.) and that push is enabled in the SDK configuration.
2. Register the device token with Customer.io
   On iOS, capture the APNs device token; on Android, capture the FCM token. Verify the token shows on the person’s profile as a device.
3. Implement identify at the right moment
   Call identify as soon as you have a stable customer identifier (login, account creation, or email capture). Don’t wait until purchase.
   • If you support guest checkout, identify on email/phone capture so cart events stitch to a real profile.
   • If you use anonymous browsing, ensure you merge anonymous activity into the known profile when the user identifies.
4. Track the events that justify using sound
   At minimum, track:
   • product_viewed (with product_id, category)
   • add_to_cart (with cart_id, value, items)
   • checkout_started (with cart_id, value)
   • order_completed (with order_id, value)
   The point is to avoid “sound for everyone” and instead target high-intent drop-offs.
5. Configure sound in your push template (Customer.io)
   In your push message settings, set the sound:
   • iOS: use default for system sound, or your custom filename if you’ve bundled it in the app.
   • Android: align the message with the correct notification channel. If you need sound, the channel must be created/updated in the app to allow sound.
6. QA on real devices (not just simulators)
   Test:
   • Phone on silent / focus mode / do-not-disturb
   • Notification permissions off → on
   • Android channel set to silent vs default
   This is where most “sound doesn’t work” tickets come from.

When Should You Use This Feature

Sound is best when the user has already raised their hand and the message is time-sensitive. If you’re trying to manufacture intent, sound usually backfires.

• Cart abandonment (high intent): A shopper adds a $78 cart, starts checkout, then disappears. A single audible push 30–60 minutes later (“Your cart’s saved — checkout takes 20 seconds”) often beats three silent nudges.
• Back-in-stock for a previously viewed SKU: If they viewed the same product multiple times or joined a waitlist in-app, an audible push is justified because it’s genuinely utility.
• Delivery exception / order issue: Audible push can reduce support tickets when it’s truly urgent (failed delivery attempt, address needed).
• Reactivation for proven repeat buyers: For customers with 3+ orders where you’re dropping a VIP early access window, sound can work—if you cap it hard (e.g., once per month).

Operational Considerations

Sound changes the cost of a send. Operationally, that means your segmentation and orchestration need to be tighter than your normal push program.

• Segmentation:
  • Only target users with push enabled and a recent session (e.g., last 14–30 days). Stale devices + audible pushes are a fast path to opt-outs.
  • Gate sound behind intent: checkout_started without order_completed in X minutes, or add_to_cart with cart value above a threshold.
  • Exclude people who recently converted or recently received an audible push (frequency cap at the person level).
• Data flow & accuracy:
  • Make sure event timestamps are consistent (server vs device time). If your “30 minutes after checkout started” delay is wrong, you’ll blast sound at bad times.
  • Confirm device tokens are attached to the identified profile. If a user logs in after browsing, you need the anonymous-to-known merge so the cart event triggers the right push.
• Orchestration realities:
  • Coordinate with SMS/email: if SMS already went out, don’t stack an audible push 2 minutes later.
  • Android channel behavior can override your intent. If your app has multiple channels (Promos vs Orders), pick the channel deliberately per use case.

Implementation Checklist

If you want sound to lift retention metrics instead of driving opt-outs, treat this like a small product change: instrumentation first, then messaging.

• Customer.io SDK installed and initialized correctly (per platform)
• Device token registration confirmed on real profiles
• identify called at login/account creation/email capture (not only at purchase)
• Anonymous activity merges into known profiles after identify
• Core commerce events tracked with required properties (cart/order ids, value, items)
• Segments exclude recent purchasers and recently-notified users
• Android notification channels audited (sound on/off matches your intent)
• Real-device QA across silent mode / DND / permissions

Expert Implementation Tips

The teams that win with sound don’t use it more—they use it with better gates and cleaner identity stitching.

• Create an “Audible Push Eligible” attribute: Set a boolean or timestamp in your app/server when a user hits a high-intent state (e.g., checkout_started_at). Your journey checks that flag before sending sound.
• Use different channels for different intents on Android: Put cart recovery in a “Promos” channel (sound optional) and order issues in an “Orders” channel (sound on). Users often silence promos but keep orders audible.
• Don’t rely on sound to fix poor timing: If your cart recovery push arrives 6 hours late because events are delayed, sound just makes the mistake louder.
• Stitch identities early for guest shoppers: In D2C, the biggest missed opportunity is the guest checkout funnel. Identifying on email capture is usually the difference between recovering revenue and sending nothing.

Common Mistakes to Avoid

Most “sound didn’t work” or “push opt-outs spiked” problems come from a few predictable operational failures.

• Turning on sound for all promotional pushes: That’s how you train users to disable notifications entirely.
• Forgetting Android channels override payload: Teams set sound in Customer.io, but the app channel is silent—so nothing plays.
• Late identify calls: If the user adds to cart while anonymous and you only identify after purchase/login, your cart recovery workflow never finds the right device.
• No frequency cap for audible sends: Even “high intent” can happen multiple times per week for browsers. Cap audible pushes per user (and exclude recent audible recipients).
• Testing only on simulators: Simulators won’t replicate real-world settings like silent switch, focus modes, and channel-level overrides.

Summary

Sound is a sharp tool: it can lift cart recovery and urgent order comms when your SDK tracking and identity stitching are solid.

If your events, device registration, or Android channels are messy, sound won’t fix performance—it’ll just increase the downside.

Implement Sound In Push with Propel

If you’re already running push through Customer.io, the fastest path is usually: audit identity stitching, confirm device/token health, then add sound only to the few journeys where it reliably drives incremental revenue (like checkout drop-off and back-in-stock). If you want help pressure-testing your tracking plan and orchestration so it holds up in production, book a strategy call.