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

Overview

If you want push to actually drive repeat purchase and recovery (not just “send notifications”), the work starts in the SDK: device registration, identity stitching, and clean event tracking. This is where Customer.io push wins or loses—long before you write copy. If you want a second set of eyes on your tracking plan and orchestration, book a strategy call.

In most retention programs, push becomes your highest-intent channel for cart recovery and replenishment—because it hits when the shopper is on-device. But it only performs when Customer.io can reliably map: person ↔ device token ↔ events.

How It Works

Push in Customer.io is basically two systems working together: your app (collecting permissions + tokens + events) and Customer.io (storing devices on the right profile and triggering sends from campaigns/journeys). The SDK is the bridge—if the bridge is shaky, your sends either don’t deliver or they deliver to the wrong person.

• Permission + token capture: Your app requests push permission (iOS) and receives a device token (APNs) or registration token (FCM). That token is what Customer.io ultimately targets.
• Device registration in Customer.io: The SDK registers the token as a device on a Customer.io profile. This is the difference between “we have a user” and “we can actually reach them.”
• Identity stitching (critical): You’ll often capture a token while the shopper is anonymous (app installed, browsing). Once they log in or enter email/phone at checkout, you must identify them so Customer.io attaches that device to the known profile—otherwise cart recovery push won’t fire for the right person.
• Event tracking drives orchestration: Push isn’t sent because time passed; it’s sent because a high-intent event happened (e.g., Added to Cart, Started Checkout, Order Completed) and the user meets eligibility rules (opted in, not recently purchased, not already converted).

Real D2C scenario: A shopper adds a moisturizer to cart in your app, gets distracted, and closes it. If your SDK logged added_to_cart and the device is registered to their profile, you can send a push 30 minutes later with the exact product and a deep link back to the cart. If you missed identity stitching (token sits on an anonymous profile), Customer.io can’t confidently target them—and your “cart recovery push” quietly under-delivers.

Step-by-Step Setup

The fastest way to ship push without breaking attribution is to set up the channel in Customer.io, then work backwards into the SDK: permissions, device registration, identify calls, and events. Treat this like instrumentation, not “marketing setup.”

1. Decide your identity key and stick to it
   • Pick the canonical identifier you’ll use with Customer.io (typically customer_id or a stable internal user id).
   • Make sure the same id is available on every platform you’ll send from (iOS/Android/web) to avoid fragmented profiles.
2. Install the Customer.io Mobile SDK
   • Implement the Customer.io SDK for your stack (iOS/Android/React Native/Flutter, etc.).
   • Initialize it early in the app lifecycle so it can capture device context and handle push callbacks reliably.
3. Implement push permission prompts intentionally
   • Don’t prompt on first app open. Tie the permission request to a value moment (e.g., “Get restock alerts” or “Track your delivery”).
   • Record permission status as a person attribute so you can segment (e.g., push_permission=granted|denied|not_determined).
4. Register device tokens with Customer.io
   • On iOS, capture the APNs device token and pass it to the SDK.
   • On Android, capture the FCM token and pass it to the SDK.
   • Handle token refresh events—tokens rotate, and stale tokens are a silent delivery killer.
5. Identify users at the right moments (identity stitching)
   • Call identify immediately after login/signup.
   • If you support guest checkout or “email capture before account,” identify as soon as you have a stable identifier (even if they haven’t created a password yet).
   • Make sure anonymous browsing events can be merged into the identified profile if your architecture supports it—this is what makes “browse/cart recovery” work in practice.
6. Track the minimum viable retention events
   • product_viewed (include sku, category, price)
   • added_to_cart (include sku, qty, cart_id)
   • checkout_started (include cart_value)
   • order_completed (include order_id, order_value, items)
