Set up Rich Push with Customer.io SDKs (iOS/Android) for Retention

Overview

If you want rich push (images, expanded layouts, and more engaging notifications) to reliably drive repeat purchases and recover carts, the work starts in the app—not in the message editor. Customer.io can send the payload, but your SDK setup determines whether the right device gets the right message at the right time; if you want help pressure-testing the tracking and identity plan, book a strategy call.

In most retention programs, rich push lifts CTR mainly when it’s paired with clean identity stitching (anonymous browsing → known purchaser) and accurate event timing (add-to-cart, checkout started, purchase). If either is shaky, you’ll end up sending beautiful pushes to the wrong person—or to nobody.

How It Works

Rich push is essentially a push notification that includes additional media and presentation options (like an image) and requires OS-level support plus correct device registration. Customer.io handles message orchestration and delivery logic, but your app has to (1) register the device push token, (2) associate that device to the right person profile, and (3) pass the right event data so campaigns can personalize and target.

• SDK registers the device: On app install/launch, the SDK captures the push token (APNs on iOS, FCM on Android) and sends it to Customer.io so the device is push-addressable.
• Identify stitches anonymous to known: When a shopper logs in or you otherwise know who they are (email/phone/customer ID), your app calls identify. That’s what ties the device token + prior anonymous activity to the customer profile you’ll segment and message.
• Events drive targeting + personalization: Your app sends events like product_viewed, added_to_cart, checkout_started, and order_completed with properties (SKU, category, cart value, image URL). Those properties are what you use to build rich push content (e.g., product image) and to trigger recovery/reactivation flows.
• Rich media rendering happens on-device: iOS/Android decide how the notification expands and displays media. If your payload is missing required fields or your app isn’t configured for rich notifications, the message may fall back to plain text.

Step-by-Step Setup

Plan this like a retention instrumentation project, not a “turn on push” task. You’re aiming for: correct device registration, consistent person IDs, and event payloads that are usable in segmentation and message personalization.

1. Install the Customer.io mobile SDK
   Add the Customer.io SDK for your platform (iOS/Android/React Native/Flutter, etc.) and confirm it initializes on app start in all environments (dev/stage/prod).
2. Enable push permissions and token capture
   Implement the OS permission prompt (ideally after value is shown—like after a shopper favorites an item). Make sure APNs/FCM token capture works and is passed to the SDK so Customer.io can register the device.
3. Implement identify at the right moment
   Call identify immediately after login/account creation (and after any “continue as guest → create account” moment). Use a stable identifier (your internal customer ID is best; email is fine if it never changes). This is the step that prevents “cart recovery push went to the guest profile” issues.
4. Track the retention-critical events (with properties)
   At minimum, send:
   • product_viewed (sku, product_name, category, price, image_url)
   • added_to_cart (sku(s), qty, cart_value, image_url, cart_id)
   • checkout_started (cart_value, cart_id, item_count)
   • order_completed (order_id, revenue, items, first_order_boolean)
   These properties are what make rich push actually “rich” (e.g., pulling image_url into the notification).
5. Validate device → person stitching
   Run a test: install app → browse as guest → add to cart → then create account/login → confirm the same Customer.io person profile shows the device and the full event history. This is where rich push programs usually break in practice.
6. Build a rich push message using event data
   Create a push template that references event properties (like product name and image URL). Use fallback values so the message still renders if a property is missing.
7. QA on real devices (not just simulators)
   Test expanded notification layouts on multiple OS versions and devices. Confirm images load quickly and aren’t blocked by size/format constraints.

When Should You Use This Feature

Rich push is worth the extra setup when the notification can carry visual context that reduces friction and drives the next action. If you’re only sending generic promos, the lift is usually marginal; the win shows up when the push is tied to a shopper’s last intent.

• Cart abandonment (high intent): A shopper adds a skincare bundle to cart but drops at payment. A rich push 30–60 minutes later showing the exact hero image + “Complete checkout” tends to outperform a text-only reminder—assuming your added_to_cart payload includes the image URL and cart value.
• Back-in-stock / replenishment: For consumables (coffee, supplements), a rich push with the product image + one-tap deep link back to the PDP increases repeat purchase rate, especially for customers who reorder the same SKU.
• Reactivation via last browsed category: If someone viewed “running shorts” twice last week but never purchased, a rich push featuring a best-seller image from that category can bring them back—if your app tracks product_viewed consistently and you’ve stitched identity across sessions.

