Capture Push Metrics (SDK)

Overview

If you’re sending push through Customer.io, capturing push metrics isn’t a “nice to have”—it’s what turns push from a blunt instrument into something you can actually optimize for repeat purchase and recovery. If you want a second set of eyes on your event spec and identity stitching before you scale sends, book a strategy call.

In most retention programs, we’ve seen push performance get misread because teams only look at sends and clicks. The real lift comes when you can trust delivery/open signals and tie them back to downstream events (add-to-cart, checkout started, purchase) without breaking identity across devices.

How It Works

Push metrics are only as good as the tracking chain from device → push provider → app → Customer.io. The SDK is where you close that loop: it registers the device token, associates it to the right person, and logs the engagement events that power reporting and segmentation.

• Device registration: Your app collects the push token (APNs/FCM) and hands it to the Customer.io SDK. Customer.io stores that token as a device tied to a profile.
• Identity stitching: The critical step is calling identify after login (and whenever identity changes). That’s what attaches the device token—and any anonymous pre-login activity—to the known customer profile.
• Engagement capture: When a user opens a push or taps an action, the SDK records the push engagement so Customer.io can attribute opens/clicks and measure performance. Without this, you’ll often see “delivered” but no reliable engagement.
• Downstream attribution: Once push engagement is captured, you can correlate it with your own events (e.g., Added to Cart, Checkout Started, Order Completed) to understand whether push is actually driving revenue—not just taps.

Step-by-Step Setup

The fastest way to get this right is to treat push metrics as an SDK instrumentation project, not a messaging project. Get the identity + event plumbing stable first, then build journeys on top of it.

1. Install the Customer.io SDK for your app platform.
   Use the official iOS/Android (or React Native/Flutter) SDK and initialize it at app start. Keep initialization consistent across environments so you don’t end up with “works in dev, missing in prod” metrics.
2. Enable push and configure provider credentials.
   Set up APNs (iOS) and/or FCM (Android) and make sure your app can receive pushes before you worry about attribution. If notifications aren’t reliably delivered, metrics will be noise.
3. Register device tokens with the SDK.
   When the OS issues a token, pass it to the SDK so Customer.io can associate the device. This is the foundation for delivery + engagement measurement.
4. Implement identify immediately after authentication.
   This is where most retention programs quietly break. Call identify(customerId, attributes) after login and on any account switch. If you support guest checkout or email capture pre-login, plan how you’ll merge anonymous activity into the known profile.
5. Track your revenue-driving events alongside push engagement.
   Push metrics tell you interaction; your events tell you outcomes. At minimum, track: Product Viewed, Added to Cart, Checkout Started, Order Completed (with order value, currency, items).
6. Verify metrics end-to-end in Customer.io.
   Send a test push to a test device, open it, and confirm the engagement shows up where you expect (message metrics + the person’s activity log). Then confirm a downstream event fires after the open so you can validate attribution logic.

When Should You Use This Feature

You’ll get the most value from push metrics when you’re past “send more pushes” and into “send fewer, smarter pushes.” The goal is to know what actually works by segment, device, and intent—not to chase vanity opens.

• Cart recovery with real attribution: If you run a cart abandonment push 30–60 minutes after Added to Cart, push metrics let you separate “opened push” from “completed checkout,” so you can tune timing and content based on revenue, not taps.
• Repeat purchase loops: For consumables (coffee, skincare, supplements), you can measure whether replenishment pushes are being opened and whether they lead to Order Completed within a window.
• Reactivation: When you target lapsed buyers, push metrics help you spot segments where delivery is fine but engagement is dead—usually a sign of stale tokens, poor identity stitching, or over-messaging.
• Cross-device reality: If customers browse on web and buy on mobile (or vice versa), accurate identity + push engagement is what prevents you from crediting the wrong channel or suppressing the wrong person.

Real D2C scenario: A skincare brand sends a “You left something behind” push after Checkout Started. Without SDK engagement tracking, the team sees decent delivery but can’t tell if the push drives revenue. With push metrics + purchase events, they discover iOS opens are strong but Android opens are low because tokens aren’t being re-registered after app updates—fixing that lifts cart recovery without changing creative.

