Push Notifications Setup (Mobile SDK) for Customer.io

Overview

If you want push to actually drive revenue (not just “engagement”), you need the Customer.io mobile SDK wired cleanly: device tokens captured, users identified, and events tracked with enough detail to segment and orchestrate. If you want a second set of eyes on your tracking plan and identity stitching before you ship, book a strategy call—this is one of those setups where small mistakes quietly kill deliverability and attribution.

In most D2C retention programs, push becomes a top-3 revenue channel when it’s tied to real behaviors (add to cart, browse, back-in-stock, replenish windows) and your identity graph is stable across anonymous browsing → login → purchase.

How It Works

Push in Customer.io is basically a chain: your app collects a device token from Apple/Google, the SDK registers that device to a person profile in Customer.io, and your events/attributes decide who gets messaged and when. The “magic” is identity stitching—making sure the same human isn’t split across multiple profiles (anonymous device profile, logged-in profile, checkout profile).

• Device registration: iOS uses APNs; Android uses FCM. Your app requests permission (iOS) and receives a device token, which must be passed to the Customer.io SDK so the device is reachable.
• Identify call: when you know who the user is (login, account creation, checkout), you call identify with a stable customer identifier (e.g., your internal customer_id). This is what ties the device token to the right person profile.
• Event tracking: you send events like product_viewed, added_to_cart, checkout_started, and order_completed with properties (SKU, category, cart value). These events power segments and campaign triggers.
• Segmentation + orchestration: Customer.io evaluates events/attributes and enters people into campaigns (cart recovery, browse abandonment, winback). Push is one message channel inside that orchestration.
• Accuracy reality: if you register devices before identify (common) but never merge/identify later, you’ll message “ghost” anonymous profiles and miss the real customer—especially after login or reinstall.

Step-by-Step Setup

Set this up like you’d set up payments: do it once, do it cleanly, and test the full lifecycle (fresh install → permission prompt → anonymous browse → login → purchase → uninstall/reinstall). The goal is to end up with one person profile per customer, with the right device(s) attached.

1. Choose your SDK path (native or cross-platform).
   Customer.io supports mobile SDKs across iOS, Android, and common cross-platform stacks (React Native/Expo/Flutter). Pick one implementation approach and avoid “half native, half wrapper” unless you have to—those are the setups that break token registration.
2. Install the Customer.io SDK in your app.
   Add the SDK to your project and initialize it at app start with your workspace credentials. Do this early in the app lifecycle so device registration and event tracking don’t race.
3. Implement push permission + token capture.
   
   • iOS: request notification permission at the right moment (after value is demonstrated), register for remote notifications, and pass the APNs device token to the SDK.
   • Android: set up FCM, ensure your app receives the FCM token, and provide it to the SDK.
   Your job here is to make sure the token is reliably collected and refreshed (tokens rotate).
4. Call identify as soon as the user is known.
   On login/account creation/checkout, call identify with a stable ID (not email unless it’s guaranteed immutable). This is what stitches the device token and any pre-login events to the right person.
5. Track the retention events that actually matter.
   Start with a tight event set and enforce naming consistency. For D2C, the minimum viable set tends to be:
   • product_viewed (properties: sku, category, price)
   • added_to_cart (properties: sku, qty, cart_value)
   • checkout_started (properties: cart_value, items)
   • order_completed (properties: order_id, revenue, items)
   If you already have subscription/replenishment behavior, add subscription_created / next_charge_date as attributes.
6. Verify device attachment in Customer.io.
   After install + permission + identify, check a real test profile in Customer.io to confirm:
   • A device exists (platform, token present)
   • The device is attached to the identified person (not a separate anonymous profile)
   • Recent events show up with the expected properties
7. Send a controlled test push.
   Test both transactional-style pushes (immediate) and campaign pushes (segment-based). Confirm delivery on device and validate that deep links open the correct screen.

When Should You Use This Feature

Push setup is worth the engineering time when you have repeatable behaviors you can trigger from and enough margin to justify incremental conversions. If your app is mostly a wrapper around the site and users rarely allow notifications, you’ll still want it—but expectations should be tied to opt-in rate and install base.

• Cart recovery (app users): trigger on added_to_cart with no order_completed within X hours. This is where tight identity stitching matters—cart events often happen pre-login.
• Browse abandonment: trigger on product_viewed for high-intent categories (e.g., “running shoes”) and suppress if they return organically within 2–4 hours.
• Replenishment / repeat purchase: use order_completed + product metadata to estimate replenishment windows (e.g., 21–35 days) and message only customers who haven’t repurchased.
• Reactivation: target customers with no app opens + no purchases in 45–90 days, but only if you can personalize with last category/SKU and a strong reason to come back.

