Set up push notifications (SDK) in Customer.io

Overview

If you want push to actually drive repeat purchase and recovery (not just “send notifications”), the hard part is getting clean device + identity data into Customer.io. When push underperforms, it’s usually because devices aren’t registered reliably, users aren’t identified at the right moments, or events don’t line up across anonymous-to-known sessions.

This guide walks through the app-side setup that makes push work in practice. If you’re rebuilding your tracking plan or your identity stitching has gotten messy, it’s often faster to book a strategy call and pressure-test the implementation before you scale sends.

How It Works

Push in Customer.io is only as good as the SDK signals you feed it. The SDK’s job is to (1) register the device token, (2) associate that device with the right person profile, and (3) stream the behavioral events you’ll use to trigger and personalize messages.

• Device registration: Your app collects the APNs/FCM token (or web push token) and passes it to the Customer.io SDK so the platform knows where to deliver messages.
• Identity stitching: Before login, activity is effectively anonymous. The moment the user authenticates (or you have a stable customer ID), you call identify so Customer.io can attach the device + future events to the correct person. In most retention programs, this is the difference between “push works” and “we’re spamming the wrong people.”
• Event tracking for triggers: You track key retention events (e.g., product_viewed, added_to_cart, checkout_started, order_completed) from the app. Those events become entry conditions for campaigns, and they also drive segmentation (like “high-intent, no purchase in 2 hours”).
• Preference + permission state: Push permission is not the same as “subscribed.” You’ll want attributes like push_permission_status and push_opt_in_timestamp so you can suppress intelligently and avoid burning the channel.

Step-by-Step Setup

Don’t start in the Journey builder. Start by making sure the SDK can consistently (a) register devices and (b) tie them to the right profile. Once that foundation is stable, everything downstream (cart recovery, replenishment, winback) becomes straightforward.

1. Pick the right SDK for your app: Use Customer.io’s Mobile SDK for iOS/Android (or your framework wrapper like React Native/Flutter/Expo). For web push, use the web integration approach that supports push tokens and permission state.
2. Install and initialize the SDK: Add the SDK to your app, initialize it at app start, and confirm it can reach Customer.io in your environments (dev/staging/prod). Keep your site/app ID and region settings consistent across builds.
3. Implement push permission prompting (timed to intent): Trigger the OS permission prompt after a meaningful action (e.g., “Track my order” or “Get restock alerts”), not on first open. Store the result in an attribute like push_permission_status so you can segment and suppress.
4. Register the device token:
   • iOS: capture the APNs token and pass it into the SDK’s device registration method.
   • Android: capture the FCM token and pass it into the SDK’s registration method.
   • Make sure you handle token refresh events—this is where delivery silently breaks if you ignore it.
5. Call identify immediately after login (and only then): Use a stable customer identifier (your internal customer ID). Send core attributes you’ll use for retention logic (email, phone if applicable, first_order_date, last_order_date, loyalty_tier, etc.).
6. Track the retention events that actually drive revenue: At minimum for D2C:
   • product_viewed (include product_id, category, price)
   • added_to_cart (include cart_id, items, value)
   • checkout_started (include cart value, shipping option if known)
   • order_completed (include order_id, revenue, items, discount_code)
7. Verify device-to-person association in Customer.io: Check a test user profile and confirm:
   • the device shows up under devices
   • events appear in the activity log
   • the person ID matches your internal ID (no duplicates)
8. Send a transactional push first (smoke test): Before you build a full cart recovery flow, send a simple transactional push (e.g., “Your order shipped”) to validate delivery, rendering, and deep links.

When Should You Use This Feature

Push is best when timing matters and the user has already shown intent. In practice, it’s strongest as a “nudge” channel layered on top of email/SMS—not a replacement—because it’s fast, cheap, and easy to overuse.

• Cart recovery (high intent): If a shopper adds to cart in-app and bounces, push can hit within minutes while intent is still hot—especially if email is delayed or goes to promotions.
• Browse abandonment: When someone views the same product twice in 24 hours but doesn’t add to cart, a push with social proof or a benefit callout can move them without discounting.
• Replenishment / repeat purchase: If you sell consumables (skincare, supplements), push works well when triggered off order_completed + expected depletion windows (e.g., day 21/28/35) and suppressed if they already reordered.
• Back-in-stock or price-drop alerts: These are permission-worthy prompts that users actually want, and they create a clean reason to opt in.