7. Validate in Customer.io before you build journeys
   • Confirm the profile shows a device entry (not just attributes).
   • Trigger a test push to your own device and confirm delivery.
   • Verify events appear on the same profile that owns the device token (this is the #1 “why didn’t it send?” issue).

When Should You Use This Feature

Push is most effective when the user intent is already high and the next step is one tap away. If you’re trying to “create demand” from scratch, email/SMS usually does the heavy lifting; push closes the loop when the shopper is already warm.

• Cart recovery (app): Trigger off added_to_cart with a short delay and deep link back to cart.
• Browse abandonment (high intent): Trigger off repeated product_viewed or a PDP view with no add-to-cart, especially for hero SKUs.
• Post-purchase replenishment: Use order_completed + expected replenishment window (e.g., 21–35 days) and send a “time to restock” push.
• Winback/reactivation: Target users who have push permission granted but haven’t opened the app or purchased in X days; use a strong “what’s new” or back-in-stock hook.
• Back-in-stock and price drop (if you track it): Push is ideal because it’s immediate and taps straight into PDP.

Operational Considerations

Once you ship the SDK work, the operational reality is about keeping data clean enough to segment and orchestrate without weird edge cases. This is where teams usually feel “push is unreliable,” when it’s really identity + event hygiene.

• Segmentation depends on permission + device presence: Build segments that require (1) push permission granted and (2) at least one active device. Otherwise you’ll inflate audience counts and under-deliver.
• Multi-device users are normal: Customer.io will often have multiple devices per person. Decide whether you’re okay with sending to all devices or want to suppress duplicates with frequency rules.
• Event timing and dedupe: Mobile apps can fire duplicate events (especially around background/foreground). Add idempotency keys (e.g., cart_id, order_id) and dedupe logic upstream if needed.
• Deep linking is part of “data flow”: If the push opens the app but lands on home, your conversion rate will look “mysteriously bad.” Pass SKU/cart context in the payload and route correctly.
• Orchestration across channels: If you also run email/SMS cart recovery, set clear precedence (e.g., push first for app users, SMS later only if no purchase). In practice, this tends to break when device eligibility isn’t included in the journey filters.

Implementation Checklist

If you want push to perform like a retention channel (not a vanity channel), you need a tight checklist that covers identity, devices, and events—not just “send a test.”

• SDK installed and initialized early in app lifecycle
• Push permission prompt implemented with a value moment
• APNs/FCM token captured and registered; token refresh handled
• identify called on login/signup and on any stable identity capture
• Anonymous-to-known stitching plan documented (what merges, what doesn’t)
• Core retention events tracked with consistent naming and required properties
• Deep links implemented and tested for cart, PDP, and order status
• Customer.io profile validation: device present + events on same profile
• Segments include “push eligible” rules (permission + device)
• Frequency limits defined to prevent over-messaging

Expert Implementation Tips

These are the small operator moves that keep push from becoming a noisy channel that the team stops trusting.

• Track a “push_enabled_at” timestamp: It’s a clean way to exclude brand-new opt-ins from immediate winback flows and measure lift from permission prompts.
• Send a silent “device registered” event: Helpful for debugging and for building a “newly push-eligible” segment you can warm up with a high-value message.
• Use cart_id everywhere: If your cart recovery journey keys off cart_id, you can exit the journey reliably when the cart converts—even if the user adds/removes items.
• Model product data consistently: If sku is sometimes a string and sometimes an object, personalization breaks at the worst time (during high-intent pushes).
• Measure delivery vs conversion separately: Low conversion might be creative/offer; low delivery is almost always tokens/permissions/identity.

Common Mistakes to Avoid

Most “push doesn’t work” issues are self-inflicted and show up after you scale. Avoid these early and you’ll save weeks of debugging and stakeholder doubt.

• Registering tokens before you can identify—then never stitching: Tokens end up on anonymous profiles, and your real customers look “unreachable.”
• Not handling token refresh: Everything works for a month, then delivery decays and nobody knows why.
• Building journeys without a push-eligible filter: Your journey audience looks huge, but actual sends are tiny.
• Using inconsistent event names across platforms: iOS fires add_to_cart, Android fires added_to_cart, and your segments miss half your users.
• No deep link context: Sending “Complete your purchase” but dumping users on the homepage kills conversion and makes push look weak.
• Over-messaging new installers: Asking for permission + sending promos immediately drives opt-outs and long-term channel fatigue.

Summary

If you want push to drive retention outcomes, treat it like SDK instrumentation: permission status, device tokens, identity stitching, and clean events. Once those are stable, cart recovery and replenishment journeys become straightforward—and performance becomes predictable.

Implement Push with Propel

If you already run retention in Customer.io, the highest-leverage work is usually tightening identity + event specs so push audiences match reality (and so journeys don’t leak conversions). If you want help pressure-testing your SDK tracking plan and mapping it to cart recovery, replenishment, and winback flows, book a strategy call and we’ll walk through what to instrument and how to operationalize it.