Set up push notifications (SDK-first) in Customer.io

Overview

If you want push to drive revenue (not just “engagement”), your setup has to start with clean identity and reliable app-side events flowing into Customer.io. If you’re rebuilding tracking, stitching anonymous-to-known users, or debugging why cart push doesn’t match backend orders, book a strategy call and we’ll pressure-test the data flow before you scale sends.

In most retention programs, push works best when it’s tightly tied to real customer intent: viewed product, added to cart, started checkout, purchased, lapsed. That means your SDK instrumentation (mobile and/or web push) is the “source of truth” for who should receive what—and when.

How It Works

Push in Customer.io is only as good as the device + identity graph you feed it. Practically, you’re doing three things: registering devices for push, linking those devices to the right person, and sending events that your segments and campaigns can reliably trigger off.

• Device registration: Your app (or website for web push) collects a push token (APNs for iOS, FCM for Android, browser token for web push) and passes it to Customer.io via the SDK. That token is what Customer.io targets when it sends a push.
• Identity stitching (the part that makes or breaks retention): Early in the session you’ll often have an anonymous user (pre-login). Once they log in or enter email/phone at checkout, you need an identify call to attach the device token and prior activity to the known profile. If you skip or delay this, you’ll see classic issues: duplicate profiles, abandoned-cart pushes going to the wrong account, or “purchased” users still getting recovery pushes.
• Event tracking for orchestration: You send events like product_viewed, add_to_cart, checkout_started, purchase from the SDK. Customer.io uses those events to trigger campaigns, build segments, and apply frequency/exit rules.

Real D2C scenario: A shopper browses in your app, adds a product to cart, then gets distracted. If your SDK fires add_to_cart with SKU/variant and cart value, and you identify them when they log in (or when they enter email in checkout), Customer.io can send a push 30–60 minutes later that deep-links back to the exact cart state. Without that stitching, you’ll either miss them entirely or hit them with a generic push that doesn’t convert.

Step-by-Step Setup

The fastest path is to treat this like a tracking project, not a “turn on push” project. Get the SDK installed, confirm tokens are flowing, then lock identity and events before you build any serious automation.

1. Decide your push surface area (mobile, web, or both).
   Map where you actually expect push to drive repeat purchase (mobile app is usually highest intent; web push can help for browse/cart recovery if opt-in rates are strong).
2. Install the Customer.io SDK for your platform.
   Use the appropriate Mobile SDK (iOS/Android/React Native/Flutter/Expo) or web implementation. Keep your initial install minimal—focus on initialization + push permissions + token capture first.
3. Enable push permissions and capture the push token.
   Implement platform-native permission prompts (iOS) and ensure FCM/APNs setup is correct. Confirm the SDK is receiving a valid token and sending it to Customer.io.
4. Implement identify immediately when a user becomes known.
   Call identify on login, account creation, or when the user submits email/phone in checkout. This is where you attach the device to the correct person.
   Operator note: In practice, this tends to break when teams only identify on “account created” but not on “login,” which leaves returning customers orphaned on old anonymous profiles.
5. Track your core retention events from the SDK.
   At minimum for D2C retention:
   • product_viewed (include product_id, variant_id, category, price)
   • add_to_cart (include cart_id, items[], value)
   • checkout_started (include cart_id, value)
   • purchase (include order_id, value, items[], discount, currency)
6. Validate in Customer.io: devices, people, and event timelines.
   Pick 2–3 test users and confirm:
   • Device tokens appear on the correct person profile
   • Anonymous activity merges into the known profile after identify
   • Events arrive with the properties you need for segmentation/personalization
7. Build one “money” automation first (then expand).
   Start with cart abandonment push (with a purchase exit condition) before you add browse, winback, or replenishment.

When Should You Use This Feature

Push is worth the SDK effort when you have frequent sessions, time-sensitive intent, or a product where reminders beat inbox competition. For D2C, it’s most effective when you can target with precision and suppress aggressively when the customer converts.

• Cart recovery: Trigger on add_to_cart or checkout_started, delay 30–120 minutes, deep-link to cart, and exit on purchase.
• Repeat purchase / replenishment: Trigger off purchase + product metadata (e.g., “30 days since last collagen purchase”), then push a reorder flow or subscription upsell.
• Reactivation: Target users with no app_open (or no meaningful commerce event) in X days, but only if they’re still opted-in and you have a compelling offer or new drop.
• Drop alerts / back-in-stock: If you track product_viewed and have inventory signals, push when a viewed SKU returns—this is high-intent and typically low-volume.

