Set up push notifications (SDK) in Customer.io

Overview

If you’re serious about retention, push is the channel that wins the “right now” moments—cart recovery, back-in-stock, replenishment, and winback—without relying on inbox placement. This guide covers the practical SDK-side setup so Customer.io can reliably target the right device, with the right identity, at the right time; if you want an operator to sanity-check your tracking plan before you ship, book a strategy call.

In most retention programs, push performance doesn’t break because of copy—it breaks because identity stitching is sloppy, tokens aren’t updated, or events fire inconsistently between app and web. The goal here is clean device registration + clean user identity + clean events.

How It Works

Customer.io push depends on a tight loop between your app and Customer.io: the SDK registers the device, your app supplies (or later attaches) the customer identity, and your app sends behavioral events that power segments and triggers.

• Device registration: the SDK collects the APNs (iOS) or FCM (Android) token and associates it to a device record. Tokens change—treat updates as normal, not edge cases.
• Identity stitching: you’ll often have an anonymous app user (browsing) who later logs in or checks out. The critical moment is calling identify so the existing device token is attached to the known Customer.io person profile (your customer_id or equivalent).
• Event tracking: your app sends events like product_viewed, added_to_cart, checkout_started, order_completed. These drive push triggers, suppression rules, and personalization.
• Segmentation + orchestration: inside Customer.io, you’ll build segments based on attributes/events and then trigger push from campaigns/journeys. Push only performs when your app data is consistent enough to segment confidently.

D2C scenario: a shopper adds a cleanser to cart in your app, gets distracted, and closes the app. If you’ve captured added_to_cart with item data and the device is correctly tied to their profile after login (or after email capture), you can send a push 45 minutes later with the exact product name—and suppress it if order_completed fires.

Step-by-Step Setup

Do the setup in the order below. In practice, teams waste days debugging “push not sending” when the real issue is that the device token exists but isn’t attached to the right person because identify happens too late (or never).

1. Create and enable push credentials for your app:
   • iOS: configure APNs (production + sandbox as needed). Make sure your bundle ID and entitlements match what you ship.
   • Android: configure Firebase Cloud Messaging (FCM) and ensure the server key / config matches the app’s Firebase project.
2. Install the Customer.io Mobile SDK:
   • Add the SDK to your iOS/Android app (or React Native/Flutter/Expo wrapper if applicable).
   • Initialize the SDK at app start with your Customer.io site/workspace configuration.
3. Request push permission at the right moment:
   • Don’t prompt on first launch “just because.” Tie the permission ask to value: order updates, restock alerts, shipping notifications, early access drops.
   • Track the permission outcome (granted/denied) so you can segment and avoid wasting impressions.
4. Ensure device token capture and updates are wired:
   • iOS: handle APNs token callbacks and pass the token to the SDK as required.
   • Android: handle FCM token refresh and pass updated tokens through the SDK path.
   • Validate that token refreshes don’t create duplicate device records (a common symptom of mis-ordered init/identify calls).
5. Implement identity stitching with identify:
   • Call identify immediately after a user logs in, creates an account, or you otherwise have a stable customer identifier.
   • Send core attributes alongside identify (email, phone if relevant, timezone, marketing opt-in states) so segments don’t rely on fragile event-only logic.
   • If your app supports logout, reset/clear identity appropriately so the next user on the device doesn’t inherit the prior user’s push targeting.
6. Track the retention-critical events (with useful properties):
   • product_viewed: product_id, name, category, price
   • added_to_cart: cart_id, items[], value, currency
   • checkout_started: cart_id, value
   • order_completed: order_id, value, items[], purchase_count (if you maintain it)
   • push_permission_status: status (granted/denied/provisional)
7. Validate end-to-end in Customer.io:
   • Confirm the person profile shows a device attached.
   • Confirm events appear in the activity feed with the expected properties.
   • Send a test push to a known internal user segment before you build real orchestration.

When Should You Use This Feature

Push is worth the SDK effort when you have time-sensitive retention moments and a product that customers naturally come back to. It’s especially strong when email is too slow, SMS is too expensive, or you need a “tap back into the app” behavior.

