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

Overview

If you’re running push as a serious retention channel in Customer.io, you need more than “sent” counts—you need reliable delivery, open, and downstream conversion signals tied to the right customer profile. If you want a second set of eyes on your tracking plan before you scale cart recovery or winback, book a strategy call and we’ll pressure-test the instrumentation and identity stitching.

In most retention programs, push performance breaks down because metrics are either missing (SDK not wired), mis-attributed (anonymous vs identified users), or delayed (events arrive after the journey decision point). Capturing push metrics cleanly is what lets you suppress “already converted” shoppers, tune send windows, and build segments like “push-clickers who didn’t purchase.”

How It Works

Customer.io’s push metrics come from what the device and your app report back—so the SDK is the source of truth for opens and action taps, and your own event tracking is the source of truth for conversion (add-to-cart, checkout started, order placed). The goal is to make sure those signals land on the same person profile, fast enough to drive orchestration decisions.

• Device registration: the SDK registers the device push token with Customer.io and associates it to a person once you identify them. This is what makes “send push to this customer” possible.
• Push lifecycle events: when a push is delivered/opened/tapped, the SDK reports those events back so Customer.io can attribute engagement to the message and campaign.
• Conversion events (your events): you track events like Added to Cart, Checkout Started, and Order Completed from the app/site. Customer.io then ties those to the push touchpoint for reporting and for journey logic (goals/exit conditions).
• Identity stitching: if the user is anonymous when they receive a push (or when they browse), you need a clean handoff when they log in or provide email/phone—otherwise push opens and purchases end up on different profiles and your metrics look “fine” while targeting gets worse.

Real D2C scenario: a shopper abandons a cart on mobile at 9:10pm. You send a push at 9:40pm with a deep link back to the cart. If the SDK doesn’t report the open, you can’t distinguish “ignored” from “opened but didn’t buy.” If identity isn’t stitched, the purchase lands on a different profile and the customer keeps getting reminders after they already checked out.

Step-by-Step Setup

Before you touch journeys, get the plumbing right. Push metrics are only as good as your SDK install, your identify timing, and the events you fire around commerce actions.

1. Install the Customer.io SDK on your app(s).
   Use the appropriate mobile SDK (iOS/Android/React Native/Flutter/etc.) and confirm it initializes on app launch in all environments (dev/stage/prod).
2. Enable push in the SDK and register device tokens.
   Make sure APNs (iOS) / FCM (Android) tokens are captured and sent to Customer.io. Validate that token refreshes are handled—this is a common silent failure that kills deliverability over time.
3. Call identify as soon as you have a stable customer identifier.
   Do this at login/account creation and whenever you resolve identity (email capture, phone capture). Use a consistent customer_id (or whatever your canonical ID is) so devices, events, and purchases all land on the same person.
4. Track commerce events that represent conversion.
   At minimum for retention: Product Viewed, Added to Cart, Checkout Started, Order Completed. Include properties like cart_value, currency, items, sku, and order_id.
5. Deep link your push destinations and track the landing.
   If your push goes to a cart, PDP, or checkout, track an event like Push Landing Viewed with properties for message_id/campaign_id if available. This helps diagnose “open happened but app routing failed.”
6. QA metrics end-to-end with a real device.
   Send a test push, open it, and confirm you see (a) device registered, (b) open/click attributed, (c) downstream conversion event tied to the same profile.
7. Only then wire journeys and reporting.
   Set journey goals/exit conditions on Order Completed (and sometimes Checkout Started) so cart recovery stops the moment intent is proven.

When Should You Use This Feature

Capturing push metrics matters any time push is doing real work in the retention mix. If you’re using push as a “spray and pray” channel, you’ll still get sends—but you won’t get the feedback loops that actually improve repeat purchase and winback.

• Cart recovery on mobile: optimize timing and frequency based on real opens and purchases, not just deliveries.
• Browse abandonment: build segments like “opened push but didn’t view product” vs “viewed product but didn’t add to cart.”
• Post-purchase repeat purchase: measure which replenishment pushes drive reorder, and suppress customers who already repurchased.
• Reactivation/winback: identify “push-engaged but lapsed” customers and route them to stronger offers or different channels.
• Channel arbitration: decide when to switch from push → email/SMS based on non-engagement over a defined window.

