Push notifications setup (Mobile SDK) for Customer.io

Overview

Push is one of the fastest levers for D2C retention—when identity and device tracking are clean. If you’re running Customer.io and want push to reliably power cart recovery, replenishment, and winback, the work is mostly SDK plumbing and data discipline (not copywriting). If you want a second set of eyes on the tracking plan before you ship, you can book a strategy call.

In most retention programs, we’ve seen push “underperform” for one simple reason: the right person exists in Customer.io, but the device token is attached to the wrong profile (or never attached at all). This guide focuses on getting the SDK layer right so campaigns hit real devices and can be orchestrated with email/SMS.

How It Works

Customer.io push depends on your app collecting a valid push token and associating it with the correct person profile. Once that mapping is stable, Customer.io can target segments like “Added to cart, no checkout in 2 hours” and send push to the devices on file.

• SDK captures device + token: Your iOS/Android app registers for push with APNs/FCM, receives a device token, and the Customer.io SDK records it as a device for that user.
• Identity stitching happens via identify: When a user logs in (or you otherwise know who they are), you call identify with your stable customer identifier. That’s the moment the device token becomes useful for retention—because it’s now tied to a real person in Customer.io.
• Events drive targeting: You track events like product_viewed, add_to_cart, checkout_started, order_placed. Journeys/campaigns listen for these events and decide who should get push, when, and with what suppression rules.
• Delivery is channel + eligibility dependent: Even with perfect events, push only sends if the profile has at least one active device token and isn’t suppressed by frequency caps, quiet hours, or unsubscribe/permission status.

Real D2C scenario: A shopper browses on mobile, adds a product to cart, then gets distracted. If your SDK tracks add_to_cart but you never called identify after login (or you identify with an unstable ID), Customer.io can’t confidently target the device. The campaign looks “fine” in the UI, but the audience is effectively empty.

Step-by-Step Setup

Before you touch campaigns, get the mobile data layer stable. The goal is simple: every logged-in customer should have a consistent customer_id in Customer.io and at least one correctly-associated device token.

1. Pick your canonical identity key (do this first).
   Use a stable internal ID (e.g., customer_id)—not email, not phone, not a device ID. In practice, this tends to break when teams identify by email and later the customer changes it, creating duplicates and “lost” devices.
2. Install the Customer.io Mobile SDK for your platform.
   Add the iOS/Android (or React Native/Flutter/Expo) SDK to your app and initialize it at app start. Make sure you’re using the correct site ID/API key for the right workspace/environment (prod vs staging).
3. Implement push permission + token registration.
   Request notification permission at an intentional moment (post-value, not on first launch), then register with APNs (iOS) or FCM (Android). Confirm your app receives a device token.
4. Send the device token to Customer.io via the SDK.
   The SDK needs the token to create/update the device record. Validate that a device appears on the person profile in Customer.io once identified.
5. Call identify immediately after authentication.
   When the user logs in (or account is created), call identify(customer_id, attributes). Include attributes you’ll actually segment on (e.g., email, first_name, timezone, marketing_opt_in, last_order_at).
6. Track retention-critical events with clean properties.
   At minimum for D2C: product_viewed (sku, category), add_to_cart (sku, qty, cart_value), checkout_started, order_placed (order_id, total, items), and optionally subscription_started/subscription_canceled.
7. Validate identity stitching with an anonymous-to-known flow.
   If you allow browsing before login, ensure anonymous activity merges into the known profile after login. This is where cart recovery often fails: the cart event lands on an anonymous profile, while push tokens sit on the known profile.
8. Confirm delivery eligibility in Customer.io.
   Check that the person has an active device, is not suppressed, and that your workspace push channel is configured. Send a test push to a real device—not just a simulator.

When Should You Use This Feature

Push setup is worth the engineering time when you have time-sensitive intents that email can’t reliably catch. The best use cases are the ones where minutes matter or where you need a lightweight “tap back into the app” nudge.

• Cart recovery on mobile: Trigger push 30–120 minutes after add_to_cart if no order_placed. Works best when you include the product name and keep the deep link clean.
• Browse abandonment / product discovery: After 2–24 hours, nudge based on last viewed category or SKU—only if the user has shown intent (multiple views, add-to-wishlist, etc.).
• Replenishment / repeat purchase: If you track order_placed with item-level data, you can estimate replenishment windows and send a push before the customer runs out.
• Reactivation: For customers who opted into push but haven’t opened the app or purchased in X days, push can be the “first touch,” with email/SMS as follow-ups depending on engagement.

