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

Overview

If you’re setting up push for retention, the hard part isn’t writing the notification—it’s getting clean device identity and event timing into Customer.io so the right person gets the right push on the right device. 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 SDK instrumentation against your retention goals.

In most D2C programs, push becomes your fastest lever for cart recovery and replenishment—until identity stitching breaks and your “Abandoned Cart” push starts hitting logged-out users, old devices, or nobody at all.

How It Works

Customer.io push is driven by device tokens (APNs for iOS, FCM for Android, browser tokens for web push) mapped to a person profile. Your SDK is responsible for collecting the token, associating it to the correct user via identify, and sending the behavioral events that trigger journeys.

• Device registration: the app gets a push token from Apple/Google (or the browser) and hands it to Customer.io through the SDK.
• Identity stitching: when a user logs in (or you otherwise know who they are), the app calls identify(user_id, attributes). Customer.io links the current device token(s) to that person.
• Event-driven sending: you track events like product_viewed, added_to_cart, checkout_started, and order_completed. Journeys listen for these events and send push immediately or after a delay.
• Multi-device reality: one person can have multiple devices/tokens. If your identify/logout handling is sloppy, pushes go to the wrong device—or keep going to a device after someone logs out.

Concrete D2C scenario: A shopper adds a moisturizer to cart on mobile, gets distracted, and closes the app. If your app tracked added_to_cart and the device token is correctly tied to their profile, you can send a push 30–60 minutes later with the exact item and a deep link back to cart. If you miss the identify call, Customer.io sees an event from an anonymous device and your recovery push never fires (or fires without personalization).

Step-by-Step Setup

Before you touch journeys, get the SDK plumbing right. Push is unforgiving: one missing permission prompt, token update, or identify call and your audience collapses.

1. Pick your SDK surface area (mobile + web): decide whether you’re implementing iOS, Android, and/or web push. If you run a D2C app, start with mobile first—web push is usually incremental, not foundational.
2. Install the Customer.io SDK: add the appropriate Customer.io Mobile SDK (iOS/Android/React Native/Flutter/etc.) to your app and initialize it on app launch with your workspace/site credentials.
3. Configure the push provider:
   • iOS: enable push capabilities, configure APNs, and ensure your app requests notification permission at the right moment (not instantly on first launch in most cases).
   • Android: configure Firebase Cloud Messaging (FCM) and verify your app can retrieve an FCM token reliably.
   • Web: set up service workers and browser permission prompts only after intent (e.g., after first purchase or after account creation).
4. Register device tokens with Customer.io: when your app receives/refreshes a token, pass it to the Customer.io SDK immediately. Tokens rotate—treat token refresh as a normal event, not an edge case.
5. Implement identify on login (and any time identity becomes known): call identify as soon as you have a stable user identifier (your customer ID). Include high-signal attributes you’ll segment on (e.g., email, first_order_date, vip_tier, skin_type).
6. Handle logout cleanly: when a user logs out, clear/reset the SDK identity so the next person using that device doesn’t inherit the previous user’s token-to-profile linkage.
7. Track retention-grade events (not vanity events): instrument events that map to money:
   • product_viewed (include sku, category)
   • added_to_cart (include sku, qty, cart_value)
   • checkout_started (include cart_value)
   • order_completed (include order_id, order_value, items)
8. Verify in Customer.io Activity Log: confirm (a) the person profile exists, (b) the device is attached, and (c) events arrive with the expected payloads.
9. Send a test transactional push: use a controlled test user to validate delivery, deep links, and that the message lands on the intended device.

When Should You Use This Feature

Push works best when timing matters and you can earn the interrupt. For D2C retention, that usually means high-intent moments and post-purchase windows—powered by SDK events so you’re not waiting on batch syncs.

• Cart recovery: trigger from added_to_cart or checkout_started, then delay 30–120 minutes depending on your average decision cycle.
• Browse abandonment with intent: trigger from repeated product_viewed on the same SKU/category within a short window (avoid spamming one-off views).
• Replenishment: trigger from order_completed + product metadata (e.g., 21–35 days later for consumables), then suppress if a new order occurs.
• Winback/reactivation: target users who have push permission + no session/open in X days, then personalize based on last category purchased/viewed.
• Back-in-stock or price drop: only if your app tracks subscribed_to_back_in_stock or wishlist_added so pushes go to opted-in intent, not broad guesswork.

