Push Metrics (SDK): Track delivery, opens, and downstream revenue in Customer.io

Overview

If you want push to drive repeat purchase (not just “send more notifications”), you need clean measurement inside Customer.io—and that starts with SDK-level push metrics wired correctly. When the plumbing is right, you can see delivery vs. open rates by segment, tie opens to product views/add-to-cart, and actually optimize your recovery and replenishment flows. If you want a second set of eyes on your instrumentation and identity stitching, book a strategy call.

In most retention programs, push “underperforms” because teams can’t trust the numbers: tokens aren’t tied to the right user, opens aren’t tracked consistently, and downstream events (viewed product, started checkout, purchased) aren’t connected back to the push send.

How It Works

Push metrics in Customer.io are only as good as the app-side signals you send. The SDK is responsible for (1) registering the device for push, (2) stitching that device to the right person profile, and (3) reporting what happened after the notification hit the device.

• Device registration: Your app collects the APNs token (iOS) or FCM token (Android) and passes it to the Customer.io SDK so the device becomes a reachable target.
• Identity stitching: When a user logs in (or you otherwise know who they are), you call identify so Customer.io ties the device token to that person. This is the difference between “we sent 100k pushes” and “we sent 100k pushes to the right customers.”
• Delivery/open measurement: Depending on platform capabilities and your SDK configuration, Customer.io records delivery outcomes and open events when the user taps the notification (or when your app processes the push interaction).
• Downstream retention attribution: You track in-app events (e.g., product_viewed, add_to_cart, checkout_started, order_completed) so you can compare cohorts who opened a push vs. those who didn’t—and drive smarter resend logic and segmentation.

Real D2C scenario: You run a cart recovery push 45 minutes after abandonment. Without SDK push metrics, you’ll optimize on “sent.” With push metrics + downstream events, you’ll see: delivered but not opened (creative/timing issue) vs. opened but no checkout_started (landing/context issue) vs. checkout_started but no purchase (offer/friction issue). That’s where real lift comes from.

Step-by-Step Setup

Plan this like a data project, not a messaging project. The goal is to ensure every push token is attached to the correct profile, and every open can be tied to the session and events that follow.

1. Install the Customer.io mobile SDK
   • Add the iOS/Android (or React Native/Flutter) SDK to your app.
   • Initialize the SDK early in app startup so it can handle push interactions reliably.
2. Enable push permissions and capture device tokens
   • iOS: request notification permission at the right moment (post-value, not on first launch), then capture the APNs device token.
   • Android: configure FCM and capture the registration token.
   • Pass the token to the Customer.io SDK so the device is registered for push.
3. Implement identity stitching with identify
   • Call identify immediately after login/account creation.
   • Send stable identifiers (your internal customer ID) and key attributes used for segmentation (e.g., email, phone, first_order_date, vip_tier).
   • If your app supports logout, reset/clear the identified user state on logout to avoid cross-user contamination on shared devices.
4. Track push opens (and deep link context)
   • Make sure the SDK is configured to capture notification opens when the user taps the push.
   • Include deep link parameters in the push payload (e.g., destination screen, product SKU, cart ID) so the app can route correctly and you can analyze intent.
5. Instrument downstream retention events
   • At minimum: product_viewed, add_to_cart, checkout_started, order_completed.
   • Include consistent properties like sku, category, price, cart_value, order_id.
   • When possible, persist campaign context (e.g., push campaign ID) into session state so downstream events can be connected back to the push interaction.
6. Validate in Customer.io before you scale
   • Send a test push to internal devices.
   • Confirm: device shows up on the person profile, open events appear, and downstream events arrive under the same profile.
   • Only then turn on high-volume automations like cart recovery or winback.

When Should You Use This Feature

Push metrics matter most when you’re making operational decisions based on engagement—resends, holdouts, suppression, and offer logic. If you can’t trust delivery and opens, you’ll end up over-messaging your best customers and missing the people who actually need the nudge.