Operational Considerations

Once push is wired, the operational work is making sure the data you’re feeding Customer.io supports segmentation and orchestration without creating noise. This is where teams either build a clean retention engine—or accidentally spam their best customers.

• Segmentation depends on event hygiene: Standardize event names and required properties. If add_to_cart sometimes sends sku and sometimes sends product_id, your dynamic push content and segments will be fragile.
• Device coverage is never 100%: Expect a chunk of users to deny permissions or lose tokens. Build fallback paths (email/SMS) and don’t treat push as the only recovery channel.
• Identity duplication kills reach: If the same customer exists as multiple profiles, their devices and events split—so your cart recovery audience shrinks and your frequency controls stop working. Use one canonical ID and be strict about it.
• Orchestration realities: Decide channel priority rules. Example: if push sent for cart recovery, suppress the email for 2 hours unless the customer clicks but still doesn’t purchase. This reduces “double tapping” the same intent.
• Time zones and quiet hours: If you don’t set timezone on the profile, “send at 7pm” becomes “send at 7pm in your workspace timezone,” which is how you end up sending winbacks at 3am.

Implementation Checklist

Use this as a pre-launch gate before you build real campaigns. If you can’t check these off, you’ll spend weeks debugging “why push isn’t working” in production.

• Canonical customer_id defined and used consistently across app, backend, and Customer.io
• Customer.io mobile SDK installed and initialized in the correct environment (staging vs prod)
• Push permission prompt implemented with a deliberate trigger (not immediate on first launch)
• APNs/FCM token successfully captured on device and passed to the Customer.io SDK
• identify called immediately after login/signup with customer_id and core attributes
• Anonymous-to-known merge behavior validated (cart/browse events don’t get stranded)
• Events implemented: product_viewed, add_to_cart, checkout_started, order_placed with required properties
• Test person in Customer.io shows an active device and receives a test push on a physical device
• Basic suppression rules planned (frequency caps, quiet hours, post-purchase cooldown)

Expert Implementation Tips

These are the small choices that make push feel “smart” instead of noisy—and they start at the SDK/event layer.

• Track deep link targets as event properties: Store a deep_link or destination property on intent events (like add_to_cart). Then your push can reliably open the correct cart state or PDP without brittle client logic.
• Send item-level order data: For repeat purchase, “order placed” without line items limits you to generic reminders. With SKUs/categories, you can build replenishment and cross-sell segments that don’t guess.
• Instrument permission state: Track an attribute like push_permission (authorized/denied) so you can segment “push-eligible” vs “needs email fallback” cleanly.
• Handle logout explicitly: If your app supports logout, make sure you’re not leaving devices attached to the wrong identity. This is a common source of “my partner got my push” horror stories on shared devices.
• QA with real customer flows: Test: browse anonymously → add to cart → login → abandon → receive push. That single path catches most stitching and token issues.

Common Mistakes to Avoid

Most push issues aren’t “Customer.io problems”—they’re mismatches between how the app identifies users and how marketing expects to segment them.

• Identifying by email instead of a stable ID: Leads to duplicates, broken stitching, and devices attached to outdated profiles.
• Tracking events before identify with no merge plan: Your highest-intent events (cart/checkout) end up on anonymous profiles that never receive push.
• Inconsistent event schemas: Campaign logic and personalization break when required properties are missing or renamed across app versions.
• Prompting for push permission too early: Denial rates spike, and you permanently shrink your reachable audience. Ask after the user sees value (e.g., after saving a cart or completing onboarding).
• No suppression after purchase: Without an order_placed-based exit/suppression, customers can receive cart recovery pushes after they already bought.

Summary

If you want push to drive real D2C retention, treat it like identity infrastructure: stable identify, clean device tokens, and consistent events. Once that’s in place, cart recovery, replenishment, and winback pushes become predictable—and orchestration with email/SMS becomes straightforward.

Implement Push Setup with Propel

If you’re already on Customer.io, the highest-leverage help is usually upfront: confirming the identity model, mapping the event schema, and validating anonymous-to-known stitching before campaigns go live. If you want to pressure-test your SDK tracking plan against your retention roadmap (cart recovery → repeat purchase → reactivation), you can book a strategy call and we’ll walk through what tends to break in production.