Capture Push Metrics (SDK) in Customer.io

Overview

If you’re running mobile push as a real retention channel (not just “nice to have”), you need clean delivery + open signals inside Customer.io—otherwise you’ll optimize creative and timing off guesswork. Capturing push metrics properly is one of those setups that looks “done” in a sprint, then quietly breaks identity stitching or attribution until someone audits it; if you want a second set of eyes on the full retention instrumentation, book a strategy call.

In practice, push metrics become the backbone for suppressions (don’t keep hammering unreachables), journey branching (openers vs non-openers), and measuring true incremental lift on cart recovery and repeat purchase.

How It Works

Customer.io’s mobile SDKs capture push performance by tying three things together: the device token (who can receive), the push send (what was sent), and the user interaction (did they open/tap). When those signals are wired correctly, Customer.io can report delivery/open outcomes and you can use those outcomes to drive orchestration decisions in campaigns.

• Device registration: your app collects the APNs/FCM token and registers it to the right Customer.io person profile. This is where identity stitching either works or quietly fails.
• Send attribution: when Customer.io sends a push, it includes identifiers so the SDK can attribute an open back to the specific message/campaign.
• Open tracking: when a user taps the notification, the SDK reports the open event back to Customer.io (and can also pass deep link context so you can measure downstream conversion).
• Metrics become operational signals: you can segment on reachability/engagement and branch journeys based on “received/opened” behavior rather than assuming delivery.

D2C scenario: You run a cart abandonment push 30 minutes after abandon. Without push metrics, you’ll keep sending to users whose tokens expired after reinstall, and you’ll misread “push doesn’t work” when the real issue is deliverability. With push metrics captured, you can suppress unreachable devices, resend via email/SMS when push fails, and isolate creative tests to users who actually received the message.

Step-by-Step Setup

The goal here is simple: make sure every device token is attached to the correct person, and every notification open is attributed to the correct send. Do this once, then QA it whenever you ship changes to auth, onboarding, or push handling.

1. Install the Customer.io mobile SDK Add the SDK for your platform (iOS/Android/React Native/etc.) and confirm it initializes on app launch. Most retention programs we’ve seen run into “missing opens” because initialization happens too late (after the app handles the notification intent).
2. Identify the user as soon as you have a stable customer ID Call the SDK identify method immediately after login/account creation (and again after token refresh if your auth flow changes). Use a durable ID (your internal customer ID), not an email that can change. This is the key step for identity stitching between anonymous app activity and known customer profiles.
3. Register the push token to the identified profile On iOS, capture the APNs token; on Android, capture the FCM token. Pass it to the Customer.io SDK so the token is stored against the right person. If you register tokens before identify, make sure you support merging from anonymous to identified—otherwise you’ll end up with “ghost devices” that never match your real customers.
4. Enable push open tracking in your notification handlers Wire the SDK into your notification open/click handler so the SDK can report the open event when the user taps. This is where many teams break attribution by handling the tap themselves (deep link routing) but never calling the SDK hook.
5. Pass deep link context for conversion measurement If your push routes to PDP/cart/checkout, include campaign context in the deep link (or preserve the payload) so you can track downstream events like Viewed Product, Started Checkout, Placed Order with a clear “came from push” signal.
6. QA in a real device flow (not just simulator logs) Send a test push to a real device, tap it, and confirm: (1) the device is attached to the expected person in Customer.io, (2) the message shows an open, and (3) your downstream purchase events still fire with the same person ID.

When Should You Use This Feature

Push metrics matter anytime you’re making decisions based on whether push “worked.” If you’re sending push but not capturing opens/delivery cleanly, you’re basically flying blind on one of your fastest feedback channels.

• Cart recovery: branch based on “opened push” vs “didn’t open” and escalate to email/SMS only when needed.
• Repeat purchase loops: measure which replenishment nudges actually get opened, then tune timing by product category (e.g., skincare vs supplements).
• Reactivation: suppress users who are no longer reachable by push and shift budget to email/SMS or paid retargeting audiences.
• Winback offer governance: only show the strongest incentive to users who received but ignored prior pushes (not to people who never got them).

Operational Considerations

Once metrics flow, the real work is operational: how you segment, how you avoid identity drift, and how you design fallbacks when push can’t reach someone.

• Segmentation: build segments like “Push reachable (token present)”, “No push token”, “Opened a push in last 30 days”, and “Delivered but never opened.” These become your routing rules for cart recovery and reactivation.
• Identity stitching realities: if your app supports guest checkout, social login, or account merging, audit how/when you call identify. In practice, most attribution issues come from identify happening after token registration or from changing identifiers (email-based IDs).
• Data flow timing: push opens often happen on cold start. If SDK initialization or identify happens after your router runs, the open can be lost or attributed anonymously.
• Orchestration: don’t treat push as a single lane. Use push metrics to decide when to stop, when to resend, and when to escalate to other channels—especially in high-intent moments like cart and browse abandonment.

Implementation Checklist

If you want this to stay working through app releases, treat it like a checklist you re-verify whenever you touch auth, onboarding, push providers, or deep linking.

• SDK initializes on app launch (before notification open handling).
• Identify uses a durable customer ID and fires immediately after login/account creation.
• APNs/FCM token is captured and registered to the identified person.
• Anonymous-to-known merge behavior is validated (guest → logged-in).
• Notification open handler calls the Customer.io SDK hook for attribution.
• Deep link/payload preserves campaign context for downstream conversion events.
• Real-device QA confirms message open metrics appear in Customer.io.
• Segments exist for reachable/unreachable and engaged/unengaged push audiences.

Expert Implementation Tips

These are the small operator moves that keep push reporting trustworthy and make your journeys perform better week over week.

• Use push metrics to control pressure: if a user hasn’t opened the last N pushes, slow down cadence or switch to email—otherwise you train them to ignore you and you burn deliverability at the OS level.
• Create a “push fallback” branch in cart recovery: if no token (or repeated non-delivery), skip push entirely and go straight to email/SMS within the same workflow.
• Track a dedicated “Push Opened” event alongside SDK metrics: keep the SDK attribution, but also fire your own event with key properties (screen routed to, product_id, cart_value). This makes analysis and segmentation easier without relying on message logs alone.
• Audit token churn after app releases: sudden drops in reachability usually mean token registration broke or identify moved later in the lifecycle.

Common Mistakes to Avoid

Most push “underperformance” stories are actually tracking and identity problems. Fix these and your tests start making sense again.

• Registering tokens before identify and never merging: leads to devices attached to anonymous profiles, so your real customers look unreachable.
• Using email as the primary identifier: breaks stitching when a customer updates email, uses Apple Hide My Email, or checks out with a different address.
• Handling notification taps without calling the SDK hook: opens don’t get attributed, so you can’t branch journeys correctly.
• Relying on simulator-only QA: simulators don’t replicate real push delivery/open behavior reliably—always validate on physical devices.
• No segmentation for reachability: you keep sending to dead tokens, inflate “sent” counts, and misread performance.

Summary

If push is part of your retention mix, capturing push metrics is non-negotiable. Get identity + token registration right, wire open tracking into your handlers, then use those metrics to drive suppression and channel fallbacks. Once it’s clean, cart recovery and winback flows get measurably tighter.

Implement Push Metrics with Propel

If you’re already sending push in Customer.io, the fastest win is usually an instrumentation audit: confirm identify timing, token registration, and open attribution, then rebuild your cart/reactivation routing around reachable vs engaged segments. If you want help pressure-testing the setup and turning the metrics into operational branching rules, book a strategy call.