Operational Considerations

Once push metrics are flowing, the real operator work is making sure segmentation and orchestration reflect reality—especially across anonymous traffic, multiple devices, and delayed events.

• Segmentation depends on identity timing: if you identify late (e.g., only at checkout), your push metrics will cluster on anonymous profiles and you’ll undercount engagement for known customers. Move identify earlier (login, email capture, loyalty sign-in).
• Multi-device behavior is normal: one customer might browse on web, add to cart on mobile, and purchase on desktop. If web tracking uses one identifier and app uses another, you’ll “double message” and misread lift. Align IDs across web + app.
• Event latency breaks journey logic: if Order Completed arrives minutes late, the customer can receive an extra push after purchase. In practice, teams fix this by (a) firing a lightweight Checkout Completed immediately client-side, then reconciling server-side, or (b) adding a short delay before the final reminder.
• Don’t over-optimize on opens alone: opens are useful for creative and timing, but retention decisions should ladder up to conversion events (checkout/order) and margin-aware properties (AOV, discount used).
• Orchestration reality: your push metrics should feed suppression rules (recent purchasers, active carts, customer support issues) so you don’t create negative experiences while chasing incremental lifts.

Implementation Checklist

If you want push metrics you can actually trust in reporting and segmentation, treat this like a tracking launch—not a messaging task.

• SDK initialized on app launch (all environments)
• Push permissions prompt handled intentionally (timing + UX)
• Device token registration working; token refresh handled
• identify called on login/account creation and any identity resolution point
• Commerce events tracked with consistent naming and required properties
• Deep links implemented and tested for push destinations
• End-to-end QA: send → deliver → open → app route → conversion event
• Journeys use conversion events for goals/exit conditions
• Suppression segments built (recent purchase, active subscription, support risk)

Expert Implementation Tips

These are the small operator moves that usually separate “metrics exist” from “metrics drive better retention.”

• Standardize IDs early: pick a canonical customer_id and use it everywhere (web + app + backend). Most attribution weirdness is really ID drift.
• Track “push enabled” as an attribute: update a boolean like push_opt_in=true (and store platform). This keeps your segments clean and prevents wasted sends.
• Instrument intent, not just outcomes: for cart recovery, Checkout Started is often a better mid-funnel goal than waiting for Order Completed to decide whether to stop reminders.
• Create a “push fatigue” counter: store a rolling 7-day push send count and use it to cap reminders for low-engagement customers.
• Use a diagnostic event for routing: fire something like Deep Link Failed when the app can’t resolve the push destination. It’s shocking how often “push doesn’t work” is actually a routing issue.

Common Mistakes to Avoid

Most teams don’t fail because push is hard—they fail because the data model is sloppy and the journey depends on signals that aren’t reliable.

• Relying on opens without conversion tracking: you’ll optimize creative that gets taps, not revenue.
• Calling identify too late: opens and purchases land on different profiles, so suppression and attribution both degrade.
• Not handling token refresh: deliverability quietly drops over weeks, and you blame creative.
• Inconsistent event names across platforms: iOS fires Order Completed, Android fires Purchase, and your segments miss half the base.
• No QA on real devices: simulator tests won’t catch permission state, notification routing, or background open behavior.
• Over-sending cart reminders: without exit conditions tied to checkout/purchase, you keep pushing after conversion and train customers to ignore you.

Summary

If push is part of your retention engine, capturing push metrics via the SDK is non-negotiable. Get device registration, identify timing, and conversion events right, then use those signals to suppress, segment, and optimize journeys. If metrics don’t tie back to the same profile, everything downstream gets noisier and less profitable.

Implement Push Metrics with Propel

If you’re already sending push in Customer.io, the fastest win is usually tightening identity stitching and conversion instrumentation so cart recovery and winback can make better decisions automatically. If you want us to review your SDK tracking plan (identify points, event schema, and journey exit logic), book a strategy call—we’ll focus on what will actually move repeat purchase and reduce wasted sends.