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

Overview

If you want push to actually move repeat purchase and recovery numbers, the work starts in the SDK—not in the message editor. Customer.io push performs best when your app-side identity and event stream are clean, because every send depends on matching a device token to the right person at the right moment.

This guide translates Customer.io’s push setup into the way retention teams run it in production. If you want a second set of eyes on identity stitching, event naming, and orchestration (where most push programs quietly break), book a strategy call.

How It Works

Push in Customer.io is basically a chain: the SDK registers a device, Customer.io stores that device on a person profile, and campaigns/journeys target that person based on events and attributes. When any link in that chain is weak (anonymous users, duplicate profiles, missing permissions, or events firing at the wrong time), your push audience shrinks or gets noisy.

• Device registration: Your app (iOS/Android/React Native/etc.) requests push permission and receives a push token from APNs/FCM. The Customer.io SDK forwards that token to Customer.io so it can be used for sends.
• Identity stitching: The critical step is calling identify after login (and anytime a user becomes known). This attaches the device token + future events to the correct Customer.io person record.
• Event-driven targeting: You track app events like product_viewed, added_to_cart, checkout_started, purchase. Customer.io uses those events to trigger campaigns and build segments (e.g., “Added to cart in last 2 hours AND no purchase”).
• Send orchestration: Journeys/campaigns decide timing, frequency, suppression, and fallbacks (email/SMS) based on what the SDK reports (events, device presence, permissions).

Step-by-Step Setup

Push setup is straightforward, but the operator trick is sequencing: get the SDK installed, confirm device registration, then lock down identify + event timing before you build any recovery flows. Otherwise you’ll spend weeks debugging “why is my audience tiny?”

1. Install the Customer.io Mobile SDK for your platform
   Add the SDK to your iOS/Android app (or your wrapper like React Native/Flutter/Expo) and initialize it on app launch with your Customer.io credentials.
2. Enable push capability in your app
   Configure APNs (iOS) or FCM (Android), then implement permission prompts and token handling. Make sure the SDK receives the token so it can register the device in Customer.io.
3. Call identify immediately after authentication
   When a user logs in (or you otherwise know who they are), call identify(userId, attributes). This is what stitches the device to the person. If you skip this, your push tokens sit on anonymous profiles and won’t join your retention segments cleanly.
4. Track the events you’ll actually orchestrate from
   Implement track calls for retention-critical moments:
   • product_viewed (include SKU, category, price)
   • added_to_cart (include cart_id, items[], value)
   • checkout_started (include cart_id, value)
   • purchase (include order_id, items[], value, currency)
   Keep names stable. Don’t ship v2/v3 event names unless you’re intentionally migrating.
5. Verify device + person linkage in Customer.io
   In your workspace, spot-check a real internal user: confirm the person profile shows a device registered for push and that events are arriving under the same profile (not split across duplicates).
6. Create a push message channel and test a send
   Send a test push to a known internal profile. You’re validating end-to-end delivery (permission → token → registration → send).
7. Only then build your first retention journey
   Start with a single push recovery flow (cart or browse) and add suppression logic before scaling volume.

When Should You Use This Feature

Push is best when you need speed and you’re reacting to fresh intent—especially in D2C where the purchase window is short. In most retention programs, we’ve seen push outperform email for “right now” moments, but only when identity and timing are tight.

• Cart recovery (high intent): Trigger from added_to_cart or checkout_started, then suppress if purchase happens.
• Browse abandonment / product discovery: If someone views the same SKU 2–3 times in-app and doesn’t add to cart, push a reminder with social proof or inventory pressure (carefully).
• Repeat purchase nudges: Use purchase + product metadata to time replenishment (e.g., 21 days after purchase for skincare) and send push only to people with an active push token.
• Reactivation: Target lapsed app users where email is saturated—e.g., “No session in 30 days” AND “Push enabled” AND “Previously purchased.”

Real D2C scenario: A supplement brand tracks added_to_cart with item details. If there’s no purchase within 45 minutes, they send a push: “Still thinking about {{item_name}}? Your cart’s saved.” If the user opens the app but doesn’t buy, the journey waits 6 hours and then switches to email with education content instead of discounting immediately.

Operational Considerations

Push programs don’t fail because of copy—they fail because the audience logic is built on shaky data. Treat push like a data product: define what “eligible” means, and enforce it through segmentation and orchestration.

