Capture Push Metrics (SDK)

Overview

If you’re sending mobile push through Customer.io, capturing push metrics is what turns “we sent pushes” into “we can actually optimize revenue.” When push opens and delivery outcomes are reliably tracked, you can build tighter cart recovery and reactivation logic—and if you want a second set of eyes on your tracking plan, you can book a strategy call.

In most retention programs, push performance looks “fine” until you try to segment by engaged vs. unengaged devices and realize opens aren’t being recorded consistently. This is usually an SDK/identity stitching problem, not a creative problem.

How It Works

Push metrics are captured when your app SDK is correctly configured to (1) register a device token to the right person profile, and (2) report push interaction events back to Customer.io. The mechanics matter because Customer.io can only attribute delivery/open behavior to a person if the device is attached to that person at send time.

• Device registration: The SDK collects the APNs/FCM token and registers it with Customer.io. This is what makes the device “pushable.”
• Identity stitching: When a user logs in (or you otherwise know who they are), the app calls identify so the device token is associated with a known person, not an anonymous profile.
• Metric capture: The SDK listens for push lifecycle callbacks (delivered/received, opened, acted-on) and forwards those events to Customer.io so they appear in reporting and can be used for segmentation and orchestration.
• Where this tends to break in practice: teams register devices before calling identify, or they never re-identify after logout/login—so opens get attributed to an anonymous record and your “non-openers” segment becomes junk.

Step-by-Step Setup

The goal is simple: every pushable device must be tied to the correct Customer.io person, and every open needs to be recorded. Set this up once, then your cart recovery and winback flows stop guessing.

1. Install the Customer.io mobile SDK for your platform.
   Use the iOS/Android (or React Native/Flutter) SDK and confirm it initializes on app launch in your production build (not just debug).
2. Initialize the SDK as early as possible in app startup.
   Do this in AppDelegate/Application (or equivalent) so push callbacks are captured even if the app is opened from a notification.
3. Request push permission at the right moment.
   For D2C, asking right after a value moment (order tracking, back-in-stock, rewards) typically yields better opt-in than asking on first launch.
4. Register the device token with Customer.io.
   Make sure APNs/FCM token registration is wired to the SDK method Customer.io expects, and confirm you see the device under the person profile once identified.
5. Call identify immediately after login (and whenever the user becomes known).
   Pass a stable identifier (your internal customer ID or hashed email) and the key attributes you’ll use for retention segmentation (e.g., email, phone, first_order_date, loyalty_tier).
6. Handle logout explicitly.
   When a user logs out, reset/clear the identified profile in the SDK so the next user on the same device doesn’t inherit the wrong identity.
7. Enable push open tracking.
   Confirm your notification opened handler is wired so the SDK reports the open to Customer.io. Test by sending a push to a test device, tapping it, and verifying the open appears in Customer.io metrics/activity.
8. Validate end-to-end with a real scenario.
   Example: trigger a cart abandonment push, open it from the lock screen, land on the cart screen, and verify (a) open tracked, (b) user attributed correctly, (c) downstream “opened push” segments update.

When Should You Use This Feature

You’ll feel the impact of push metrics as soon as you start making decisions based on engagement—especially for D2C where push is often the fastest path back to checkout.

• Cart recovery with engagement-based branching: send push #2 only to people who didn’t open push #1, and escalate to SMS/email for chronic non-openers.
• Product drop / back-in-stock optimization: identify which customers consistently open push within 15 minutes, and prioritize them for limited inventory notifications.
• Reactivation: build winback segments like “no purchase in 60 days AND no push opens in 30 days” to avoid burning sends on dead devices.
• Post-purchase repeat purchase: measure which replenishment pushes actually get opened, then tune timing (e.g., day 21 vs day 28) based on open + conversion performance.

Operational Considerations

Once tracking is live, the operational work is keeping your segments and orchestration honest. Push metrics are only as useful as your identity and data flow discipline.

• Segmentation reality: create separate segments for push-enabled (has a valid device token) vs push-engaged (opened within X days). Don’t mix them.
• Multi-device users: decide how you want to treat customers with multiple devices. In practice, you’ll see “open” behavior skew toward one device—so measure at the person level, but sanity-check device counts.
• Anonymous-to-known stitching: if you let users browse anonymously, make sure you merge anonymous activity when they identify. Otherwise, your “opened push” and “viewed product” signals can live on different profiles.
• Orchestration across channels: use push opens as a throttle. Example: if someone opened a cart push in the last 2 hours, suppress the follow-up email to avoid double-tapping the same intent.
• Data latency: assume a small delay between an open and segment membership changes. Don’t build flows that require instant segmentation updates without a buffer.

Implementation Checklist

Before you scale sends, lock the basics. These are the checks that prevent “reporting looks weird” weeks later when you’re trying to diagnose a revenue dip.

• SDK initialized on app launch in production builds
• Push permission prompt implemented and tested
• APNs/FCM token successfully registered to Customer.io
• identify called after login with a stable customer identifier
• Logout/reset behavior implemented to prevent identity leakage
• Push open handler wired and verified (tap notification → open recorded)
• Test person profile shows device + push activity in Customer.io
• At least one segment built using push engagement (e.g., opened in last 7 days)

Expert Implementation Tips

These are the operator moves that keep push metrics clean enough to actually drive retention decisions.

• Identify early, identify often: if your app has “soft login” states (magic links, shop accounts, loyalty), call identify as soon as you can prove identity—not only after checkout.
• Instrument deep links as events: when a push opens to a PDP or cart, track an event like push_deeplink_opened with destination and campaign. Opens alone don’t tell you if the landing experience worked.
• Use engagement windows that match buying cycles: for fast-turn products, “opened in last 3–7 days” is meaningful. For replenishment, “opened in last 21–30 days” is often more predictive.
• Build a ‘dead token’ cleanup loop: if you see repeated delivery failures, suppress those devices or re-prompt permissions in-app. This keeps your push-enabled counts honest.

Common Mistakes to Avoid

Most push metric issues aren’t complicated—they’re just easy to miss when you’re moving fast on launches.

• Registering device tokens before identity is known—and never re-linking them: you end up with opens on anonymous profiles and broken engagement segments.
• Not handling logout: shared devices (or even just account switching) will corrupt attribution and make “opened push” look higher than reality for the wrong customer.
• Assuming “delivered” equals “seen”: delivery metrics help diagnose reach, but open/intent signals should drive orchestration decisions.
• Using push opens as a conversion proxy without a holdout: engaged users open more and buy more anyway. Use holdouts or compare against matched cohorts when you’re making budget/channel calls.
• Skipping real-device QA: simulators and staging builds won’t catch the edge cases around notification taps, cold starts, and permission states.

Summary

If push metrics aren’t captured cleanly, you can’t trust engagement segments—and your cart recovery and winback flows will over-send or misfire. Get device registration + identity stitching right, verify opens end-to-end, then use engagement windows to drive channel escalation and suppression.

Implement Push Metrics with Propel

If you’re already sending push through Customer.io, the fastest win is usually tightening identity stitching and turning push opens into suppression/escalation logic across email and SMS. If you want help pressure-testing your SDK tracking plan against your retention roadmap, you can book a strategy call—we’ll focus on what’s most likely to move repeat purchase and reactivation, not just “getting data in.”