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

Overview

If push is going to drive revenue (not just “engagement”), the foundation is clean device tracking and identity stitching in Customer.io. Most retention programs we’ve seen don’t fail because the copy is bad—they fail because tokens aren’t captured reliably, users aren’t identified at the right moment, or anonymous browsing never gets merged to the eventual purchaser.

If you want a second set of eyes on your event plan and identity model before you ship, you can book a strategy call and we’ll pressure-test the setup against cart recovery, repeat purchase, and reactivation use cases.

How It Works

Push in Customer.io is only as good as the data you send from your app or site. In practice, you’re wiring up three things: (1) permission + token capture, (2) identity (who is this device tied to), and (3) behavioral events that tell Customer.io when to send.

• Device registration: your app (iOS/Android) or browser (web push) collects a push token/subscription and sends it to Customer.io so the person profile has a reachable device.
• Identify at the right time: when a user logs in, creates an account, or you otherwise know who they are, you call identify so Customer.io can attach the device token to the known customer record.
• Track events for triggers: you send events like product_viewed, added_to_cart, checkout_started, order_completed. Those events power segments and Journeys that send push with real intent.
• Identity stitching (anonymous → known): if someone browses anonymously, you can still track events. The critical part is merging that anonymous activity into the identified profile once they log in or provide an email/phone—otherwise your “cart abandon” push never fires for the right person.

Real D2C scenario: a shopper adds a bundle to cart on mobile web, then installs the app and logs in to check shipping. If you stitch identity correctly, you can send an app push 30–60 minutes later: “Your bundle is still in your cart—complete checkout for delivery by Friday.” If you don’t, the cart event lives on an anonymous profile and your push audience is empty.

Step-by-Step Setup

The fastest path is to get the SDK installed, confirm tokens are landing on profiles, then layer in identify + events. Don’t start building cart recovery flows until you’ve verified device reachability and profile merges in real traffic.

1. Install the Customer.io SDK for your platform.
   Add the iOS/Android (or your cross-platform wrapper like React Native/Flutter/Expo) SDK to your app and initialize it on app start with your workspace credentials.
2. Enable push capability and request permission.
   Implement the OS-level permission prompt (iOS) and notification permission flow (Android 13+). Time the prompt after a value moment (e.g., “Track your order” or “Restock alerts”), not on first open.
3. Capture and register the push token with Customer.io.
   When APNs/FCM returns a token, pass it to the SDK so Customer.io can associate the device with a profile. Verify in Customer.io that the person shows a device entry.
4. Implement identify on login/account creation.
   Call identify(userId, attributes) as soon as you have a stable customer identifier. Include retention-relevant attributes like email, phone (if applicable), first_order_date, last_order_date, vip_tier, marketing_opt_in.
5. Stitch anonymous activity into the identified profile.
   If your app supports guest browsing, track events anonymously, then merge on identify so pre-login cart and browse behavior isn’t lost. This is where cart recovery and product discovery flows usually break.
6. Track the events you’ll actually operationalize.
   At minimum for D2C retention: product_viewed (with sku/product_id, category, price), added_to_cart (sku, qty), checkout_started, order_completed (order_id, revenue, items), and optionally push_opt_in/push_opt_out.
7. Validate in Customer.io before building Journeys.
   Use a test device, generate each event, and confirm: the person profile updates, the device token appears, events show in activity, and anonymous-to-known merging behaves as expected.
8. Create your first push message and send to a controlled segment.
   Start with an internal segment (employees/testers) to validate delivery, deep links, and unsubscribe/opt-out behavior.

When Should You Use This Feature

Push is most effective when you have a clear behavioral trigger and a tight time window. If you’re sending push like email (“weekly promos”), it’ll work for a month and then your opt-in rate and engagement decay.

• Cart recovery: trigger off added_to_cart with no order_completed within X minutes/hours, and only if the user is push-opted-in and has a reachable device.
• Browse-to-buy nudges: product_viewed 2–3 times without added_to_cart, especially for higher-AOV categories where consideration is real.
• Post-purchase repeat purchase: after order_completed, send replenishment or “how to use” reminders based on item-level data (e.g., skincare routine steps, supplement cadence).
• Reactivation: “no session” or “no purchase” windows (e.g., 45–60 days) paired with a last-category affinity attribute captured from events.
• Back-in-stock / price drop: only if you track subscribed_to_restock or wishlist events and can target by SKU.