• Segmentation: build on device reality, not wishful thinking.
  • Always segment on “has a push-enabled device” (or equivalent device presence) so you don’t route people into dead-end push steps.
  • Split by platform (iOS vs Android) if your deep links, permission rates, or deliverability differ.
• Data flow: event timing matters more than event volume.
  • Fire purchase as close to confirmation as possible. Late purchase events cause double-sends (cart push after someone already bought).
  • Send cart events from a single source of truth. If web and app both emit added_to_cart with different schemas, your segments get messy fast.
• Identity stitching: duplicates quietly kill performance.
  • If users can browse anonymously, track anonymous events—but make sure you merge/identify when they log in or checkout. Otherwise you’ll retarget the wrong profile.
  • Standardize on one customer_id (not email sometimes, phone other times). Consistency is what keeps device tokens attached to the right person over time.
• Orchestration: push should cooperate with email/SMS, not compete.
  • Add frequency controls so high-intent flows (cart) don’t collide with broad promos.
  • Use channel fallback: if no push device exists, route to email/SMS instead of dropping the user.

Implementation Checklist

Before you scale push volume, lock these in. This is the stuff that prevents “it works on my phone” from turning into a retention channel that can’t be trusted.

• SDK installed and initialized on app launch (correct workspace/site credentials).
• Push permissions implemented with a deliberate prompt strategy (not immediately on first open unless you’ve tested it).
• Device token successfully registers in Customer.io and appears on the person profile.
• identify fires on login and updates attributes (email, phone, first_name, etc.) consistently.
• Core retention events implemented: product_viewed, added_to_cart, checkout_started, purchase.
• Event payloads include the minimum fields needed for personalization and suppression (cart_id/order_id/value/items).
• Basic eligibility segment created: “Push enabled device present.”
• Test journey built and validated end-to-end (trigger → delay → suppression → send).

Expert Implementation Tips

Once the basics are in, small operator choices make a big difference in revenue and customer experience. These are the patterns that tend to hold up under real traffic.

• Track a dedicated suppression event for edge cases.
  If your checkout can complete outside the app (Shop Pay, browser handoff), emit a purchase or order_completed event back into the app/server stream immediately. Otherwise cart pushes will keep firing after conversion.
• Use cart IDs to prevent “multi-cart spam.”
  Include cart_id in added_to_cart and checkout_started. In Customer.io, you can suppress or exit the journey when that cart converts, instead of treating every add as a new recovery.
• Time your permission prompt to intent.
  Asking for push permission after a user favorites a product or adds to cart typically converts better than asking on first launch. Higher opt-in rates directly expand your recoverable audience.
• Normalize event names across app and web.
  In practice, this tends to break when mobile ships AddedToCart while web ships added_to_cart. Pick one taxonomy and enforce it so segments don’t fragment.

Common Mistakes to Avoid

These are the mistakes that create misleading reporting and brittle journeys—especially when multiple teams touch the app and retention stack.

• Delaying identify until “later”: If you only identify on checkout, you’ll lose the ability to target earlier intent and you’ll strand device tokens on anonymous profiles.
• Tracking purchase too late: If the event arrives minutes later, your suppression logic fails and you’ll send recovery pushes to people who already paid.
• Building push journeys without a “push eligible” segment: You end up with journeys that look fine but silently skip most users due to no device token.
• No dedupe strategy for multiple devices: One customer with two devices can get two pushes. Decide if that’s acceptable, and if not, design around “most recently active device” behavior.
• Over-personalizing without payload discipline: If your push copy depends on item_name but half your events don’t send it, you’ll ship broken messages or blank variables.

Summary

If you want push to drive cart recovery and repeat purchase, treat SDK tracking and identity stitching as the real setup work. Once devices reliably attach to the right person and events arrive on time, Customer.io journeys become predictable and scalable.

Decision rule: if you can’t confidently answer “which person owns this device token?” you’re not ready to scale push volume yet.

Implement Push with Propel

If you’re already on Customer.io, the fastest win is usually tightening the app-side identify/event layer and then rebuilding 1–2 push journeys with clean suppression and channel fallback. That’s where we typically see cart recovery and reactivation lift without increasing discount pressure.

If you want help validating your SDK instrumentation (identify timing, event schemas, duplicate profiles) and turning it into production-ready push orchestration, book a strategy call.