Operational Considerations

Once push is live, the operational work is less about message copy and more about keeping segments accurate, events trustworthy, and orchestration clean across channels (email/SMS/push).

• Segmentation depends on event hygiene: If add_to_cart fires multiple times per session without a stable cart_id, you’ll over-trigger and inflate “abandon” audiences. Deduplicate at the app layer or segment on the latest cart state.
• Identity stitching is ongoing: Make sure identify happens on every login—not just signup. Also plan for logout behavior; if a shared device logs into another account, you need to avoid sending the prior user’s pushes.
• Data flow reality: SDK vs backend: Purchases often finalize server-side. If your SDK purchase event is delayed or missing (app killed, network drop), you’ll keep sending recovery pushes to buyers. In most retention programs, we’ve seen better suppression when the backend also sends a canonical purchase event (even if the SDK tracks it too).
• Orchestration across channels: Decide your priority rules: e.g., cart recovery = push first, then email; or push only for app users, email for everyone. Use exit conditions and frequency limits so a customer doesn’t get push + SMS + email for the same cart.
• Deep links and measurement: Push without deep links turns into “open the app and hunt,” which kills conversion. Standardize deep link structure and pass campaign identifiers for attribution.

Implementation Checklist

Before you scale beyond a single recovery flow, lock these basics. It’s the difference between “push is noisy” and “push prints incremental revenue.”

• SDK installed and initialized on all supported app versions
• Push permission prompt implemented with a deliberate timing strategy (not first app open)
• Device token successfully registered in Customer.io and visible on person profiles
• identify called on login and checkout identity capture
• Anonymous-to-known activity merges correctly (verified with test users)
• Core commerce events implemented with consistent naming and required properties
• Purchase event reliably arrives (SDK and/or backend canonical event)
• Deep links tested for cart, PDP, collection, and order status destinations
• At least one campaign has exit conditions (purchase) and frequency limits

Expert Implementation Tips

These are the things that usually separate a clean push program from one that slowly degrades as the app evolves.

• Use stable identifiers in events: Always include product_id/variant_id and a stable cart_id. Relying on product names breaks personalization and reporting the first time merchandising changes naming.
• Send the “state,” not just the action: For cart, include items[] and value on every cart event so you can segment by cart size and avoid pushing $12 carts like they’re $180 carts.
• Build suppression segments early: Opted-out, recent purchasers, refunded/canceled orders, customer support cases—these should suppress push automatically.
• Plan for token churn: Tokens can rotate. Make sure your app updates the token with Customer.io when it changes, otherwise deliverability quietly decays.
• QA with real devices, not just logs: Simulator success doesn’t guarantee production delivery. Test on fresh installs, upgraded installs, logged-out states, and users who reinstall the app.

Common Mistakes to Avoid

Most “push doesn’t work” stories are really tracking and orchestration failures. Fix these and performance usually follows.

• Identifying too late: Waiting until post-purchase to identify means you can’t recover carts or personalize browse-based push.
• Duplicate profiles from inconsistent IDs: Switching between email, internal user_id, and phone without a clear primary identifier creates split histories and messy targeting.
• No purchase-based exits: If your cart flow doesn’t exit on purchase, you will annoy customers and inflate unsubscribes/opt-outs.
• Over-triggering from noisy events: Tracking every quantity change as add_to_cart without dedupe leads to multiple pushes per session.
• Generic pushes with no deep link: “Come back to complete your order” without a cart deep link is basically a brand ad—not a recovery message.

Summary

Push setup in Customer.io is an SDK and identity problem first, and a messaging problem second. Nail device registration, identify calls, and clean commerce events, then build cart recovery and repeat purchase flows with strict exits.

If your events and stitching are solid, push becomes a reliable lever for incremental revenue—not just another channel to manage.

Implement Push with Propel

If you’re rolling out push (or fixing a messy setup), it helps to treat it like a retention system: identity stitching, event contracts, suppression logic, and channel orchestration all working together inside Customer.io. If you want a second set of eyes on your SDK plan and the first revenue-driving flows, book a strategy call and we’ll map the tracking and campaigns to your actual purchase cycles.

In most retention programs, getting this right upfront saves weeks of debugging “why did they get that push?” later—especially once you layer in SMS/email and real frequency constraints.