Push notifications setup (SDK-first) for Customer.io

Overview

If you’re setting up push in Customer.io, the real work isn’t the message composer—it’s getting clean device registration, consistent identity, and trustworthy events so push can actually drive repeat purchase and recovery. If you want a second set of eyes on your tracking plan (before you bake in messy IDs), book a strategy call and we’ll sanity-check the implementation like an operator would.

In most D2C retention programs, push becomes meaningful when it’s tied to intent (browse/cart), state (order/shipping), and lifecycle (lapsed/reactivation). That only works when the SDK is correctly installed, the device token is attached to the right person, and anonymous app activity gets stitched to the eventual logged-in profile.

How It Works

Customer.io push is basically a chain: your app collects a push token from Apple/Google (or a browser token for web push), the Customer.io SDK registers that token against a person, and your campaigns target that person/device based on attributes and events you send.

• Device registration: Your app obtains a push token (APNs for iOS, FCM for Android). The SDK sends that token to Customer.io so the device becomes addressable.
• Identity stitching: Users often browse anonymously, then log in at checkout. If you don’t handle the transition, push tokens and pre-login events can end up tied to the wrong profile (or an anonymous one that never gets messaged). The SDK pattern is: track anonymous events → user authenticates → call identify with your stable customer ID → ensure the device token is associated to that identified profile.
• Event-driven targeting: You fire events like Product Viewed, Added to Cart, Checkout Started, Order Placed, and Customer.io uses them to trigger push campaigns, build segments, and suppress messages when someone converts.
• Delivery plumbing: iOS requires APNs credentials/certificates configured; Android requires FCM credentials. Without those, you can “send” pushes in Customer.io and still get zero deliveries.

Real D2C scenario: A shopper views a skincare bundle on mobile, adds it to cart, gets distracted, and closes the app. If your SDK tracked Added to Cart with the cart value and item IDs, and the push token is registered to the right person, you can trigger a 30–60 minute cart recovery push and stop it instantly if Order Placed fires.

Step-by-Step Setup

Before you touch campaigns, get the SDK and identity layer right. Push is unforgiving: one missed call (or inconsistent IDs) and you’ll spend weeks debugging “why didn’t this send?” instead of shipping revenue-driving flows.

1. Pick your identity key (do this first).
   Use a stable, internal customer identifier (not email, not phone, not a device ID). This becomes the value you pass to identify in the SDK.
2. Install the Customer.io SDK for your platform.
   Implement the official SDK for iOS/Android (or your cross-platform wrapper like React Native/Flutter) and initialize it on app start with your workspace/site ID and region settings.
3. Request push permission at the right moment.
   Don’t prompt on first launch. Tie the prompt to user intent (e.g., after they save a routine, favorite a product, or opt into “restock alerts”). Better opt-in rate = bigger reachable audience.
4. Register the device token with Customer.io.
   When APNs/FCM returns a token, pass it to the SDK so Customer.io can associate the device with a profile. Confirm you handle token refresh events too—tokens rotate.
5. Implement identify on login (and whenever identity becomes known).
   Call identify immediately after authentication with your stable customer ID and key attributes (email, phone, first order date, etc.). This is where anonymous browsing becomes actionable.
6. Track retention-critical events (minimum viable set).
   Send events with useful properties:
   • Product Viewed (product_id, category, price)
   • Added to Cart (cart_id, value, items[])
   • Checkout Started (cart_id, value, shipping_method)
   • Order Placed (order_id, value, items[], discount_used)
   • Subscription Created (if you have replenishment)
7. Configure APNs/FCM credentials in Customer.io.
   Upload the required credentials in your Customer.io workspace for iOS and Android. Until this is done, delivery will fail even if tokens and events look correct.
8. Test end-to-end with a real device.
   Send a test push to a known profile, then validate: token exists on the profile, the profile is identifiable, events appear in activity, and the push arrives on device.

When Should You Use This Feature

Push is best when you need speed and frequency without paying per send, but it only performs when your SDK events reflect real intent. If your app tracking is thin or identity is messy, fix that first—otherwise you’ll just spam people with generic blasts.

