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

Overview

If you want push to drive revenue (not just “engagement”), the work starts in the SDK—clean device registration, consistent identify calls, and event tracking that maps to how people actually buy. Customer.io’s push channel is straightforward once your app-side tracking is reliable, and if you want a second set of eyes on identity stitching and event design, Customer.io is a common stack we see in D2C—feel free to book a strategy call.

In most retention programs, push wins when it’s triggered off high-intent moments (carted, viewed, replenishment window) and throttled with sane frequency rules. If your device tokens aren’t tied to the right profile, you’ll “send” a lot of messages that never land—or land on the wrong person.

How It Works

Push in Customer.io is powered by devices attached to a person profile. Your SDK is responsible for (1) collecting the push token/registration, (2) associating that device to the right user via identify, and (3) sending events Customer.io can use to trigger campaigns and segment audiences.

• Device registration: The mobile SDK captures the APNs (iOS) or FCM (Android) token and registers it with Customer.io so the person becomes “push addressable.”
• Identity stitching (the make-or-break step): Anonymous app activity becomes useful only after you call identify with your stable customer identifier (typically your internal user ID; email as a secondary attribute). This is what ties the device token to the customer profile that your ecommerce data also updates.
• Event tracking: Your app sends behavioral events (e.g., product_viewed, added_to_cart, checkout_started, order_completed) with properties (SKU, category, cart value). Those events trigger push automations and build segments.
• Delivery + orchestration: Customer.io uses those events/attributes to decide who enters a campaign, which push gets sent, and when. If you also send email/SMS, you’ll typically coordinate channels using the same events and a “last messaged”/frequency strategy.

Real D2C scenario: A shopper browses on mobile, adds a bundle to cart, then gets distracted. If your SDK fires added_to_cart and the user is identified (or you later merge anonymous activity into the known profile), you can trigger a push 30–60 minutes later with the exact bundle name and price—then suppress the push if order_completed fires.

Step-by-Step Setup

Think of setup as two parallel tracks: making the device reachable (permissions + tokens) and making the data usable (identity + events). Get both right before you build journeys, otherwise you’ll debug “why didn’t this send?” for weeks.

1. Pick your identity strategy up front.
   Decide your primary identifier (best practice: internal user/customer ID). Treat email/phone as attributes, not identifiers, unless your system truly guarantees uniqueness and permanence.
2. Install the Customer.io mobile SDK for your platform.
   Add the SDK to iOS/Android (or React Native/Flutter/Expo) and confirm the base integration is running in a dev build before touching push.
3. Enable push permissions and capture tokens.
   Implement the OS-level push permission prompt (iOS) and ensure your app receives APNs/FCM tokens. Verify token refresh flows—tokens change more often than teams expect.
4. Register the device with Customer.io.
   Confirm the SDK is sending the device token to Customer.io and that the device appears on the person profile as a push-capable device.
5. Call identify immediately after login/account creation.
   This is where most retention programs break. Make the call as soon as you have a known user, and include key attributes you’ll segment on (email, acquisition source, first_order_date if available, etc.).
6. Track purchase-intent events with consistent naming and properties.
   Implement a small set of canonical events (view → cart → checkout → purchase). Include properties like sku, product_name, category, price, currency, cart_value, and quantity.
7. Validate in Customer.io: profile, device, and event stream.
   In Activity Logs / profile view, confirm: (a) the user is identified, (b) the device is attached, and (c) events arrive with the right properties.
8. Create a basic push message and send a test to internal devices.
   Keep it simple: a transactional-style push or a one-step campaign triggered by a test event. Confirm delivery and deep link behavior.
9. Build your first revenue push automation.
   Start with cart abandonment or browse abandonment. Add exit conditions based on purchase events and a frequency cap to avoid spamming.

When Should You Use This Feature

Push is best when you need a fast, high-visibility nudge tied to a specific behavior—especially on mobile-first brands where email is slower or less reliable. The SDK is what makes it precise enough to feel personal instead of noisy.

• Cart recovery on mobile: Trigger on added_to_cart or checkout_started, then suppress if order_completed happens. This is where token-to-user stitching matters most.
• Browse abandonment for product discovery: If someone views 2–3 PDPs in a category but doesn’t add to cart, send a push featuring the category they browsed (not a generic “come back”).
• Replenishment and repeat purchase: Trigger based on last purchase date + product type (e.g., skincare at 30 days, supplements at 25 days). The event/attribute model needs to store what they bought, not just that they bought.
• Winback/reactivation: Use inactivity windows (no app open + no purchase) and target only users who are still push-reachable and historically engaged.

