Capture push metrics (SDK-first) in Customer.io

Overview

If push is a meaningful revenue lever for your brand, you need clean, end-to-end measurement inside Customer.io—not just “sent” counts. When you capture push metrics properly (delivery, opens, and downstream events like add-to-cart or purchase), you can tune recovery and repeat-purchase journeys based on what actually works. If you want a second set of eyes on your tracking plan and identity stitching, book a strategy call.

In most retention programs, we’ve seen push underperform simply because the app instrumentation is fuzzy: opens don’t map to the right person, conversions are attributed to the wrong touch, and Android/iOS behave differently. Fixing metrics capture is usually the fastest way to unlock better holdouts, better frequency rules, and better reactivation ROI.

How It Works

Push metrics only become useful once Customer.io can reliably connect three things: the device that received the push, the person who owns that device, and the events that happen after the push (session start, product view, add to cart, purchase). The SDK is where that stitching happens—especially when someone installs, browses anonymously, then logs in later.

• Device registration: your app SDK registers the device push token (APNs for iOS, FCM for Android) and associates it with a Customer.io person profile.
• Identity stitching: when a user logs in (or you otherwise know who they are), the app calls identify so Customer.io can attach the device token and future activity to the correct person.
• Engagement tracking: the SDK captures push engagement signals (like opens) and sends them back to Customer.io so message-level reporting reflects real behavior.
• Conversion tracking: your app tracks the business events you care about (e.g., Viewed Product, Added to Cart, Order Completed) so you can attribute lift to push campaigns and build segments like “opened push but didn’t purchase.”

D2C scenario: A shopper abandons cart on mobile. You send a push 45 minutes later with a “Still thinking about it?” nudge. If you’re capturing push opens and purchase events correctly, you can split reporting into: delivered vs opened vs purchased, then tighten the journey (e.g., only send the second reminder to “delivered but not opened,” and reserve the incentive for “opened but didn’t purchase”).

Step-by-Step Setup

The goal here is simple: make sure every device token is tied to the right Customer.io profile and every meaningful action after a push is tracked as an event. Do this once, and your cart recovery + reactivation flows stop guessing.

1. Install the Customer.io SDK in your app
   • Add the Customer.io mobile SDK to iOS and/or Android (or your wrapper like React Native/Flutter/Expo).
   • Confirm the SDK initializes on app launch in all environments you care about (prod + staging if you test there).
2. Configure push credentials and enable push in Customer.io
   • Set up APNs (iOS) and/or FCM (Android) so Customer.io can send pushes to your app.
   • Verify you can send a test push to a known device.
3. Register device tokens and keep them fresh
   • On token creation/refresh, pass the token to the Customer.io SDK so it can associate the token with the device record.
   • Handle token rotation (common on iOS reinstalls and some Android cases) or you’ll see “sent” with no deliveries.
4. Call identify at the right moment (this is where most teams slip)
   • Call identify(userId, attributes) immediately after login/account creation.
   • If you support guest checkout or anonymous browsing, don’t “guess” identity early—capture anonymous activity, then merge/stitch once you have a real identifier.
   • If your app supports logout, reset the SDK identity on logout to avoid cross-user contamination on shared devices.
5. Track the post-push events you’ll optimize against
   • At minimum for D2C retention: Viewed Product, Added to Cart, Checkout Started, Order Completed.
   • Send consistent properties (SKU, product_id, cart_value, currency, order_id) so you can segment and report cleanly.
6. Verify push metrics in reporting before you scale
   • Send a small internal campaign and confirm you see deliveries/opens and that opens correlate with real app sessions.
   • Confirm conversions are attributed to the right person (especially if you have multi-device shoppers).

When Should You Use This Feature

Push metrics capture matters most when push is part of your core retention motion and you need to make journey decisions based on engagement—not just sends. If you’re running push “because you can,” measurement work won’t pay back.

