Capture Push Metrics (SDK) in Customer.io

Overview

If you’re running mobile push through Customer.io, push metrics are only as good as the tracking you wire up in your app. When teams complain that “push doesn’t work,” it’s usually not the creative—it’s missing delivery/open signals, broken identity stitching, or events firing against the wrong profile. If you want a second set of eyes on your instrumentation before you scale campaigns, book a strategy call and we’ll pressure-test it like an operator would.

Capturing push metrics cleanly gives you three practical wins in retention: (1) reliable delivery vs. open rate trends (so you can spot token/permission decay), (2) segmentation you can actually trust (recent openers vs. silent devices), and (3) tighter attribution for cart recovery and repeat purchase flows.

How It Works

In practice, push metrics come from a handshake between your app and Customer.io: the SDK registers the device token, ties that device to a known person when you identify them, and then reports engagement events (like opens) back to Customer.io. Customer.io can only attribute a push open to the right customer if the device is registered and the identity on that device is stitched correctly.

• Device registration: the SDK collects the push token (APNs on iOS, FCM on Android) and registers it with Customer.io so messages can be delivered to that device.
• Identity stitching: once a user logs in (or you otherwise know who they are), your app calls identify so the device token and future push metrics attach to the correct Customer.io person profile.
• Engagement tracking: when the user opens a notification (or interacts with it), the SDK reports that interaction back to Customer.io so opens and downstream performance reflect reality.
• Downstream orchestration: those metrics become segment conditions and trigger/exit logic in Journeys—e.g., suppress customers who already opened the push, or route “didn’t open” into SMS/email fallback.

Where this tends to break: the app registers tokens before login but never re-identifies after login, users get merged/duplicated, or opens are tracked but attributed to an anonymous profile that never gets merged.

Step-by-Step Setup

Before you touch campaigns, get the tracking right in the app. You’re aiming for one clean path: install SDK → register token → identify user → track opens → verify in Customer.io activity logs.

1. Install the Customer.io Mobile SDK for your platform
   Add the iOS/Android (or React Native/Flutter) SDK to your app and confirm the SDK initializes on app launch. Don’t ship this half-wired—if initialization is flaky, your metrics will be noisy forever.
2. Enable push permissions and capture the device token
   Request notification permission (iOS) and ensure FCM/APNs token generation works. Your goal is to reliably obtain a valid token and hand it to the SDK for registration.
3. Register the token with Customer.io
   Make sure the SDK is actually registering the token (and refreshing it when it rotates). Token rotation is a silent killer of delivery rates if you don’t handle updates.
4. Call identify immediately after login (and whenever the user identity changes)
   This is the retention operator’s non-negotiable. If a user browses anonymously, then logs in, you need to stitch that device to the logged-in profile so push opens and conversions land on the right person.
5. Track push opens (and action taps if you use them)
   Confirm the SDK is reporting notification opens back to Customer.io. If you use deep links or notification actions (e.g., “Resume checkout”), ensure those interactions are tracked consistently.
6. Validate in Customer.io with real devices
   Send a test push to a known internal user, open it, and confirm the person’s activity shows the expected push metrics. Do this on iOS and Android—platform differences matter.
7. Verify attribution against a retention event
   Run a simple scenario: push → open → view product → add to cart. Make sure the open and the commerce events show on the same profile. If they don’t, fix identity stitching before you build journeys.

When Should You Use This Feature

Push metrics aren’t “nice to have” once you’re using push as a real retention channel. You need them any time you’re making decisions based on engagement, suppressions, or fallback routing.

• Cart recovery on mobile: send a push 30 minutes after abandonment, then branch based on opened push vs didn’t open. Without open tracking, you’ll spam people who already came back.
• Repeat purchase nudges: for consumables (supplements, skincare, coffee), target customers who opened a push in the last 14 days with replenishment reminders, and route non-openers into email instead.
• Reactivation: build a “silent app users” segment—installed + opted-in but no push opens in 30 days—and test a lighter cadence or different value prop before you give up and move them to paid retargeting.
• Deliverability and permission decay monitoring: if delivery drops, you can separate token/permission issues from creative fatigue.