Operational Considerations

Once the SDK is live, the work shifts from “can we send push?” to “can we trust the audience and timing?” This is where segmentation, data flow, and orchestration realities decide whether push prints money or just burns opt-ins.

• Segmentation depends on identity hygiene: if you identify too late (after checkout), you’ll miss the highest-intent windows. Identify on login and also when a user submits email for order tracking or account creation.
• Token churn is real: devices rotate tokens, users reinstall, permissions change. Build segments that require a recent device update or recent app activity if deliverability drops.
• Event naming and payload consistency: pick a schema and stick to it. “added_to_cart” vs “add_to_cart” fragmentation creates silent segment gaps that look like “push isn’t working.”
• Deep linking and attribution: make sure push opens the right screen (cart, PDP, order status) and you can attribute downstream purchase back to the push touch.
• Cross-channel orchestration: in most programs, push should be the first touch for high-intent moments, with email/SMS as fallback if the user isn’t opted into push or isn’t reachable.
• Frequency and fatigue control: cap promotional push and reserve sends for behavior-triggered moments. A noisy push program kills opt-ins faster than a noisy email program.

Implementation Checklist

Before you call push “done,” you want proof that tokens, identities, and events line up end-to-end. This checklist is what we use to keep teams from building Journeys on top of shaky tracking.

• SDK installed and initialized on app start (all environments: dev/stage/prod)
• Push permission flow implemented and timed after a value moment
• APNs/FCM token captured and sent to Customer.io; device visible on person profile
• identify implemented on login/account creation with stable userId
• Anonymous activity merges into identified profile (validated with a real test)
• Core retention events tracked with consistent schema: view → cart → checkout → purchase
• Opt-in/opt-out state tracked and respected in segments
• Deep links tested from push to the correct in-app destination
• At least one controlled internal segment successfully receives push

Expert Implementation Tips

These are the small operator moves that usually separate “we launched push” from “push drives incremental revenue.”

• Identify earlier than you think: if your app has “track my order” or “save my cart,” that’s an identity capture moment. Tie that to identify so cart and browse events don’t stay anonymous.
• Send item-level cart payloads: include items arrays (sku, name, price, qty). Your best-performing cart pushes usually reference the exact product, not “items in your cart.”
• Use a short grace period before cart recovery: 20–45 minutes tends to outperform “instant” because it avoids interrupting active shoppers and reduces wasted sends.
• Build a reachability fallback: segment logic like “has push-enabled device” → send push, else send email/SMS. This keeps conversion consistent without spamming everyone.
• Instrument a ‘push_opened’ event: track opens/clicks in a way your product analytics can use, then optimize by category, time-to-send, and creative.

Common Mistakes to Avoid

Most push issues show up as “low volume” or “random delivery.” The root cause is usually one of these avoidable mistakes.

• Relying on email as the identifier in the SDK: use a stable internal userId. Emails change; IDs don’t.
• Not merging anonymous activity: you’ll see lots of anonymous carts and very few recoverable push audiences.
• Prompting for push permission on first launch: opt-in rates crater, and you can’t win them back easily.
• Event payloads that aren’t usable: tracking added_to_cart without SKU/price means you can’t personalize, prioritize high-AOV carts, or exclude low-margin items.
• No caps or suppression logic: sending cart recovery to someone who already purchased (because purchase event arrives late) is a fast way to drive complaints and opt-outs.
• Testing only on one device: Android OEM differences, iOS permission states, and token refresh behavior can create “works on my phone” false confidence.

Summary

If you want push to reliably drive cart recovery and repeat purchase, treat the SDK as the product: token capture, early identify, and clean event schema.

Once identity stitching is solid, Customer.io segmentation and Journeys become straightforward—and your send volume matches real buyer intent.

Implement Push with Propel

If you’re already running Customer.io, the highest-leverage help is usually not “building the push message”—it’s validating identity stitching, event payloads, and reachability so your automations don’t leak revenue.

If you want that operational review (and a clean plan for cart recovery + post-purchase push), book a strategy call and we’ll map the SDK events and identify points to the exact segments and triggers you’ll run.