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

Overview

If you’re sending mobile push through Customer.io, capturing push metrics is what turns “we sent a push” into “we know what actually happened”—delivered, opened, and whether it drove revenue. If you want help pressure-testing your tracking plan before you scale sends, book a strategy call and we’ll walk through the identity + event model with you.

In most retention programs, push underperforms not because of creative, but because teams can’t trust the measurement. The fix is almost always app-side: clean device registration, consistent identify calls, and a small set of events that let Customer.io attribute opens and downstream behavior correctly.

How It Works

Push metrics are only as good as the SDK signals you send from the app. Customer.io’s mobile SDKs register devices, associate them to a person profile, and report push interactions (like opens) back to Customer.io so you can segment, suppress, and optimize based on real engagement.

• Device registration: The SDK captures the push token (APNs/FCM) and registers the device in Customer.io. This is what makes a user “push addressable.”
• Identity stitching: When you call identify() after login (or when you can confidently tie the device to a known shopper), Customer.io links the device to that person. This is the difference between “anonymous device got a push” and “Emily got a push.”
• Delivery + open tracking: The SDK and OS callbacks report notification interactions (open/tap) so Customer.io can attribute opens to the message/campaign.
• Downstream conversion tracking: Customer.io won’t magically know a push caused a purchase unless your app fires the right events (e.g., Checkout Started, Order Completed) after the open—ideally with order value and product context.

Practical D2C scenario: you run a cart recovery push 45 minutes after abandonment. Without SDK open tracking, you’ll over-credit “delivered” as success. With opens + purchase events, you can split audiences into (a) delivered-not-opened (creative/timing problem) vs (b) opened-no-purchase (landing/deeplink/offer problem) and fix the right lever.

Step-by-Step Setup

Do this in the app first, then validate inside Customer.io. Most teams try to “set up reporting” in the UI, but push metrics start with correct SDK wiring and identity discipline.

1. Install the Customer.io mobile SDK for your platform.
   Add the iOS/Android (or React Native/Flutter) SDK, and confirm the app builds cleanly with the push module enabled.
2. Enable push notifications in the app and obtain a device token.
   On iOS, request notification permissions and capture the APNs token. On Android, ensure FCM is configured and you can retrieve the FCM token.
3. Register the device token with Customer.io as soon as you have it.
   Do this on first app open after permission is granted, and again whenever the token rotates (it will). Token churn is a silent killer of deliverability and metrics.
4. Call identify() immediately after login (and whenever the user becomes known).
   Use a stable identifier (your internal customer id is best; email is acceptable if it’s guaranteed unique). This is the step that stitches the device to the person profile so push engagement rolls up correctly.
5. Track core commerce events from the app.
   At minimum: Product Viewed, Added to Cart, Checkout Started, Order Completed. Include properties like sku, category, price, order_id, and revenue.
6. Handle notification opens and deep links.
   Confirm that tapping a push routes the user to the intended screen (cart, PDP, collection). If the OS opens the app but you drop the deep link, you’ll see “opens” with weak conversion and assume the offer is the issue.
7. QA in Customer.io with a real device.
   Send a test push, tap it, and verify you see the open event/metric tied to the right person. Then complete a test purchase and confirm the order event lands after the open.

When Should You Use This Feature

Capturing push metrics matters any time push is part of your revenue engine, not just a “nice to have” channel. If you’re making decisions on frequency, offer strategy, or spend allocation without reliable push engagement data, you’ll optimize the wrong thing.

• Cart recovery: Separate “didn’t open” from “opened but didn’t convert” so you can adjust timing/creative vs landing/offer.
• Repeat purchase loops: Measure whether replenishment pushes actually get opened and lead to a reorder event (not just sessions).
• Reactivation: Identify sleepers who still receive pushes but never open, and shift them to email/SMS or reduce frequency to protect deliverability and brand fatigue.
• Product drops and back-in-stock: Validate whether your “hype” pushes drive PDP views and add-to-carts, and which segments respond fastest.

Operational Considerations

Once the SDK is wired, the real work is making sure data stays clean as your app, attribution, and segmentation evolve. In practice, this tends to break when identity rules change (guest checkout, new login methods) or when multiple systems emit similar events with different schemas.

• Segmentation depends on identity hygiene: If users browse anonymously and later log in, make sure you stitch pre-login activity to the known profile (or you’ll undercount “push influenced” conversions for high-intent shoppers).
• Data flow timing: Push open happens immediately, but purchase events might come minutes later. Build attribution windows in your analysis and avoid “same-session only” assumptions.
• Orchestration reality: If you also send email/SMS, decide how push engagement affects suppression. Example: if a user opens a cart push, suppress the cart email for 2–4 hours to avoid over-messaging.
• Event deduplication: If your backend and app both send Order Completed, you’ll inflate conversion metrics. Pick one source of truth and enforce it.
• Token churn + uninstall blind spots: Delivery failures often look like “low engagement.” Monitor token refresh handling and keep your device list current.

Implementation Checklist

If you want push metrics you can actually act on, treat this like a small instrumentation project—not a messaging toggle. This checklist is the minimum bar before you start optimizing creative or frequency.

• Mobile SDK installed and initialized on app start
• Push permission prompt implemented (with a deliberate timing strategy)
• APNs/FCM token captured and registered; token refresh handled
• identify() called on login and updated on account changes
• Notification open/tap handling confirmed on real devices
• Deep links tested for cart, PDP, collection, and checkout entry points
• Commerce events implemented with consistent naming + required properties
• Order event deduplication strategy defined (app vs backend)
• QA plan: test push → open → purchase, verified in Customer.io activity logs

Expert Implementation Tips

These are the small operator moves that keep push reporting trustworthy once you’re sending at scale.

• Identify late, but not too late: If you support guest browsing, register the device immediately, then call identify() the moment the user authenticates. That way you don’t lose early funnel behavior.
• Standardize event names before you launch Journeys: Renaming events later is how you end up with two “Added to Cart” variants and broken segments.
• Track “Push Opt-In” as an attribute: Use app-side state (authorized/denied) to segment. Don’t assume “has a device token” equals “still opted in.”
• Use a holdout for reactivation pushes: Even a 5–10% holdout tells you whether opens translate to incremental orders or just cannibalize organic returns.
• Instrument a lightweight “App Opened” event: It helps you distinguish “push open” from “organic session,” especially when you’re comparing channel performance.

Common Mistakes to Avoid

Most push programs fail quietly because the data is “mostly working.” These are the issues that create false confidence and bad decisions.

• Not calling identify() consistently: Push engagement gets stuck on anonymous profiles or the wrong user after account switching.
• Only tracking delivery, not opens: Teams optimize send volume because “delivery looks fine,” while actual engagement is falling.
• Broken deep links: You’ll see opens with low conversion and assume the offer is weak—when the user actually landed on home instead of cart.
• Duplicate purchase events: Inflated revenue attribution leads to over-sending and hurts long-term CLV.
• Token refresh ignored: Deliverability degrades over time, and you misread it as “push fatigue.”

Summary

If push is a meaningful revenue channel, you need app-side metrics you can trust: device registration, clean identity stitching, and a few commerce events that close the loop. Once those are solid, you can confidently tune cart recovery, replenishment, and reactivation without guessing.

Implement Push Metrics with Propel

If you’re rolling out push or trying to fix messy attribution, it’s usually faster to validate the SDK + identity plan upfront than to debug campaign performance later. We’ll map the exact events, identify rules, and suppression logic you need in Customer.io—book a strategy call when you’re ready to pressure-test your setup.