Operational Considerations

Once the SDK is live, the real work is keeping data clean enough to segment confidently and orchestrate across channels without collisions. In practice, push programs degrade over time when identity and event contracts aren’t enforced.

• Segmentation depends on consistent identifiers: If some devices are tied to anonymous profiles and others to known profiles, you’ll under-send (missing customers) and over-send (duplicate profiles). Make merging/duplication a first-class concern.
• Event timing and ordering: Mobile events can arrive late or out of order (offline mode). Design triggers with buffers (e.g., wait 20–30 minutes before sending cart push) and always include purchase-based exit conditions.
• Frequency and channel arbitration: Decide what happens if the same user qualifies for push + email + SMS. A common approach: push first for speed, then email if no conversion, SMS only for high-intent and opted-in users.
• Deep links and measurement: If your push opens the app but drops users on home, you’ll lose the moment. Use deep links into cart/PDP and tag links/opens so you can tie sessions back to campaigns.
• Token churn and deliverability: Uninstalls, permission revokes, and token refreshes are normal. Monitor reachable audience size over time; sudden drops usually indicate an SDK regression.

Implementation Checklist

If you want push to be a dependable revenue channel, treat this like a production integration checklist—not a one-time “turn it on” task. Run through this before you scale campaigns.

• SDK installed and verified in dev/staging builds
• Push permission prompt implemented with a deliberate moment (post-value, not on first open)
• APNs/FCM tokens captured, refreshed, and successfully registered to Customer.io
• identify called on login/signup; stable user ID used consistently
• Anonymous-to-known stitching plan confirmed (and tested)
• Canonical events implemented: product_viewed, added_to_cart, checkout_started, order_completed
• Event properties standardized (SKU, category, cart value, currency)
• Deep links tested for cart/PDP and measured
• At least one cart recovery automation live with exit conditions + frequency cap
• Monitoring in place for token reachability and event volume anomalies

Expert Implementation Tips

These are the things that tend to separate “we have push” from “push prints incremental revenue.” They’re mostly unsexy, but they’re what keep your program stable as you scale.

• Delay your first cart push slightly. Sending immediately after added_to_cart often hits while they’re still shopping. A 30–60 minute delay usually lifts conversion and reduces complaints.
• Track a single “cart state” event if your cart is complex. For multi-item carts, emitting a cart_updated event with an items array + totals can be easier to operationalize than dozens of item-level events.
• Use internal IDs for identity, always. Emails change, and shared inboxes exist. Internal ID + email attribute is the cleanest way to prevent profile fragmentation.
• Design push copy around the last action. “Finish checkout” works when checkout_started fired. “Your cart is waiting” works when added_to_cart fired. Don’t mix them, or you’ll confuse high-intent buyers.
• Build suppression as aggressively as triggers. Purchase, refund, subscription pause, and support ticket states should all be able to suppress certain pushes.

Common Mistakes to Avoid

Most push failures aren’t creative problems—they’re plumbing problems. Fix these early and you’ll save yourself a lot of “Customer.io sent it but nobody got it” investigations.

• Prompting for push permission on first app open. Opt-in rates tank, and you’ll shrink your reachable audience before you even have intent signals.
• Calling identify inconsistently. If you only identify on some sessions, devices float around on anonymous profiles and your triggers won’t match the right person.
• Using email as the primary identifier without guarantees. This creates duplicates when people update emails or use Apple private relay addresses.
• Triggering cart flows without purchase-based exits. You’ll send “complete your order” to people who already bought—an easy way to burn trust.
• No event/property contract. If one app version sends cart_value and another sends cartTotal, your segments and personalization break silently.
• Deep links not tested end-to-end. A push that dumps users on home instead of cart/PDP will underperform and look like an attribution issue.

Summary

Push in Customer.io is only as good as your SDK implementation: device registration, consistent identify, and purchase-intent events with clean properties. Nail identity stitching and suppression rules, then scale cart recovery, replenishment, and winback with confidence.

Implement Push with Propel

If you’re already running Customer.io and want push to behave like a revenue channel (tight identity stitching, durable event contracts, and journeys that don’t collide with email/SMS), it’s worth pressure-testing your SDK instrumentation before you scale. When it’s helpful, you can book a strategy call and we’ll map your app events to the specific retention flows you’re trying to run.