Push Metrics (SDK): Track Delivery, Opens, and Downstream Revenue in Customer.io

Overview

If you’re running push as a real retention channel (not just “send and hope”), you need clean feedback loops: delivered, opened, and what happened after the tap. Customer.io push metrics get you that visibility—assuming your SDK implementation and identity stitching are tight. If you want a second set of operator eyes on your tracking plan before you scale journeys, you can book a strategy call.

In most D2C programs, push metrics become the difference between “push drives revenue” and “push annoys customers.” Once you can trust delivery + open data, you can tune frequency, suppress fatigued users, and route high-intent tapers into tighter conversion flows.

How It Works

Push metrics in Customer.io are only as good as the signals your app SDK sends back. The platform can attribute message performance when it can connect (1) a device token to (2) a known person profile and then (3) observe engagement events like opens and downstream conversion events like checkout.

• Device registration: Your mobile app SDK collects the push token (APNs for iOS, FCM for Android) and registers it to Customer.io. This is what makes “deliveries” and device-level reach measurable.
• Identity stitching: When a user logs in (or you otherwise know who they are), your app must call identify so Customer.io can attach that device token to the right person. Without this, you’ll see anonymous device behavior that won’t reliably tie back to revenue.
• Engagement capture: When a user opens a push (or taps an action), the SDK should record the open/interaction and send it to Customer.io. This is what powers open rate and message-level engagement.
• Downstream attribution: Your app (and/or backend) still needs to send the business events that matter—Product Viewed, Added to Cart, Checkout Started, Order Completed. Push metrics tell you the message was opened; these events tell you whether it worked.

Real D2C scenario: A customer abandons a cart for a replenishable item (say, haircare). You send a push 45 minutes later: “Still thinking about it? Your routine is waiting.” If push metrics are wired correctly, you’ll see delivery → open → and then whether Checkout Started/Order Completed happened within your attribution window. If identity stitching is sloppy, you’ll see opens with no revenue and you’ll end up under-investing in a channel that’s actually working.

Step-by-Step Setup

The goal here is simple: make sure every push-enabled device is registered, every logged-in user is identified, and every open + purchase event is trackable. Do this once, do it cleanly, and your push program stops flying blind.

1. Install the Customer.io mobile SDK
   • Add the Customer.io SDK to your iOS/Android app (or your framework wrapper like React Native/Flutter).
   • Confirm you’re using the correct workspace/site ID + API key/config for the environment (dev vs prod).
2. Enable push and register device tokens
   • iOS: request notification permission, then capture and register the APNs token.
   • Android: configure FCM and register the FCM token.
   • Validate that tokens update correctly on refresh (tokens change more often than teams expect).
3. Call identify immediately on login
   • When a user authenticates, call identify with your stable customer identifier (e.g., customer_id).
   • Send key attributes that help retention segmentation (e.g., first_order_date, subscription_status, lifetime_value).
   • Avoid identifying on weak identifiers (like email before verification) if that causes profile fragmentation.
4. Track push opens and interactions
   • Confirm the SDK is configured to capture notification opens.
   • If you use deep links, make sure the open event still fires when routing through your link handler.
   • If you use action buttons, ensure each action is captured (these are often “invisible” unless explicitly handled).
5. Track the conversion events that prove value
   • Send Added to Cart, Checkout Started, and Order Completed events with order metadata (value, currency, items).
   • Keep event naming consistent across app and backend so attribution isn’t split across variants.
6. QA the full loop end-to-end
   • Send a test push to a real device.
   • Verify: delivered → opened → conversion event appears on the same person profile.
   • Repeat for: logged-out state, logged-in state, token refresh, and reinstall (reinstall is where identity stitching tends to break).

When Should You Use This Feature

Push metrics matter most when you’re using push as a conversion and repeat-purchase lever, not just a broadcast channel. The minute you start making suppression and routing decisions based on engagement, you need trustworthy metrics.

• Cart recovery on mobile-heavy stores: If most of your traffic is mobile, push often beats email on speed—especially within the first 1–2 hours after abandonment.
• Post-purchase cross-sell and replenishment: Use opens + downstream purchase events to learn which timing windows actually drive second order (e.g., day 14 vs day 21).
• Reactivation: Identify “delivered but never opens” vs “opens but doesn’t buy.” Those are different problems and should trigger different winback paths.
• Offer testing without wrecking deliverability: Push metrics let you A/B incentives and creative quickly without burning your email sender reputation.

