Push notification setup (SDK-first) for Customer.io

Overview

If you’re serious about mobile retention, push is only as good as your identity stitching and event tracking. This guide translates the Customer.io push setup into the practical, app-side steps that prevent “sent but not received” headaches and make cart recovery + repeat purchase flows actually fire when they should. If you want a second set of eyes on your tracking plan before you ship, you can book a strategy call and we’ll pressure-test the data flow.

In most D2C apps, the biggest unlock is getting device registration tied to the same person profile you use for email/SMS—so “Added to Cart” from an anonymous session can still convert after login.

How It Works

Customer.io push messaging depends on two things happening reliably on the app side: (1) the device gets registered for push and (2) Customer.io can confidently attach that device to the right person profile. When either breaks, you’ll see classic symptoms like duplicate sends, missing devices, or pushes going to the wrong user after a shared-device login.

• Permission + token/registration: Your app requests push permission (iOS/Android/Web). Once granted, the OS provides a push token (APNs on iOS, FCM on Android; web uses a browser subscription). Your SDK integration needs to pass that token/subscription to Customer.io so the device appears on the person profile.
• Identify (identity stitching): When a user logs in (or you otherwise know who they are), your app must call identify with a stable customer_id (or your canonical user ID). This is the moment when Customer.io can stitch the device to the known person—critical for cart recovery and post-purchase sequences.
• Track events that drive retention: Push isn’t “set and forget.” Your app needs to send behavioral events like Product Viewed, Added to Cart, Checkout Started, and Order Completed. These events become triggers/conditions in Customer.io campaigns.
• Device lifecycle management: When users log out, switch accounts, or reinstall, you need clean handling so devices don’t remain attached to the wrong profile. In practice, this tends to break on shared iPads, “guest checkout then login,” and subscription apps where people churn/rejoin with a new email.

Step-by-Step Setup

Push setup goes fastest when you treat it like a tracking project, not a channel toggle. The goal is: every push-capable device is registered, attached to the correct person, and updated when identity changes.

1. Pick your identity strategy before you code.
   Use one stable identifier as customer_id (internal user ID is ideal). Decide how you’ll handle guest users and when you’ll merge anonymous activity after login.
2. Install the appropriate Customer.io SDK in your app.
   Implement the Customer.io Mobile SDK (iOS/Android/React Native/Flutter/etc.) and confirm the environment keys match your workspace. Don’t move on until you can see SDK calls hitting Customer.io in a dev environment.
3. Configure your push provider credentials.
   Set up APNs (iOS) and FCM (Android). For web push, configure browser push keys. This is where most “token registered but nothing delivers” issues originate, so validate with a real device early.
4. Request push permission at the right moment.
   Ask after intent, not on first app open. For D2C, a clean moment is after a user favorites an item, adds to cart, or opts into restock alerts—permission rates are materially higher.
5. Register the device token/subscription with Customer.io.
   When the OS returns the token, pass it to the Customer.io SDK so the device is stored on the profile. Confirm in Customer.io that the person shows a device entry.
6. Call identify immediately after login (and after account creation).
   This is non-negotiable. If you delay identify until later in the session, you’ll lose the window where cart events happen anonymously and never stitch to the known user.
7. Implement core retention events.
   At minimum, track: Product Viewed, Added to Cart, Checkout Started, Order Completed. Include product/variant IDs, price, quantity, and cart value so you can segment and personalize without relying on brittle Liquid hacks.
8. Handle logout/account switching.
   On logout, reset the Customer.io identity in the SDK (per platform guidance) and ensure a new login re-identifies cleanly. This prevents the “push goes to the previous account on the same phone” problem.
9. Validate end-to-end with a real D2C flow.
   Run: install app → browse → add to cart as guest → login → abandon → receive push → complete purchase. Verify the same person profile contains the device and the event trail.

When Should You Use This Feature

Push is most valuable when timing matters and you want to pull the customer back into the app with minimal friction. It’s a retention lever, not a broadcast crutch—if your event tracking is thin, you’ll just annoy people faster.

• Cart abandonment (app-first brands): Trigger a push 30–90 minutes after Checkout Started with no Order Completed, then follow with email/SMS only if they don’t return. This works best when device identity is stitched after login.
• Browse abandonment / product discovery: If someone views the same product twice in 48 hours and doesn’t add to cart, send a push with social proof or a short “still thinking about it?” message—no discount required.
• Repeat purchase replenishment: For consumables, trigger based on last order date + typical replenishment window, but only if the device is active and they’ve opened the app recently.
• Reactivation: If a customer hasn’t opened the app in 21–45 days but has high LTV, push can be the cheapest win—assuming you’re not targeting devices that are stale or unregistered.