Operational Considerations

Most push programs fail because the data model wasn’t designed for segmentation and orchestration. Treat push as a channel that’s downstream of identity, not a standalone feature.

• Segmentation depends on identity hygiene: if users browse anonymously and only identify at checkout, your top-of-funnel push audiences will be thin. In practice, this tends to break browse/cart programs unless you also support anonymous activity merging (or encourage earlier account creation).
• Token churn is real: iOS/Android tokens rotate. If you don’t forward refreshed tokens, deliverability quietly degrades over weeks.
• Multi-device suppression: decide whether you’re okay sending to all devices or only the “most recently active” device. If you don’t control for this, one customer can get duplicate pushes (especially common for iPad + iPhone shoppers).
• Event latency and ordering: cart recovery logic assumes added_to_cart arrives before order_completed. If your app queues events offline, you can accidentally send recovery pushes after purchase unless you add exit conditions.
• Deep linking is part of conversion: every push should open the exact screen (cart, PDP, order status). If your deep links are brittle, push looks like it “doesn’t work” when it’s really a UX drop-off.
• Orchestration with email/SMS: set channel priority rules (e.g., push first for app users, email fallback if no permission/token). Otherwise you’ll stack messages and spike unsubscribes.

Implementation Checklist

Use this to sanity-check the build before you scale sends. If any box is unchecked, fix it now—debugging push after launch is painful.

• Customer.io SDK installed and initialized on app launch
• Push provider configured (APNs/FCM/web) and tokens successfully generated
• Token registration wired to Customer.io, including token refresh handling
• identify called on login with a stable user_id and key attributes
• Logout/reset behavior implemented to prevent cross-user token leakage
• Retention events tracked with consistent naming and required properties (SKU, value, category)
• Events and device registrations verified in Customer.io Activity Log
• Deep links tested from push → in-app destination
• At least one test journey/transactional push successfully delivered end-to-end

Expert Implementation Tips

These are the small operator moves that keep push profitable instead of noisy.

• Delay the permission prompt until intent: ask after a meaningful action (account created, first add-to-cart, order shipped). Permission rates usually jump, and your push audience becomes higher value.
• Track “push_enabled” as an attribute: set a profile attribute when permission is granted/denied. It makes segmentation and channel fallback clean.
• Use event properties for personalization, not just triggers: pass product_name, image_url, cart_value. Your best-performing pushes tend to look like “your cart,” not “our sale.”
• Build exit conditions around purchase: every cart/browse journey should exit on order_completed to prevent post-purchase nags when events arrive late.
• Control frequency at the person level: cap pushes per day/week per user. D2C apps often over-message during promo periods and pay for it in opt-outs.

Common Mistakes to Avoid

Most of these show up as “push doesn’t convert” when the real issue is tracking or identity.

• Calling identify too late: if you only identify after purchase, cart and browse pushes won’t have a real person to attach to.
• Not resetting identity on logout: shared devices become a compliance and CX problem fast.
• Ignoring token refresh: delivery decays quietly; teams blame creative instead of plumbing.
• Event names drift between platforms: iOS sends AddedToCart, Android sends added_to_cart, and your journey triggers on only one.
• Sending without deep links: dumping users on the home screen kills conversion—especially for cart recovery.
• No suppression for recent purchasers: you end up pushing discounts to people who just paid full price.

Summary

If you want push to drive repeat purchase and recovery, treat the SDK as the product: clean tokens, disciplined identify, and events that map to revenue. Once identity stitching is stable, Customer.io journeys become straightforward to scale.

Implement Push with Propel

If you’re already running Customer.io, the fastest win is usually tightening SDK identity + event payloads so your push audiences stop leaking and your suppressions actually work. If you want help pressure-testing your tracking plan (tokens, identify/logout, event schema, and journey guardrails), book a strategy call and we’ll map it to the retention flows you care about—cart recovery, replenishment, and winback.