Track events (SDK) in Customer.io for retention marketing

Overview

Getting app-side events into Customer.io is what turns “we sent a campaign” into “we recovered revenue.” If your mobile app (or web app) is where customers browse, add to cart, and purchase, the SDK is the cleanest way to capture those moments with the right identity and timing—then trigger cart recovery, replenishment, and winback flows off real behavior.

If you want a second set of eyes on your event plan and identity stitching before you ship, book a strategy call—in most retention programs, the tracking spec is where performance is won or lost.

How It Works

Customer.io doesn’t magically know what a “cart” is. Your app sends Customer.io events (like Product Viewed, Added to Cart, Checkout Started, Order Completed) and Customer.io uses them to build segments and trigger campaigns in real time.

• SDK captures behavior in the moment: The app fires an event when the action happens (tap, view, purchase confirmation), with properties that describe the context (SKU, price, cart value, currency, category, etc.).
• Identity stitching makes events usable: Early in the session you’ll have an anonymous device/user. Once the customer logs in or provides an email/phone, you identify them so future events (and ideally past session activity) attach to the right person.
• Events become triggers + segmentation: You’ll typically trigger workflows off events (e.g., Added to Cart) and then filter/branch using event properties (e.g., cart_value > 75, category = “Skincare”).
• Accuracy depends on where you fire: For retention, fire “purchase” only after you have a confirmed order (server receipt or confirmation screen). Firing too early is how you end up suppressing people from cart recovery who never actually bought.

Step-by-Step Setup

Before you write a line of code, align on the handful of events that actually power revenue flows. Then implement the SDK with a tight identity strategy so you don’t end up with fragmented profiles and “missing” conversions.

1. Install the Customer.io SDK for your platform
   Add the Customer.io mobile SDK (iOS/Android/React Native/Flutter/etc.) or web SDK in your app. Do this early so you can validate events in a dev build before wiring up every screen.
2. Decide your identity key and when you’ll call identify
   Pick a stable identifier (commonly your internal customer_id). Then call identify immediately after login/signup, and again any time the identity changes (logout/login as different user).
   Operator note: if you only identify on checkout, you’ll lose most product discovery and browse intent—exactly what you need for better cart recovery and post-purchase upsell.
3. Track your core commerce events with consistent naming
   Start with a minimal set you’ll actually use:
   • Product Viewed (properties: sku, product_id, name, category, price, currency)
   • Added to Cart (properties: sku, quantity, cart_value, currency)
   • Checkout Started (properties: cart_value, item_count, coupon)
   • Order Completed (properties: order_id, revenue, currency, items array)
   Keep event names stable. Renaming events later breaks segments, triggers, and reporting.
4. Send person attributes on identify (and keep them current)
   On identify, include attributes you’ll segment on: email, phone (if SMS), first_name, country, marketing_opt_in, preferred_category. Update these when they change.
5. Validate event delivery and property quality
   Use Customer.io’s activity/event views to confirm:
   • Events arrive under the right person (not stranded on anonymous profiles).
   • Properties are present and typed consistently (numbers as numbers, not strings).
   • order_id is always populated on purchase events (dedupe depends on it).
6. Build retention workflows that depend on these events
   Once events are stable, wire them into campaigns: cart abandonment, browse abandonment, post-purchase cross-sell, replenishment, and winback.

When Should You Use This Feature

SDK event tracking matters most when the app is the source of truth for intent. If you’re trying to drive repeat purchase and recovery, you need the behavioral signals that happen before an email capture or before an order hits your backend.

• Cart recovery that doesn’t lie: Trigger off Added to Cart or Checkout Started, then suppress if Order Completed happens within a window. This only works if purchase events are accurate.
• Browse abandonment for product discovery: If someone views the same SKU twice in a session but never adds to cart, that’s a high-intent segment you can message differently than a generic newsletter audience.
• Replenishment and repeat purchase: Use Order Completed plus item-level properties to start a replenishment timer per product type (e.g., supplements at 25 days, skincare at 35 days).
• Reactivation based on real inactivity: “Has not viewed a product in 30 days” is a stronger winback trigger than “has not opened an email,” especially for mobile-heavy brands.

