Capture Push Metrics (Mobile SDK) for Retention Performance in Customer.io

Overview

If you’re sending mobile push through Customer.io, capturing push metrics is what turns “we sent it” into “we can optimize it.” It’s the difference between guessing why your cart recovery push isn’t converting and actually seeing delivery, opens, and engagement so you can tune timing, frequency, and follow-ups. If you want a second set of eyes on your tracking plan before you scale spend or promos, book a strategy call.

In most retention programs, push is the fastest lever for repeat purchase and reactivation—but it breaks down quickly when metrics aren’t wired correctly. You end up suppressing the wrong people, double-touching users who never received anything, or optimizing creative based on clicks that were never attributed.

How It Works

Push metrics in Customer.io are captured on the app side via the mobile SDK. The SDK listens for push lifecycle events (delivery/display, open/tap, and related notification interactions) and reports them back to Customer.io so your reporting and Journeys reflect what actually happened on-device.

• Device registration is the foundation: the SDK must register the device push token and associate it to the right person profile. If identity stitching is off, metrics will land on the wrong profile (or an anonymous one) and your suppression/targeting logic will drift.
• SDK emits push engagement signals: when a push is received/displayed and when a user opens/taps it, the SDK reports those events back to Customer.io. That’s what powers message-level metrics and lets you build segments like “received but didn’t open.”
• Identity stitching matters more than people think: for D2C, a common path is browse anonymously → add to cart → install/open app → login at checkout. If you don’t identify at the right moment (and merge anonymous activity where relevant), push metrics won’t connect to the revenue event you care about.

Real scenario: A skincare brand runs a cart recovery push 30 minutes after abandon. Without push metrics, they send an email follow-up to everyone who “didn’t convert.” With push metrics captured, they can suppress anyone who never received the push (bad token), resend to a clean device segment, and only email the users who received but didn’t open—tightening pressure while improving recovery rate.

Step-by-Step Setup

The cleanest implementations treat push metrics capture as part of your identity + event instrumentation plan, not a standalone toggle. Set it up once, validate it in logs, and then build retention orchestration on top of it.

1. Install the Customer.io mobile SDK
   • Add the SDK to your iOS/Android app (or your wrapper like React Native/Flutter).
   • Initialize the SDK as early as practical in the app lifecycle so it can capture notification opens reliably (cold start is where teams lose attribution).
2. Configure push permissions + token registration
   • Request notification permission at a moment that makes sense for conversion (post-value, not on first launch for most D2C apps).
   • Ensure the SDK receives and registers the APNs/FCM token with Customer.io.
   • Confirm token updates are handled (tokens rotate; if you don’t update, delivery drops silently).
3. Identify users at the right time (and keep it consistent)
   • Call identify when you have a stable user identifier (login, account creation, or checkout).
   • Pass key attributes you’ll segment on operationally: email, phone (if applicable), customer_id, first_order_date, last_order_date, lifetime_value, opt_in_push.
   • If your app supports guest checkout → account later, plan how you merge/alias identities so push engagement doesn’t fragment across profiles.
4. Enable/verify push metric capture in the SDK
   • Confirm the SDK is set to capture push interactions (open/tap) and any delivery/display signals supported in your setup.
   • Test with a real device (not only simulator) and validate events show up in Customer.io message activity.
5. Validate end-to-end with a retention flow test
   • Trigger a known push (e.g., a test broadcast) to your device.
   • Confirm: sent → delivered/received (where available) → opened is reflected in Customer.io.
   • Then complete a downstream event (e.g., order_completed) and ensure attribution/segmentation behaves how your Journeys expect.

When Should You Use This Feature

If push is part of your retention mix, you want push metrics captured before you start “optimizing.” Otherwise you’ll optimize on noise and your holdouts will lie to you.

• Cart recovery orchestration: resend to “delivered but not opened,” and route “not delivered” users into email/SMS fallback faster.
• Repeat purchase nudges: time replenishment pushes based on actual opens (e.g., only send the second reminder if the first was opened but no reorder happened).
• Winback/reactivation: build a clean segment of “push reachable” dormant users vs. “unreachable” so you don’t burn frequency caps on dead tokens.
• Creative + timing tests that matter: run A/B tests where the primary KPI is push open rate (or push-assisted conversion), not just sends.