Real D2C scenario: A skincare brand sees a lot of “add to cart” on mobile, but checkout completion happens after users log in. Without an identify call at login, the cart event sits on an anonymous profile and the cart recovery push never reaches the real customer. Once identify + merge is correct, the brand can run a 2-step push: (1) reminder with the exact product name, (2) 12 hours later, a low-friction offer for first-time purchasers only.

Operational Considerations

Push isn’t hard to ship—it’s hard to keep clean as your app evolves. Most issues come from inconsistent IDs, duplicated profiles, or event payload drift after a release.

• Segmentation depends on event hygiene: if one team sends add_to_cart and another sends added_to_cart, your cart recovery audience quietly shrinks. Lock event names and properties like an API contract.
• Identity stitching is the real unlock: decide your canonical identifier (internal customer ID). Use email as an attribute, not the primary key, unless you’re 100% sure it never changes.
• Anonymous-to-known flow: if you let users browse without login, you need a plan for merging anonymous activity once they identify. In practice, this tends to break after app reinstalls or when users log in on a second device.
• Multi-device reality: one person may have multiple devices/tokens. Your orchestration should assume that and avoid sending duplicates (frequency caps + “send to most recently active device” logic where possible).
• Data flow timing: cart recovery workflows are sensitive to minutes/hours. If events batch or arrive late, your “1 hour after add to cart” push becomes “tomorrow,” which tanks conversion.

Implementation Checklist

Before you build campaigns, get the plumbing right. This checklist is what we run through to avoid the classic “push says sent, but nobody got it” fire drill.

• SDK installed and initialized at app launch
• Push permission prompt implemented intentionally (not on first open by default)
• APNs/FCM token captured, refreshed, and passed to the SDK
• identify called on login/account creation/checkout with a stable ID
• Core retention events tracked with consistent naming and required properties
• Test profile in Customer.io shows: identified user + device attached + events arriving
• Deep links tested end-to-end from push → correct in-app destination
• Basic suppression logic planned (purchased, already returned, already messaged)

Expert Implementation Tips

These are the small operational choices that usually separate “push as noise” from “push as a revenue line item.”

• Delay permission until intent is proven: ask after a meaningful action (e.g., after first add-to-cart or after they favorite a product). Opt-in rate is the ceiling for everything else.
• Send richer event payloads than you think you need: include sku, product_name, category, and cart_value so you can personalize without relying on brittle lookups later.
• Use “known customer” campaigns for offers: keep discounting behind an identified user segment so you can enforce eligibility and avoid leaking promos to anonymous profiles.
• Build a debug view for QA: log identify + event calls in a dev build. When something breaks, you’ll know if it’s token registration, identity, or event delivery.
• Plan for token churn: treat token refresh handling as required, not “nice to have,” especially on Android where device/OS conditions can change delivery behavior.

Common Mistakes to Avoid

Most push “underperformance” is actually setup debt. These are the repeat offenders we see when auditing D2C apps.

• Using email as the primary identifier: emails change, get aliased, or differ between checkout and account. That’s how you end up with split profiles and missing devices.
• Never calling identify after collecting a token: you successfully register a device… to an anonymous profile you’ll never message again.
• Event naming drift across app versions: older versions send checkout_started, newer versions send begin_checkout. Your segments become version-dependent.
• Triggering cart recovery off the wrong signal: using “viewed cart screen” instead of added_to_cart or checkout_started inflates the audience with low intent.
• No suppression for recent purchasers: sending “Complete your order” after order_completed because purchase events arrive late or aren’t wired.
• Deep links not mapped: the push lands users on the home screen, not the cart/product—conversion drops and you blame creative.

Summary

If you want push to drive repeat purchase and recovery flows, treat the SDK setup as an identity and data-quality project—not a messaging project. Get device registration, identify, and your core commerce events correct, then build segments and orchestration on top.

If your app can reliably tie pre-login intent to post-login purchases, push becomes a dependable retention lever instead of an unreliable broadcast channel.

Implement Push Setup with Propel

When teams implement push quickly, the part that usually slips is the stitching between anonymous activity, device tokens, and the eventual customer profile in Customer.io. That’s also the difference between “we sent pushes” and “we recovered carts.”

If you want help pressure-testing your tracking plan, identity strategy, and the exact events/properties you’ll need for cart recovery and replenishment journeys, book a strategy call and we’ll map it to a build checklist your dev team can ship confidently.