Operational Considerations

In practice, push metrics tend to break at the seams: token lifecycle, identity merges, and event timing. If you plan for those realities upfront, your reporting and journeys stay stable as you scale.

• Segmentation depends on identity hygiene: If a user has multiple profiles (guest checkout, email change, reinstall), push opens may attach to the “wrong” person. Decide your canonical identifier and enforce it in identify.
• Data flow timing matters: If your purchase event is server-side but arrives late, your “push drove revenue” reporting will look worse than reality. Align timestamps and make sure order events include a reliable created_at.
• Orchestration across channels: Once push opens are reliable, you can do smart suppression—e.g., if push opened, don’t send the follow-up email; if push delivered but not opened, escalate to email/SMS after X hours.
• Attribution windows need to match buying behavior: For impulse items, a 4–12 hour window might be fair. For higher-AOV products, you may need 1–3 days. Pick a window, document it, and keep it consistent so the team trusts the numbers.

Implementation Checklist

Before you rely on push metrics for decisions (frequency, suppression, or spend), make sure the basics are locked. This checklist is the minimum bar we hold D2C teams to when push becomes a top retention channel.

• Customer.io mobile SDK installed in production builds (iOS + Android as applicable)
• Push permission prompt strategy defined (when/where you ask, and what you do if denied)
• APNs/FCM token registration confirmed and resilient to token refresh
• identify called on login with a stable customer identifier
• Anonymous-to-known stitching tested (guest browse → login → purchase)
• Push open tracking verified with deep links enabled
• Core commerce events tracked consistently: Product Viewed, Added to Cart, Checkout Started, Order Completed
• End-to-end QA: delivered → opened → purchase attributed on the same profile

Expert Implementation Tips

Once the basics work, the gains come from tightening your identity graph and making your push metrics actionable inside journeys—not just visible in dashboards.

• Identify early, but not sloppily: If you identify users before authentication (e.g., email typed into a field), you’ll inflate duplicate profiles. If you need pre-login tracking, use anonymous profiles and merge cleanly at login.
• Track “push_enabled” as a first-class attribute: Store permission state and update it when users change OS settings. This keeps you from routing “push-first” journeys to people who can’t receive push.
• Use message engagement to control frequency: A practical rule: if a user hasn’t opened the last N pushes, slow down or pivot channels. This is where push metrics directly protect LTV by reducing fatigue.
• Deep link to the exact intent: Cart recovery push should land in cart with items visible. Category discovery push should land on a filtered collection. Opens without intent-aligned landing pages look like “push doesn’t work” when it’s really routing friction.

Common Mistakes to Avoid

Most push programs don’t fail because creative is bad—they fail because the data is untrustworthy. These are the issues that quietly poison push metrics and make teams cut the channel too early.

• Not calling identify after login: You’ll get device-level behavior that can’t be tied to orders, so revenue attribution collapses.
• Letting token refresh break registration: Push “delivery” drops over time and nobody notices until performance tanks.
• Relying on opens without conversion events: Open rate is not a retention KPI. Without purchase events, you can’t optimize for repeat purchase or reactivation.
• Inconsistent event names across platforms: Order Completed vs order_completed splits reporting and segments, and your journeys miss people.
• Ignoring duplicate profiles: If the same customer exists twice, you’ll double-message or suppress incorrectly—both hurt revenue.

Summary

Push metrics are only useful when your SDK reliably registers tokens, stitches identity, and records opens alongside purchase events. If you’re using push for cart recovery, replenishment, or winback, getting this right quickly pays back in cleaner orchestration and higher repeat revenue.

Implement Push Metrics with Propel

If you’re tightening push tracking to drive repeat purchase (not just reporting), it helps to pressure-test the identity and event plan before you roll it into high-volume journeys. Propel teams often sanity-check the SDK instrumentation, stitching rules, and suppression logic inside Customer.io so push metrics actually map to revenue outcomes. If you want to walk through your current setup and where it’s likely to break at scale, book a strategy call.