Real scenario: A skincare brand sees lots of “add to cart” in-app, but checkout completion happens later on desktop. If the app never calls identify until after purchase, Customer.io can’t connect the cart event to the known customer—so cart recovery push never triggers. Fixing identify timing usually lifts recovery volume immediately without changing any messaging.

Operational Considerations

Once the SDK is live, the work shifts to making the data dependable enough to orchestrate across channels. The retention team needs predictable event names, consistent IDs, and clear rules for who is eligible for push.

• Segmentation depends on device presence: Build segments that explicitly require an active push device. Otherwise you’ll “target” people who can’t receive push and skew your campaign read on performance.
• Event taxonomy must be stable: Renaming Added to Cart to add_to_cart mid-quarter will silently break campaigns. Lock a naming convention and version changes intentionally.
• Identity stitching rules: Decide how you treat anonymous sessions. If users browse as guests, you’ll want anonymous activity merged on login so the cart/browse history powers push personalization.
• Cross-channel orchestration: Push should usually go first for app users, then email/SMS as fallback. Set holdouts and suppression rules so you don’t send push + SMS within 2 minutes and burn trust.
• Data latency and retries: Mobile networks are messy. Expect delayed event delivery and implement retries where your SDK/platform supports it. Your campaign delays should assume some events arrive late.

Implementation Checklist

Before you call push “done,” you want proof that devices, identities, and events line up in Customer.io the way your campaigns assume they do.

• Customer.io SDK installed and sending data in dev + production
• APNs (iOS) and/or FCM (Android) configured and validated on real devices
• Push permission prompt implemented after an intent moment (not on first launch)
• Device token/subscription successfully registered to Customer.io
• identify(customer_id) called immediately on login and account creation
• Logout/account switching resets identity to prevent mis-attribution
• Core retention events tracked with rich properties (product_id, variant_id, cart_value)
• Segment exists for “has active push device” and used in push campaigns
• End-to-end test flow completed: browse → cart → login → abandon → push → purchase

Expert Implementation Tips

Most push programs plateau because the plumbing is “mostly working” but not reliable enough for tight orchestration. These are the fixes that usually move push from noisy to profitable.

• Identify earlier than you think: If you support magic links/OTP, identify as soon as the session is authenticated—don’t wait for a profile screen completion.
• Send cart state as properties, not just an event: For cart recovery, include cart_items (IDs/qty) and cart_value. It makes segmentation (e.g., “cart value > $75”) and personalization much easier.
• Use “device present” as a gating condition: If someone doesn’t have a device registered, route them to email/SMS immediately instead of delaying and hoping.
• Design for multi-device reality: High-intent shoppers often have both phone + tablet. Make sure your messaging logic doesn’t double-send across devices unless that’s intentional.
• Instrument opens/deep links: If your push drives to PDP/cart, deep link parameters should be consistent so you can attribute “push → session → purchase” cleanly.

Common Mistakes to Avoid

These are the issues that create false negatives (“push doesn’t work”) when the actual problem is tracking, identity, or eligibility logic.

• Relying on email as the identifier: Emails change. Use a stable internal ID for customer_id, store email as an attribute.
• Not resetting identity on logout: This is how you end up pushing order updates to the wrong person on shared devices.
• Triggering campaigns off events that fire too early: If Checkout Started fires on “view checkout page” instead of “entered shipping/payment,” your abandonment flows will spam.
• Ignoring device eligibility: Building a cart recovery journey without checking “has push device” leads to misleading conversion math and wasted orchestration complexity.
• Shipping without an end-to-end test script: Token registration can look fine while delivery is broken due to certificates/keys. Always validate with a real device outside your dev network.

Summary

If you want push to drive retention, treat setup as identity + event instrumentation first and channel configuration second. Once devices are reliably stitched to the right person and your commerce events are clean, Customer.io campaigns become straightforward to orchestrate for cart recovery, replenishment, and winback.

Implement Push Setup with Propel

If you’re already running Customer.io, the fastest path is usually a quick audit of your SDK calls (identify timing, device registration, and the 4–6 events your retention program actually needs). If you want us to map the tracking plan to your cart/repeat/reactivation journeys and sanity-check it before you ship, book a strategy call—we’ll focus on making the data reliable enough that your push flows don’t break in production.