Operational Considerations

Once push metrics are flowing, the day-to-day work is less about “did it send?” and more about keeping your data clean enough to segment and orchestrate confidently.

• Segmentation depends on identity hygiene: If you identify late (or inconsistently), you’ll end up with push engagement on one profile and purchases on another. In practice, this tends to break reactivation and winback flows first.
• Token churn is real: Device tokens rotate. If your app doesn’t reliably register new tokens, you’ll see gradual delivery decay and assume the audience is “fatigued” when it’s actually a data issue.
• Event naming and payload consistency: Keep a tight contract for commerce events (order_id, value, currency, items). Push metrics become actionable when you can slice by category, AOV, or first-time vs repeat.
• Orchestration across channels: Push metrics are most useful when they influence suppression/branching. Example: if someone opens a cart push, suppress the next email reminder for 6–12 hours and wait for Order Completed.
• Time windows matter: Decide what “success” means operationally (purchase within 4 hours of open, within 24 hours of send, etc.) and standardize it so your team isn’t debating attribution every week.

Implementation Checklist

Before you roll push metrics into high-volume programs, get these basics locked. It’ll save you from debugging “performance issues” that are really instrumentation gaps.

• Customer.io SDK installed and initialized on app start (prod + staging)
• APNs/FCM configured and pushes confirmed delivered on real devices
• Device token registration wired and tested across reinstall/app update
• identify called after login and on account switch/logout flows
• Core commerce events tracked with consistent payloads
• Test push sent → opened → engagement visible in Customer.io activity
• Downstream purchase event visible and tied to the same profile
• Basic segments built (recent openers, non-openers, delivered-not-opened)

Expert Implementation Tips

These are the operator moves that usually separate “we have push” from “push is a predictable revenue lever.”

• Identify early, not perfectly: If you collect email before account creation (quiz, waitlist, SMS opt-in), identify as soon as you have a stable key. Then update attributes later. Waiting for the “perfect profile” costs you attribution.
• Instrument notification permission state: Track whether notifications are allowed/denied. It’s one of the best levers for forecasting reach and deciding when to shift to SMS/email for recovery.
• Use engagement to control pressure: Build a segment like “Delivered 3+ pushes in 7 days, 0 opens” and cool them down. That protects deliverability and keeps your best buyers from getting drowned out.
• Debug with a single known test profile: Keep one internal profile per platform (iOS/Android) and run every change through it. You’ll catch token/identify regressions immediately.

Common Mistakes to Avoid

Most push metric issues aren’t “Customer.io problems”—they’re instrumentation and identity problems that show up as misleading performance.

• Forgetting to call identify after login: Push engagement lands on an anonymous/incorrect profile, then revenue attribution looks broken.
• Not handling logout/account switching: Shared devices or multiple accounts can cause engagement to attach to the wrong customer, which poisons segmentation (especially winbacks).
• Assuming delivery equals reach: If tokens are stale, you can see “sent” counts without meaningful engagement. Watch delivery trends by platform and app version.
• Tracking purchases but not cart/checkout intent: Without mid-funnel events, you can’t build good recovery logic or understand where push is actually helping.
• Over-optimizing for opens: Opens are useful, but retention teams win by optimizing for downstream purchase and repeat rate by cohort.

Summary

Capture push metrics through the SDK so you can trust delivery and engagement, stitch identity across devices, and tie push to revenue-driving events. If your cart recovery or reactivation numbers feel “off,” it’s usually an identify/token issue—not creative.

Implement Push Metrics with Propel

If you’re tightening up push measurement inside Customer.io, the highest-leverage work is usually an instrumentation pass: identity stitching, token lifecycle, and a clean commerce event spec that makes segmentation reliable. If you want help pressure-testing your setup before you scale, book a strategy call and we’ll walk through what’s being captured app-side and where attribution tends to drift.