Set up Rich Push with Customer.io SDKs (D2C Retention Execution)

Overview

If you’re running push as a real retention channel (not just a broadcast megaphone), rich push is where the leverage is—images, deep links, and action buttons drive higher intent taps and cleaner post-click behavior. With Customer.io, the difference between “push sent” and “push that converts” usually comes down to whether your SDK tracking and identity stitching are airtight; if you want a second set of eyes on your implementation, book a strategy call.

Rich push setup is mostly an app-side job: registering devices correctly, identifying users at the right moments, and sending the events that let Customer.io target the right people with the right creative.

How It Works

Rich push is just push notifications with enhanced payloads—images, buttons, and deep links—but the operational win is that you can map taps to revenue-driving in-app actions. In practice, this tends to break when device tokens aren’t associated to the right person, or when “anonymous browsing” never gets merged into a known profile after login.

• Device registration: Your mobile app SDK registers the device token (APNs on iOS, FCM on Android) and associates it to a Customer.io person profile. If that association is wrong or missing, pushes either won’t deliver or will deliver to the wrong user.
• Identity stitching: The SDK tracks activity pre-login (anonymous) and you merge it into the authenticated user when they sign in or create an account. This is what lets you send a “finish checkout” rich push to someone who added to cart before logging in.
• Event-driven targeting: Your app sends events like product_viewed, added_to_cart, checkout_started, and order_completed. Customer.io uses those events to trigger campaigns and to personalize the rich push payload (hero image, product name, price, deep link).
• Rich payload rendering: iOS and Android render rich content differently. iOS typically requires a Notification Service Extension to display remote images reliably; Android uses notification styles and image URLs in the payload. If you skip the platform-specific rendering work, you’ll “send rich push” but users will see plain text.
• Tap + action tracking: A tap isn’t a conversion. You want the app to deep link to the right screen and then fire a follow-up event (e.g., push_opened, cart_recovered, viewed_checkout) so you can measure recovery rate and suppress people who already converted.

Step-by-Step Setup

The goal here is simple: every device gets registered once, every user gets identified at the right time, and every key commerce action emits an event you can use for orchestration. Do this cleanly and rich push becomes a reliable lever for cart recovery and repeat purchase.

1. Install the Customer.io mobile SDK for your platform
   Add the iOS/Android (or React Native/Flutter) SDK and confirm it initializes on app start. Treat initialization as “must not fail silently”—log it in debug builds.
2. Implement push permissions + token capture
   Request notification permission at a contextually right moment (post-value, not on first launch), then capture the APNs/FCM token and pass it to the SDK so Customer.io can deliver.
3. Register the device with Customer.io
   Make sure the SDK is registering the device token and keeping it up to date (tokens rotate). This is the #1 reason “push deliverability” looks fine in theory but underperforms in practice.
4. Call identify immediately after authentication
   On login/account creation, call the SDK identify method with your stable customer identifier (not an email that can change). This is where identity stitching happens.
5. Handle logout explicitly
   On logout, reset/clear the identified user state per SDK guidance. If you don’t, shared devices (or even test devices) will cause cross-user messaging—an expensive trust leak.
6. Track the events you actually need for retention
   At minimum for D2C: product_viewed, added_to_cart, checkout_started, order_completed. Include properties you’ll personalize with: product_id, product_name, image_url, price, variant, cart_value, currency, deep_link.
7. Set up rich rendering on each platform
   For iOS, implement the Notification Service Extension to download and attach images. For Android, implement the appropriate notification style for big images and action buttons.
8. Deep link handling + post-open events
   When a user taps a push (or an action button), route to the right screen and fire an event like push_opened with properties: campaign_id/message_id, action, destination. This is what makes optimization real.
9. QA with real devices and edge cases
   Test: fresh install, anonymous browse → add to cart → login, token rotation, notification permission denied → later enabled, and logout → login as different user.

When Should You Use This Feature

Rich push is worth the engineering time when your push program is already event-driven (or you’re committing to making it event-driven). If you’re still blasting promos to “everyone with push enabled,” rich media won’t save you.

• Cart recovery with real product context: Send a rich push 30–90 minutes after checkout_started with the exact item image and a deep link back to checkout. This consistently beats generic “You left something behind” copy.
• Back-in-stock / replenishment: Rich push with the product image and a “Buy now” action button works especially well for high-repeat categories (supplements, skincare, coffee).
• Post-purchase cross-sell: After order_completed, wait for delivery window, then send a rich push featuring the most compatible add-on with a deep link to a pre-filled cart.
• Reactivation with a single-step path: For lapsed buyers, rich push reduces friction—tap lands on a curated collection or their last purchased product page, not the home screen.