• Cart recovery on mobile: optimize timing and incentive strategy based on delivered/opened behavior, not gut feel.
• Repeat purchase nudges: for consumables, trigger replenishment pushes and measure “opened → viewed product → purchased” to tune cadence.
• Winback/reactivation: build segments like “not purchased in 90 days, push delivered, no open” vs “opened but bounced” and run different creative.
• Product drop / back-in-stock: measure open rate and downstream add-to-cart to decide whether to follow with email/SMS or hold back.

Operational Considerations

Once tracking is live, the real work is keeping the data usable for segmentation and orchestration. In practice, this tends to break when identity is inconsistent or when teams track events differently across platforms.

• Segmentation depends on clean identity: if a device token is associated with the wrong profile, you’ll suppress the wrong people (or worse, send to the wrong person). Treat identify + logout handling as non-negotiable.
• Event taxonomy must match across iOS/Android: “AddedToCart” on Android and “Added to Cart” on iOS creates duplicate segments and broken journey triggers.
• Attribution is only as good as your conversion events: if your purchase event fires late, duplicates, or misses server-confirmed orders, your push reporting will lie. Many D2C teams send purchase from server/webhook and also from app—pick a source of truth and dedupe with order_id.
• Orchestration reality: once you can trust push opens, you can add practical rules like “if not opened within 2 hours, follow with email” or “if opened but no cart, show in-app message next session.” Without metrics, those branches become noise.

Implementation Checklist

Before you rely on push reporting for decisions (frequency caps, incentives, channel arbitration), make sure the basics are locked. This checklist is what we run through before scaling a cart recovery or winback program.

• Customer.io SDK installed and initializing on app launch
• APNs/FCM credentials configured and test push confirmed
• Device token registration implemented (including refresh/rotation)
• identify called immediately after login/account creation
• Logout/reset behavior implemented to prevent cross-user mixing
• Core D2C events tracked with consistent naming and properties
• Purchase event deduped with order_id and consistent source of truth
• Test campaign validated for delivered/opened signals + downstream conversion

Expert Implementation Tips

These are the small operational choices that usually separate “push is a channel” from “push is a measurable profit center.”

• Instrument deep links like a product analyst, not a marketer: when a push opens a PDP, track Push Opened (or rely on built-in open metrics) and also track Viewed Product with SKU. That’s how you learn which creative actually drives product discovery.
• Use a single, stable customer identifier: if you switch between email, internal user ID, and phone, you’ll fragment profiles and your push metrics will look “fine” while revenue attribution is wrong.
• Guard against duplicated purchase events: if you must track client-side and server-side, add a dedupe rule in your pipeline using order_id so journeys don’t over-credit push.
• Build “engagement-based” suppression segments: for example, suppress “delivered but never opened in 30 days” from high-frequency pushes and move them to a lower-frequency repermission track.

Common Mistakes to Avoid

Most push reporting issues aren’t Customer.io problems—they’re instrumentation and identity problems that show up later as wasted sends and misleading tests.

• Calling identify too late: if you wait until checkout or purchase, all the browsing and push engagement before that stays anonymous and can’t inform segments.
• Not resetting identity on logout: shared devices (or even just account switching) can poison your metrics and send recovery messages to the wrong person.
• Inconsistent event names/properties across platforms: you’ll end up with duplicated segments and journeys that only work for half your users.
• Optimizing on “sent” instead of “delivered/opened”: delivery failures and notification permission drop-offs are real—especially for winback cohorts.
• Missing token refresh handling: you’ll see decaying delivery rates over time and assume creative is the problem.

Summary

If you want push to drive repeat purchase and recovery, you need trustworthy delivery/open signals and clean conversion events tied to the right profile. Get SDK identity and event tracking right, then use engagement-based branches to reduce spam and lift revenue. If your metrics don’t reconcile, fix stitching before you touch creative.

Implement Push Metrics with Propel

When teams ask us to troubleshoot “push isn’t working,” it’s usually a tracking and identity stitching issue—not a messaging issue. We’ll help you map a clean SDK event plan, validate token/identify behavior, and make sure Customer.io reporting lines up with what’s happening in-app so your recovery and winback journeys can make real decisions. If you want to pressure-test your implementation, book a strategy call.