• Cart recovery in-app: trigger after added_to_cart with no order_completed within 30–120 minutes, and suppress if the user returns to the app.
• Replenishment / repeat purchase: for consumables, predict depletion windows and send a push that deep-links to “Buy again” with the last purchased SKU.
• Back-in-stock or price drop: if you track product_viewed or wishlist_added, push the moment inventory flips (best paired with an object/catalog feed on the backend, but the app events are the seed).
• Reactivation: target users with push permission granted who have not opened the app in X days but have purchased before.

Operational Considerations

Once push is “working,” the operational work is making sure the data stays trustworthy as the app evolves. Most retention teams get burned by silent tracking regressions after app releases, or by segments that unintentionally include/exclude users because identity is inconsistent.

• Segmentation hygiene:
  • Build separate segments for push-enabled vs push-denied vs unknown so you don’t assume reach you don’t have.
  • Segment by platform (iOS/Android) when debugging delivery or token issues—failures often skew by OS.
• Data flow realities:
  • Decide which events are source-of-truth: app, web, or backend. For retention triggers, backend purchase confirmation usually beats client-side “thank you page” events.
  • Plan for offline behavior: queue events safely if the app is offline, but avoid replaying stale cart events days later without timestamps.
• Orchestration constraints:
  • Set suppression rules: if order_completed fires, immediately cancel pending cart pushes.
  • Frequency caps matter more on push than email—too many pushes drives opt-outs fast, and your reachable audience shrinks.
• Identity stitching edge cases:
  • If users can check out as guest, decide when you create a Customer.io profile and how you merge later when they create an account.
  • If your app supports multiple accounts on one device, enforce logout/reset flows so device tokens don’t stay attached to the wrong person.

Implementation Checklist

Before you build any serious push journeys, get the fundamentals locked. This checklist is what we run through to avoid “it worked on my phone” setups that fall apart at scale.

• Push credentials configured correctly (APNs/FCM) for the environments you ship
• Customer.io SDK initialized on app start (not lazily after screens load)
• Permission prompt tied to a value moment; permission result tracked
• Device token capture and token refresh handling confirmed
• identify called immediately on login/account creation; attributes sent
• Logout/reset flow clears identity to prevent cross-account targeting
• Core retention events implemented with stable naming + required properties
• Test user profile in Customer.io shows: events arriving + device attached
• At least one internal-only segment created for QA pushes

Expert Implementation Tips

The difference between “push exists” and “push drives revenue” usually comes down to how you model identity and events. These are the patterns that keep programs stable even as apps and catalogs change.

• Fire events with timestamps you trust: if your SDK supports it, include event time so delayed sends don’t trigger off stale behavior.
• Standardize commerce properties: keep product_id, variant_id, price, currency, and quantity consistent across app and backend so segments don’t need duct tape.
• Track “app_opened” explicitly: relying only on session analytics can make reactivation logic fuzzy. A clean app_opened event gives you reliable inactivity windows.
• Deep link everything: cart recovery push should open the cart with the items preloaded; replenishment push should open a “Buy again” PDP/cart state, not your home screen.
• Hold out a control group: even a 5–10% holdout on cart push gives you real incrementality instead of vanity lift.

Common Mistakes to Avoid

Most push issues aren’t mysterious—they’re repeatable failure modes. Avoid these and your program stays predictable through app releases.

• Calling identify too late: if you only identify after checkout, your cart and browse pushes won’t reliably target known customers.
• Not handling token refresh: tokens rotate; if you don’t update them, delivery quietly degrades over time.
• Event name drift across platforms: iOS sends AddedToCart, Android sends added_to_cart, web sends add_to_cart—now your segments miss half your audience.
• No suppression on purchase: nothing burns trust faster than a cart reminder after someone already bought.
• Over-notifying new installers: blasting pushes before a user has purchase intent drives opt-outs and shrinks your reachable pool.
• Debugging in prod without an internal QA segment: always keep an employee/tester segment to validate tokens, payloads, and deep links.

Summary

If you want push to drive retention revenue, treat the SDK as the foundation: correct device registration, immediate identity stitching, and consistent commerce events. Once those are solid, Customer.io segmentation and orchestration becomes straightforward—and your cart recovery and repeat purchase flows stop behaving inconsistently.

Implement Push with Propel

If you’re already running retention in Customer.io, the fastest path is usually validating your identity model (anonymous → known), event taxonomy, and token hygiene before you scale journeys. If you want a second set of operator eyes on your SDK plan and the first push flows (cart, replenishment, winback), book a strategy call and we’ll map the tracking and orchestration to your actual purchase cycles.