Real scenario: A skincare brand sees a lot of “add to cart” behavior in-app but weak recovery. After implementing identity stitching (anonymous → identified on login) and sending added_to_cart with image_url + deep_link, they run a rich push at 60 minutes: hero image of the serum, button “Resume checkout.” The key lift comes from (1) correct device-to-person mapping and (2) deep linking straight into checkout, not the cart page.

Operational Considerations

Once rich push is live, the real work is keeping targeting clean and your data reliable. Most retention programs we’ve seen hit a ceiling because the app and Customer.io disagree on identity, or because event properties aren’t consistent enough to personalize safely.

• Segmentation depends on identity hygiene: If you identify late (e.g., only after checkout), you’ll miss the highest-intent recovery window. Identify at login and also consider identifying on email capture if that’s your first durable identifier.
• Event naming + property standards: Lock a schema early. If half your events send imageUrl and the other half send image_url, your rich push will degrade into text-only for a chunk of users.
• Data flow latency: If events arrive late, your “60-minute cart recovery” becomes a “3-hour cart recovery.” Monitor event ingestion timing from the SDK to Customer.io.
• Orchestration and suppression: Always suppress by conversion events. If order_completed fires, immediately exit the user from recovery and stop reminders. This is where Customer.io shines when your events are trustworthy.
• Cross-channel coordination: Rich push works best when it’s coordinated with email/SMS, not competing. Use push for fast intent capture; use email for longer-form persuasion; use SMS sparingly for high-confidence recovery.
• Multi-device reality: A single person may have multiple devices/tokens. Make sure your identify strategy supports that, and that logout doesn’t accidentally orphan valid tokens.

Implementation Checklist

Before you scale spend or rely on rich push for revenue targets, you want confidence in the basics: delivery, identity, deep links, and measurement. This checklist keeps you out of the “looks fine in the dashboard” trap.

• Customer.io mobile SDK initialized on app start (verified in logs)
• Push permission prompt implemented with a deliberate trigger (not first launch)
• APNs/FCM token captured and registered; token refresh handled
• identify called immediately after login/account creation with a stable customer ID
• Logout clears identified state to prevent cross-user messaging
• Core commerce events tracked with consistent naming and required properties
• iOS rich push rendering implemented (Notification Service Extension for images)
• Android rich push rendering implemented (big image style + actions)
• Deep links route to the correct screen and handle cold start
• Post-open event tracked to measure true recovery (not just opens)
• Campaign suppression rules based on order_completed / conversion events

Expert Implementation Tips

The difference between “we have rich push” and “rich push prints money” is usually a handful of unglamorous details—identity timing, payload fallbacks, and measurement discipline.

• Send a safe fallback payload: Always include text-only content and a default deep link. If the image fails to load, you still get a usable notification.
• Personalize with what you can guarantee: Use image_url only if it’s present on 95%+ of relevant events; otherwise build logic to swap to a category image.
• Track “resume checkout” as its own event: Don’t rely only on push_opened. Fire checkout_resumed when the deep link lands on checkout successfully—this is the metric that correlates to recovered revenue.
• Use short delays with guardrails: For cart recovery, start with 30–90 minutes and suppress aggressively. Longer delays belong in email, not push.
• Deduplicate triggers: If users add multiple items, you’ll spam them unless you collapse events (e.g., only trigger on the latest added_to_cart within a window).

Common Mistakes to Avoid

Most teams don’t fail because they can’t send a push—they fail because the app instrumentation isn’t built for retention-grade orchestration. These are the ones that show up over and over.

• Identifying with an unstable ID: Using email as the primary identifier leads to broken stitching when users change emails or check out with different addresses.
• Forgetting logout handling: Shared devices and QA devices will receive the wrong user’s messages, which is both a trust and compliance issue.
• Missing deep link support on cold start: Push tap opens the app but drops users on the home screen. Conversion rate tanks and attribution gets muddy.
• Inconsistent event properties: Personalization fails silently when properties are missing or named inconsistently.
• Measuring opens instead of outcomes: Opens are directionally useful, but you need downstream events (resume checkout, purchase) to optimize frequency and creative.
• No suppression on purchase: The fastest way to annoy customers is to keep sending “complete your order” after they already did.

Summary

Rich push is a retention multiplier when your SDK implementation is clean: devices registered correctly, users identified at the right time, and commerce events tracked with consistent properties.

If you want cart recovery, repeat purchase, and reactivation to feel predictable, treat identity stitching and deep link measurement as first-class requirements—not “nice to have.”

Implement Rich Push with Propel

If you’re already on Customer.io, the fastest path is usually tightening the app-side tracking first (identify timing, event schema, deep link outcomes), then building the rich push campaigns on top. When teams ask for help, it’s rarely the message build—it’s the instrumentation and suppression logic that determines whether push drives incremental revenue or just noise.

If you want an operator-led review of your SDK events, identity stitching, and a cart recovery rich push flow end-to-end, book a strategy call.