Real D2C scenario: A apparel brand runs a 2-step cart recovery: Push at 30 minutes, email at 4 hours. After wiring push open tracking correctly, they suppress the email for customers who opened the push and returned to the app—email volume drops, conversion rate holds, and unsubscribes improve because you stop double-tapping the same intent.

Operational Considerations

Once metrics flow, the real work is using them without breaking your segmentation or creating attribution confusion across channels.

• Segmentation hygiene: define engagement windows that match buying cycles (e.g., “opened push in last 7 days” for fast-fashion drops vs. 30 days for higher-consideration categories). Avoid “ever opened” segments—they get stale fast.
• Identity and duplicates: if your app supports guest checkout + later account creation, plan for merging. In most retention programs, we’ve seen push metrics get stranded on anonymous profiles unless the identify/merge path is deliberate.
• Token lifecycle reality: tokens rotate, users reinstall, permissions change. Expect delivery to drift unless your app updates tokens and your segments account for recent device activity.
• Cross-channel orchestration: decide what a push open means operationally. Common pattern: open = suppress email/SMS for 12–24 hours; no open = escalate to the next channel. If you don’t codify this, teams end up “sending everything to everyone.”
• Attribution vs. causation: push opens are directional, not perfect proof. Use them for routing and suppression, then measure incremental lift with holdouts where it matters.

Implementation Checklist

If you want push metrics you can trust in reporting and segmentation, this is the minimum bar we hold teams to before scaling volume.

• SDK initializes reliably on app start (iOS + Android)
• Push permission prompt implemented and tracked (optional but recommended)
• Device token captured and registered with Customer.io
• Token refresh handled (rotation / reinstall)
• identify called immediately after login and on account switch
• Notification opens tracked and visible on the correct person profile
• Deep link / action tap behavior tested end-to-end
• Test journey built to branch on open vs not open (to validate segmentation)

Expert Implementation Tips

The difference between “we have push metrics” and “push is a reliable retention lever” is usually a handful of details teams skip when they’re rushing.

• Instrument a “push opt-in status” attribute: store whether the user is opted-in, denied, or not yet prompted. It makes your targeting cleaner than guessing from delivery failures.
• Re-identify on app resume after login: if your session/auth can change without a full app restart, make sure identity doesn’t drift. This is a common source of misattributed opens.
• Use push engagement as a throttle: cap push frequency harder for non-openers. In practice, disengaged devices are where you burn permission rates fastest.
• QA with two accounts on one device: log out/in with different users and confirm metrics attach to the right profile. If this fails, your whole program will have ghost data.

Common Mistakes to Avoid

Most “push performance” problems are tracking problems wearing a creative costume. These are the ones we see repeatedly in D2C mobile programs.

• Only registering the token once: tokens change. If you don’t update them, delivery drops and you’ll blame content.
• Delaying identify until later in the session: any opens/events before identify may land on an anonymous profile and never merge cleanly.
• Building journeys before validating device-level tracking: you’ll end up with broken branches (“didn’t open”) that are really “we didn’t track the open.”
• Using open rate as the only success metric: optimize for downstream behavior (return to app, view product, checkout start, purchase), and use opens mainly for routing/suppression.
• Not accounting for platform differences: iOS and Android handle permissions, delivery, and notification presentation differently—test both.

Summary

If push is part of your retention mix, capturing push metrics via the SDK is foundational—not optional. Get device registration and identity stitching right, then use opens for suppression and channel routing. Once that’s stable, you can actually trust what Customer.io reports and scale without guessing.

Implement Push Metrics with Propel

If you’re already sending push in Customer.io, the fastest win is usually tightening the app-side tracking so your segments and fallbacks behave the way you think they do. If you want help auditing SDK events, identity stitching, and the “open → suppress/escalate” logic inside Journeys, book a strategy call and we’ll map the exact instrumentation and routing needed for your retention program.