• Cart recovery push: Split “delivered-not-opened” vs. “opened-no-checkout_started” and change the second message accordingly (different landing page, stronger incentive, or support angle).
• Replenishment and repeat purchase: For consumables, track whether replenishment pushes are opened and whether they lead to product_viewed and order_completed within a window.
• Reactivation: Identify dormant customers who still receive push but never open—then move them to email/SMS or prompt in-app permission refresh.
• Product discovery: If a push drives category browsing but not carts, that’s a merchandising/landing problem—not a channel problem.

Operational Considerations

In practice, push metrics break at the seams: identity, timing, and inconsistent event naming. Treat this as a data contract between your app team and your retention team, because segmentation and orchestration depend on it.

• Segmentation depends on identity stitching: If you register tokens before identify and never stitch post-login, you’ll see “anonymous” devices that can’t be targeted with customer-level logic (VIP, last order date, predicted replenishment window).
• Multi-device reality: One person can have multiple devices/tokens. Your orchestration needs to decide whether to send to all devices or prefer the most recently active device to avoid duplicate notifications.
• Data flow latency: Push opens can arrive quickly, but downstream purchase events might come from server-side systems later. Build delays/decision windows accordingly (e.g., wait 30–90 minutes before sending a second cart push).
• Event taxonomy: If your app uses CheckoutStarted and your backend uses checkout_started, your segments and conversion reporting will be noisy. Standardize names and properties across sources.
• Suppression logic: Use push metrics to suppress aggressively: if a user has 10 delivered pushes with zero opens in 30 days, stop pushing and shift channel strategy.

Implementation Checklist

Before you build automations on top of push, lock down the basics so your metrics don’t lie and your segments don’t drift.

• Customer.io SDK installed and initialized on app launch
• Push permission flow implemented (timed after a value moment)
• APNs/FCM token captured and registered with Customer.io
• identify called on login/account creation with stable customer ID
• Logout/reset behavior defined to prevent cross-user device contamination
• Push open tracking validated end-to-end
• Deep link payloads standardized (destination, SKU/cart context)
• Core downstream events tracked with consistent naming/properties
• QA plan: internal device matrix (iOS/Android, fresh install, logged out/in, multiple devices)

Expert Implementation Tips

These are the small choices that usually separate “we have push” from “push is a reliable revenue lever.”

• Delay the permission prompt: Ask after a user favorites an item or adds to cart. Opt-in rate goes up, and your push audience is higher intent.
• Persist campaign context: When a push opens the app, store a short-lived “last_push_context” in memory/local storage and attach it to the next few events. That’s how you diagnose whether the push drove browsing vs. checkout.
• Design for resend logic: Build segments like “delivered AND not opened within 2 hours” so you can resend with different creative or switch channels without guessing.
• Use holdouts: For high-volume pushes (cart, replenishment), keep a small holdout cohort. It’s the easiest way to prove incremental lift and defend channel volume.

Common Mistakes to Avoid

Most push programs don’t fail because of copy—they fail because the app-side tracking is messy. Fix these early and you’ll save weeks of churn between marketing and engineering.

• Registering devices but never calling identify: You end up with tokens that can’t be targeted with customer attributes or purchase history.
• Calling identify with unstable IDs: Using email as the primary ID sounds convenient until users change emails or you have guest checkout flows.
• No logout hygiene: Shared devices (tablets, family phones) cause “wrong person” pushes, which looks like low engagement but is actually mis-targeting.
• Measuring only opens: Opens are diagnostic, not the goal. If you don’t track checkout_started and order_completed, you’ll optimize for taps instead of revenue.
• Inconsistent deep links: If half your pushes land on home and half land on PDP, your metrics will look random and you’ll blame the channel.

Summary

If push is part of your retention engine, SDK push metrics are non-negotiable. Get device registration and identity stitching right, then layer in open tracking and downstream events so you can optimize recovery and repeat purchase based on what actually happened.

Implement Push Metrics with Propel

If you’re already running push in Customer.io, the fastest win is usually an instrumentation audit: confirm tokens are stitched correctly, opens are trustworthy, and your downstream events support resend/suppression logic. When you want to pressure-test your setup against real retention flows (cart recovery, replenishment, winback), book a strategy call and we’ll map the tracking to the decisions you’re trying to make.