Operational Considerations

Once metrics flow, the real work is making them usable in segmentation and Journeys without creating a mess of edge cases. This is where most teams get 80% of the way there and then wonder why performance plateaus.

• Segmentation:
  • Create segments around reachability (has valid device token, opted in) vs. engagement (opened push in last X days).
  • For D2C, also segment by lifecycle: first-time buyer vs. repeat vs. lapsed—push behavior differs dramatically across these groups.
• Data flow realities:
  • Push opens can arrive late (offline opens, delayed app start). Don’t chain ultra-tight “if opened within 2 minutes then…” logic unless you’ve validated latency.
  • Token churn is real. Plan for token refresh and uninstall behavior so your “push reachable” audience doesn’t rot.
• Orchestration:
  • Use push metrics to drive channel fallback: if not delivered, go email/SMS; if delivered but not opened, adjust copy or timing; if opened but no purchase, follow with product-specific content.
  • Set frequency rules that respect engagement: heavy senders should be limited to engaged users, not your entire reachable base.

Implementation Checklist

Before you rely on push metrics for suppression, resend logic, or holdouts, run through this checklist and confirm it on real devices across iOS and Android.

• Mobile SDK installed and initialized early enough to capture notification opens on cold start
• Push permission prompt implemented thoughtfully (and opt_in_push captured as an attribute)
• APNs/FCM tokens registered and updated when rotated
• identify called with a stable user ID at login/checkout (not only on install)
• Anonymous-to-known stitching plan documented (guest → account, multiple devices, etc.)
• Test push sent to device and open reflected in Customer.io activity
• At least one Journey uses push metrics for a real decision (fallback, suppression, resend)

Expert Implementation Tips

These are the small operator moves that typically unlock cleaner reporting and better automation decisions once volume ramps.

• Instrument “push reachable” as a first-class concept: don’t rely only on “has device.” Track a boolean like push_opt_in=true and a timestamp like push_opt_in_at so you can exclude users who churned permissions.
• Use opens to control pressure: in practice, sending more to non-openers rarely fixes performance. Instead, cap frequency for non-openers and put them into email-first or content-first tracks.
• Validate identity on multi-device users: if a customer logs in on iPad and iPhone, make sure both tokens attach to the same profile so metrics and reachability don’t split.
• Build a “delivery gap” monitor: if sends stay flat but deliveries drop, you likely have token refresh issues or permission churn. Catch it before your revenue dips.

Common Mistakes to Avoid

Most push metric issues aren’t “Customer.io problems”—they’re SDK lifecycle and identity problems that show up as bad segments and misleading tests.

• Calling identify too late: if you only identify after purchase, your cart recovery and browse pushes will attach to anonymous profiles and your reporting won’t tie out.
• Testing only on warm app opens: cold start from a notification is where opens often fail to attribute if initialization is late.
• Assuming “sent” equals “delivered”: if you don’t use delivery/receipt signals where available, you’ll over-email/SMS people who never got the push.
• Letting tokens go stale: not handling token refresh quietly kills reach over time and makes reactivation look “worse than it is.”
• Over-branching Journeys on real-time opens: push engagement data can be delayed; keep logic resilient with reasonable wait windows.

Summary

If push is a meaningful retention channel for your brand, capturing push metrics via the mobile SDK is non-negotiable. It’s what makes cart recovery and winback orchestration accurate, and it prevents you from optimizing creative and timing on misleading data.

Implement it when you’re ready to use delivery/open behavior to drive segmentation, suppression, and channel fallback—not just reporting.

Implement Push Metrics with Propel

If you’re already running push in Customer.io, the fastest win is usually tightening identity stitching and making push metrics actionable inside Journeys (fallbacks, resend logic, frequency rules). When you want to sanity-check your SDK instrumentation and the segments it feeds, book a strategy call and we’ll map the tracking to the retention outcomes you’re actually trying to drive.