Operational Considerations

Once rich push is live, the operational work is keeping the data clean enough that segmentation and orchestration don’t drift over time. Most teams don’t fail on message creative—they fail on inconsistent IDs, missing properties, and event spam that wrecks targeting.

• Segmentation depends on event hygiene: If added_to_cart fires multiple times per button tap, you’ll over-trigger recovery flows and burn push permission faster than you think.
• Identity stitching rules need to be explicit: Decide what your “source of truth” identifier is (internal customer ID preferred). If you switch identifiers midstream (email → ID), you’ll create duplicates and your device tokens may attach to the wrong profile.
• Deep links are part of the retention system: Rich push without a clean deep link to cart/PDP is wasted. Make sure each push routes to the correct screen with enough context (cart_id, sku).
• Data flow latency matters for recovery: Cart recovery pushes are time-sensitive. If events arrive late (batching, offline queue), your “send after 30 minutes” becomes “send after 2 hours,” and performance drops.
• Frequency controls protect deliverability and opt-in: Rich push is more engaging, but it also accelerates fatigue. Use holdouts and per-user frequency rules tied to intent (cart > browse > promo).

Implementation Checklist

Before you scale rich push beyond a test cohort, lock down the basics so you’re not debugging production campaigns with revenue on the line.

• Customer.io mobile SDK installed and initializing correctly in each app environment
• Push permission prompt implemented with a value-first moment (not on first launch)
• APNs/FCM token successfully registered in Customer.io and visible on the person profile
• identify called on login/account creation using a stable identifier
• Core events tracked: product_viewed, added_to_cart, checkout_started, order_completed
• Event properties include what rich push needs (image_url, sku, deep_link, cart_id)
• Deep links route correctly to PDP/cart with context
• Tested rich push rendering on real devices + multiple OS versions
• Basic frequency caps and suppression rules in place (purchased users excluded from cart recovery)

Expert Implementation Tips

The best-performing rich push setups look boring on the surface: consistent IDs, predictable event schemas, and aggressive QA. The “secret sauce” is making sure the notification always matches the shopper’s last meaningful intent.

• Send the image URL from the source of truth: Don’t construct image URLs client-side if your CDN paths change. Pass a canonical URL from your product data layer.
• Use a single event schema across platforms: iOS and Android teams often name properties differently (productId vs sku). Normalize early or segmentation becomes a mess.
• Stitch before you trigger: If you run “added_to_cart → push” workflows, make sure the workflow references the identified profile when possible. Otherwise, guests who later log in won’t get coherent follow-ups.
• Personalize the CTA to the funnel step: For checkout_started, push “Finish checkout” to cart/checkout. For product_viewed, push “Still thinking about it?” to PDP. Same product, different intent.
• Hold out 5–10% from rich push: In Customer.io, keep a control group so you can prove lift vs plain push (or no push) instead of guessing.

Common Mistakes to Avoid

Most rich push failures aren’t dramatic—they’re small implementation gaps that quietly kill conversion or inflate sends. These are the ones we see repeatedly in D2C apps.

• Calling identify too late: If you only identify after purchase, your cart and browse behavior stays on an anonymous profile and your recovery flows underperform.
• Duplicate profiles from inconsistent identifiers: Logging in with email on iOS and customer_id on Android creates two people with two devices and half the history each.
• Missing or oversized media assets: Rich push images that are too large, slow, or blocked by auth headers will silently degrade to text-only.
• No suppression after purchase: If order_completed doesn’t arrive reliably, customers keep getting “complete your order” pushes after they already bought.
• Over-triggering from noisy events: Tracking added_to_cart on quantity change or cart open leads to spammy recovery sequences.

Summary

Rich push is a retention lever when your SDK setup reliably registers devices, stitches identity, and sends clean event payloads with media and deep links. If your data is inconsistent, rich push mostly amplifies the wrong message to the wrong audience.

Implement Rich Push with Propel

If you already run push in Customer.io, the fastest path to a lift is usually auditing identity stitching and event schemas before you touch creative. When you want a second set of operator eyes on your SDK tracking plan (guest → login merges, cart event timing, deep link routing), book a strategy call and we’ll map the exact instrumentation needed for cart recovery, repeat purchase, and reactivation.