Real D2C scenario: A skincare brand sees lots of “add to cart” in the app, but purchases happen later on desktop. Without identity stitching, those users look like they abandoned. With proper identify on login and consistent customer IDs across platforms, you can suppress the push if the order completes elsewhere and avoid training customers to ignore you.

Operational Considerations

Once the SDK is live, the operational work is keeping data clean enough that your orchestration doesn’t drift. Push failures usually show up as segmentation bugs (wrong audience) or data flow gaps (missing events/devices), not as “copy problems.”

• Segmentation depends on permission + device presence: Always build segments that require (a) push permission = granted and (b) an active device. Otherwise you’ll think a campaign is “sending” when it’s effectively dead on arrival.
• Identity stitching is your suppression layer: If you don’t unify app + web identities, you’ll over-message. Make sure your customer ID is consistent across all sources feeding Customer.io (SDK, server events, ecommerce platform).
• Event timing and dedupe: Mobile networks are messy. If added_to_cart can fire multiple times, dedupe with a cart_id + timestamp rules in your campaign logic. In practice, this tends to break when teams rely on “count of events” without stable identifiers.
• Deep links need to match the message goal: Cart recovery push should open the cart (with the same cart_id), not the homepage. If you can’t restore cart state, you’ll pay for the click and lose the conversion.
• Cross-channel orchestration: Decide upfront how push interacts with email/SMS. Example: push at +30 minutes, email at +4 hours, SMS only for VIPs at +24 hours if still unconverted.

Implementation Checklist

If you want push to be a reliable retention lever, treat this like instrumentation—not messaging. Run through this checklist before you scale volume or build complex Journeys.

• SDK installed and initialized in all environments (dev/staging/prod)
• Push permission prompt implemented after an intent moment (not on first open)
• Permission status stored on the profile (granted/denied/not_determined)
• Device token registration implemented + token refresh handled
• identify called immediately after authentication with a stable customer ID
• Key events tracked with stable identifiers (cart_id, order_id, product_id)
• Test profile shows device attached + events flowing in Customer.io activity log
• Deep links tested from push to the correct in-app destination
• Basic suppression rules defined (purchased, already reordered, opted out, no device)

Expert Implementation Tips

The difference between “we have push” and “push drives incremental revenue” is usually a handful of small operator decisions around identity, timing, and suppression.

• Identify earlier than you think (but not before you’re sure): If you have a logged-in state, call identify on app open. If you only have email capture, consider a temporary user ID until login—then merge carefully so you don’t fork profiles.
• Track a single “source of truth” purchase event: If you’re sending order_completed from both the app and server, you’ll double-trigger. Pick one source (server is usually safer) and keep the SDK focused on intent events.
• Use value-based branching: Pass cart value and item count in added_to_cart. Then branch: high AOV gets faster follow-up; low AOV gets content-led nudges before discounts.
• Build a “push-eligible” segment and reuse it everywhere: Centralize logic like permission granted + device exists + not suppressed. This prevents every campaign from reinventing (and breaking) eligibility rules.

Common Mistakes to Avoid

Most push programs fail quietly. These are the mistakes that create phantom sends, duplicate profiles, and inflated abandonment numbers.

• Calling identify with an unstable identifier: If you identify by email that can change, or by a device ID that resets, you’ll fragment profiles and lose suppression accuracy.
• Ignoring token refresh: Everything works in QA, then delivery decays over time because tokens rotated and you never updated them.
• Tracking events without IDs: “added_to_cart” without a cart_id makes dedupe and suppression brittle, especially with multi-session carts.
• Prompting for push permission on first launch: You’ll get low opt-in rates and you can’t win it back easily. Tie the ask to a benefit (shipping updates, restock alerts).
• No cross-channel suppression: If the customer buys on desktop and your app push still fires, you train them that your messages are irrelevant.

Summary

Push setup in Customer.io is an SDK and identity problem first, and a messaging problem second. Get device registration, identify, and event quality right, and you can run reliable cart recovery, replenishment, and winback without spamming.

If your current data makes you hesitate to scale, fix the stitching before you add more journeys.

Implement Push with Propel

If you’re implementing push on top of Customer.io, the fastest path is usually: validate SDK identity stitching, lock a minimal event spec, then build 2–3 revenue-critical flows (cart recovery, replenishment, winback) with tight suppression. That sequencing prevents the common “we launched push and performance dropped” outcome.

If you want a second set of eyes on device tracking, token refresh handling, and cross-channel suppression logic, book a strategy call and we’ll map your app instrumentation to the retention outcomes you care about.