• Cart recovery: Trigger off Added to Cart or Checkout Started, suppress on Order Placed, and personalize with last items viewed.
• Browse-to-buy nudges: For high-consideration products (supplements, skincare routines), send a push 4–24 hours after Product Viewed if no cart activity happened.
• Replenishment / repeat purchase: Use Order Placed + product-level attributes to estimate depletion windows and send a “time to restock” push.
• Reactivation: Target “no app open + no purchase” cohorts and use a push to pull them back into a personalized landing screen (not your homepage).

Operational Considerations

Once push is wired, the bottleneck shifts to segmentation and orchestration. In practice, this tends to break when teams treat push as a channel instead of a state machine: people move between anonymous/known, devices churn, and events arrive out of order.

• Segmentation depends on event hygiene: If Added to Cart sometimes fires without cart_id or value, your “high-intent carts” segment will be unreliable and hard to debug.
• Identity stitching is the make-or-break: If a user logs in after browsing, ensure the device token and pre-login events land on the same person profile you’ll message. Audit for duplicates and decide how you’ll resolve them.
• Data flow timing: Mobile events can batch/send late on poor connections. Build campaigns with sensible delays and exits (e.g., wait 30 minutes, then check if Order Placed happened).
• Orchestration across channels: Coordinate push with email/SMS so you don’t stack touches. Use suppression rules like “if push delivered, hold email for X hours unless they open.”
• Device coverage: A person can have multiple devices. Decide whether you message all devices or prefer “most recently active device” behavior, depending on your product and audience.

Implementation Checklist

If you want push to drive revenue (not just “engagement”), treat this like instrumentation work. This checklist is what we typically validate before we let a team scale sends.

• Customer.io SDK installed and initialized on app start (correct region/workspace settings)
• Stable customer ID defined and used consistently in identify
• Push permission prompt placed after a meaningful action (not on first launch)
• APNs (iOS) and/or FCM (Android) credentials configured in Customer.io
• Device token registration implemented + token refresh handled
• Anonymous-to-known stitching verified (browse → login → purchase stays on one profile)
• Core commerce events implemented with required properties (product_id, cart_id, order_id, value)
• Test device receives a push; profile shows token; event stream matches expected behavior

Expert Implementation Tips

These are the small operator moves that prevent weeks of “why is push underperforming?” later.

• Track “App Opened” and “Push Opened” cleanly: You need to know if push is driving sessions, not just deliveries. Make sure opens are attributed back into Customer.io so you can build “push engaged” segments.
• Use event properties to avoid generic messaging: A cart push that includes the top item name/category consistently beats “You left something behind.” That requires items[] on cart events.
• Build exits like a hawk: Every recovery flow should exit on Order Placed and ideally on Checkout Started (if the next step is email/SMS). This is where you protect CX while still being aggressive.
• Don’t rely on email as identity in the SDK: Email changes; logins can be social; guest checkout exists. Use your internal customer ID for identify, then attach email as an attribute.
• Validate token-to-person mapping: When debugging, always check: is the token present on the intended profile, or did it get attached to an anonymous/duplicate profile?

Common Mistakes to Avoid

Most “push doesn’t work” issues are really tracking and identity issues. Fix these and performance usually follows.

• Prompting for push permission on first launch: Opt-in rates crater, and you’ll never have enough reachable users for meaningful recovery programs.
• Calling identify inconsistently: If you only identify sometimes (or you use different IDs across platforms), you’ll fragment profiles and lose conversion attribution.
• Missing token refresh handling: Push quietly stops working for a chunk of users when tokens rotate.
• Event naming drift: “AddToCart” on Android and “Added to Cart” on iOS creates broken segments and duplicate campaign logic.
• No suppression on purchase: Nothing burns trust faster than a cart reminder after someone already paid.
• Testing only in simulators: Simulators don’t behave like real devices for push delivery. Always test on hardware.

Summary

If you want push to lift repeat purchase and recovery, treat SDK setup as the product: stable identity, reliable device tokens, and high-signal events.

Once those are solid, Customer.io campaigns become straightforward—and you can scale without guessing who you’re actually messaging.

Implement Push Setup with Propel

If you’re already running retention in Customer.io, push setup is one of those areas where a small instrumentation mistake can cap performance for months. We’ll help you map the right events, validate identity stitching, and pressure-test your cart/repeat flows against real app behavior—then you can move faster with confidence. If that’s useful, book a strategy call.