Capture Push Metrics (SDK) in Customer.io

Overview

If you’re sending mobile push and not capturing the right metrics, you’re basically flying blind on what actually drives repeat purchases and reactivation. With Customer.io, push metrics become reliable when the SDK is installed correctly, the device is attached to the right person, and opens are tracked consistently—otherwise your “push works” story usually collapses under attribution and duplicate-profile issues.

If you want a second set of eyes on your tracking and identity stitching before you scale spend or increase push volume, book a strategy call—most retention programs we’ve seen get a measurable lift just by fixing instrumentation and audience logic.

How It Works

Push metrics in Customer.io are only as good as your app-side signals. In practice, the SDK is doing three jobs: registering the device for push, tying that device to a known user (identity stitching), and reporting what happened after a push was sent (delivery/open/influence depending on your setup).

• Device registration: your app collects the push token (APNs on iOS, FCM on Android) and passes it to Customer.io via the SDK. That’s what makes the device addressable.
• Identity stitching: when a user logs in (or you otherwise know who they are), you call identify so Customer.io can associate the device with the correct person profile. This is the step that prevents “push metrics look fine but revenue attribution is nonsense.”
• Open tracking: when a notification is tapped, the SDK should report the open. If this breaks, you’ll still send push—but you’ll optimize on bad data (and your holdouts/A-B tests won’t be trustworthy).
• Metric availability: once events are flowing, Customer.io can report push performance at the message/campaign level and you can segment users based on engagement (opened push recently, never opened, etc.).

Step-by-Step Setup

The goal here is simple: make sure every push-able device is registered, every device is attached to the right user, and every tap is counted. Do this once, and your cart recovery + reactivation workflows stop guessing.

1. Install the Customer.io mobile SDK (iOS/Android/React Native/Flutter depending on your app).
   • Use the official Customer.io Mobile SDK for your platform and confirm it’s initialized on app start.
   • Make sure you’re using the same workspace/site configuration across environments (it’s easy to accidentally point staging builds at prod or vice versa).
2. Enable push notifications in your app and obtain a valid device token.
   • iOS: configure APNs, request permission, and capture the APNs device token.
   • Android: configure Firebase Cloud Messaging and capture the FCM token.
3. Register the device token with Customer.io via the SDK.
   • Confirm the SDK is receiving token updates (tokens can rotate; treat this as a recurring update, not a one-time setup).
   • Verify the device shows up on the person profile in Customer.io once the user is known.
4. Call identify at the right moment (usually immediately after login/registration).
   • Send a stable identifier (e.g., your internal customer ID) rather than email as the primary ID if you can.
   • Attach key attributes that matter for retention segmentation (e.g., first_order_date, last_order_date, vip_tier, sms_opt_in).
5. Track push opens (tap-through) in your notification handler.
   • Confirm that tapping a notification triggers the SDK open event consistently, including cold start scenarios (app fully closed).
   • Test deep links: if you route users to PDP/cart, make sure the open is still recorded even if the deep link routing code runs first.
6. QA in Customer.io before you build journeys on top.
   • Send a test push to a known internal user, tap it, and confirm the open shows up in activity.
   • Check that the device is attached to the correct profile (no duplicates) and that events land under the expected person.

When Should You Use This Feature

Capturing push metrics matters most when push is part of your revenue engine—meaning you’re using it for recovery, repeat purchase nudges, and winback. If you can’t trust opens and device identity, you’ll over-message the wrong people and under-invest in what’s actually working.

• Cart recovery on mobile-first brands: someone adds to cart in-app, bounces, and you send a push 30–60 minutes later. Push metrics tell you whether the message was opened—and lets you suppress follow-up SMS/email if they already came back.
• Post-purchase replenishment: for consumables, push is often the cheapest “nudge” channel. You’ll want segments like “opened a push in the last 14 days” to decide who gets push-first vs email-first.
• Reactivation: “no purchase in 60 days” is blunt. “no purchase in 60 days AND hasn’t opened push in 30 days” is actionable—different creative, different channel priority.
• Offer testing and holdouts: if you run A/B tests in Customer.io, push-open tracking is the difference between learning and guessing.