Real D2C scenario: A skincare brand sees lots of “add to cart” in-app, but only modest recovery. After implementing SDK tracking with proper identify on login and a confirmed Order Completed event, they split cart recovery into (1) high AOV carts and (2) first-time carts, and suppress anyone who purchases within 60 minutes. The result is fewer “why are you emailing me, I already bought” complaints and a meaningful lift in recovered revenue.

Operational Considerations

In practice, event tracking breaks less from code and more from messy identity, inconsistent properties, and teams shipping “just one more event” without thinking through downstream workflows.

• Segmentation depends on property hygiene: If cart_value is sometimes "98.00" (string) and sometimes 98 (number), your “cart value > 75” segments will silently undercount.
• Data flow timing affects orchestration: If your app fires Order Completed late (or not at all for some payment methods), cart recovery will keep sending. Align with engineering on the definitive “purchase confirmed” moment.
• Identity stitching is the retention unlock: Anonymous browsing is common in D2C apps. If you don’t merge/attach that activity after login, you lose the ability to personalize recovery and recommendations based on what they actually looked at.
• Event volume and noise: Don’t track every screen view as a unique event and then wonder why segments are slow and workflows are noisy. Track events tied to intent and revenue.
• Cross-channel consistency: If email/SMS is driven by Customer.io but purchases are recorded elsewhere, make sure the same order_id and customer identifier are used everywhere so reporting and suppression are reliable.

Implementation Checklist

Use this as the “ship it” gate before you build serious recovery and repeat purchase orchestration on top of your events.

• SDK installed and initialized in all app environments you’ll test (dev/stage/prod).
• identify called on login/signup with a stable customer_id.
• Anonymous-to-known stitching strategy confirmed (what happens to pre-login events).
• Core commerce events implemented: Product Viewed, Added to Cart, Checkout Started, Order Completed.
• Event properties standardized (types, naming, required fields like order_id).
• Purchase event fired only on confirmed order (not on “payment initiated”).
• Test profiles show events arriving under the correct person in Customer.io.
• At least one segment and one campaign trigger built from SDK events to validate end-to-end.

Expert Implementation Tips

These are the small choices that make your retention machine reliable six months from now, not just “working today.”

• Design events around decisions: If you can’t name the workflow branch the event powers, don’t ship the event yet.
• Always include a dedupe key on conversion events: For purchases, that’s order_id. It protects you from double-fires on flaky connections or app restarts.
• Send item arrays for merchandising: Even if you start simple, capturing items (SKU, qty, price) lets you do category-based replenishment and smarter cross-sell later without re-instrumenting.
• Track “Removed from Cart” if your catalog is high-consideration: For higher AOV brands, removal is a strong objection signal—use it to adjust messaging (reviews, guarantees, bundles) instead of discounts.
• Instrument login and email capture moments: If a user enters an email for a receipt or back-in-stock, identify them right there. That’s often your best bridge from anonymous browsing to known retention.

Common Mistakes to Avoid

Most retention underperformance looks like “creative isn’t working,” but the root cause is usually tracking and identity.

• Identifying too late: Waiting until purchase to call identify strands the most valuable intent events on anonymous profiles.
• Firing purchase on the wrong step: If you fire Order Completed on “checkout submitted,” you’ll suppress recovery for failed payments and lose revenue.
• Event name drift: Shipping add_to_cart on Android and Added to Cart on iOS creates duplicate logic and broken segments.
• Missing currency/price context: Without currency and numeric price fields, AOV-based branching and margin-aware offers become guesswork.
• Over-tracking low-signal events: Flooding Customer.io with noisy events makes it harder to build clean segments and increases the chance teams trigger campaigns off the wrong thing.

Summary

If you want reliable cart recovery, repeat purchase, and winback, your app needs to send clean, identity-aware events into Customer.io. Get identify right, standardize your commerce events, and validate purchase confirmation—then build orchestration on top of signals you actually trust.

Implement Track Events with Propel

If you’re already running retention in Customer.io, the fastest path is usually tightening the event spec, identity stitching, and property hygiene before you add more flows. When you want help pressure-testing your tracking plan against the cart recovery and repeat-purchase programs you’re trying to run, book a strategy call and we’ll map the exact events and payloads your app needs to send to make those campaigns perform.