Operational Considerations

This is where teams usually get tripped up: the instrumentation is “installed,” but the data doesn’t line up with how retention actually operates. You want clean segmentation inputs, predictable data flow, and orchestration rules that prevent channel pileups.

• Segmentation depends on identity quality: if users browse anonymously and only log in at checkout, you’ll see devices floating around without a real customer attached. Plan for identity stitching at login and consider how you merge anonymous activity if you rely on it.
• Token churn is real: tokens rotate; users reinstall; permissions change. Make sure your app updates tokens and your Customer.io device list stays fresh, or deliverability and metrics will degrade quietly over time.
• Orchestration across channels: decide how push metrics influence other sends. Example: if a user opens a cart push, suppress the next email step for 4–6 hours and wait for purchase or product view events instead.
• Attribution expectations: push opens are a strong engagement signal, but not every purchase will be a direct click. In most retention programs, we’ve seen better decisions come from combining push metrics with onsite/app events (viewed product, started checkout, purchased) rather than trying to force last-click logic.

Implementation Checklist

If you want this to hold up when you scale sends, treat this as a launch gate. Most “push underperforms” diagnoses end up being one of these items.

• SDK installed and initialized on app start (iOS/Android)
• Push permissions requested and handled correctly (including denied state)
• APNs/FCM token captured and sent to Customer.io
• identify called immediately after login/registration with a stable customer ID
• Push open tracking confirmed for warm and cold starts
• Deep links tested (PDP, cart, collection) without breaking open tracking
• Internal QA user profile shows device attached + open events in activity
• Segments created for “opened push in last X days” and “never opened push”

Expert Implementation Tips

Once the basics are in, a few operator moves make push metrics far more useful for retention decisions—especially when you’re trying to protect margin and reduce message fatigue.

• Use push engagement as a channel selector: route “push-engaged” users into push-first flows, and send email/SMS first to users who never open push. This usually improves recovery without increasing volume.
• Build a “permission + engagement” matrix: permission granted isn’t the same as responsive. Segment by (a) has push token, (b) opened push in last 30 days, (c) purchased in last 60 days. That’s your real targeting grid.
• Instrument key commerce events in the app: push metrics tell you opens; retention needs outcomes. Track product_viewed, added_to_cart, checkout_started, order_completed with consistent IDs so you can connect push engagement to revenue behavior.
• Guardrails for cart recovery: if the user returns to the app (session start) after the push send, suppress the “second nudge.” In practice, this reduces annoyance without hurting conversion.

Common Mistakes to Avoid

These are the failure modes that create misleading dashboards and wasted iteration cycles. Fixing them is usually a bigger win than rewriting copy.

• Calling identify too late: if you only identify after purchase, all your pre-purchase push engagement sits on an anonymous or wrong profile.
• Using unstable identifiers: using email as the primary ID when users change email (or check out with different emails) creates duplicates and splits metrics.
• Not handling cold start opens: teams test taps when the app is already open and assume it’s fine. Then production opens undercount because many taps happen from a closed app.
• Assuming token = reachable: users can disable notifications at OS level. If you don’t track permission state (where possible) and engagement recency, you’ll over-target dead devices.
• Optimizing on opens alone: opens are useful, but retention decisions should tie back to commerce events—especially for promos where open rate can look great and margin impact is negative.

Summary

If push is part of your retention mix, capturing push metrics via the SDK is non-negotiable. Get device registration, identity stitching, and open tracking right, then use engagement segments to drive smarter orchestration across push/email/SMS.

Implement Push Metrics with Propel

If you’re already running Customer.io and want push metrics you can actually make decisions from, the fastest path is usually a quick audit of SDK identity stitching, token hygiene, and open tracking—then we map those signals into your cart recovery and winback orchestration. If that’s useful, book a strategy call and we’ll pressure-test your current setup against how D2C retention programs tend to break in production.