Track Events (SDK) in Customer.io: the retention-grade way to instrument your app

Overview

If you want retention campaigns that react to real customer behavior (not guesses), you need clean event tracking feeding Customer.io from your app. If you’re trying to untangle identity stitching, event naming, and what to track first, book a strategy call—most teams don’t need “more events,” they need the right few events wired correctly.

In practice, event tracking is what turns Customer.io from a sender into a retention engine: cart recovery that knows what’s in the cart, replenishment that knows what was purchased, and reactivation that knows what someone last engaged with.

How It Works

At a mechanics level, the SDK sends two kinds of data to Customer.io: identity (who the user is) and events (what they did). The retention win comes from getting the sequence right so anonymous behavior (like browsing) gets stitched to the known profile (after login/checkout), and from sending event properties that make segmentation and personalization actually usable.

• Install the SDK in your mobile app (iOS/Android/React Native/etc.) or web app so events fire client-side when the behavior happens.
• Track anonymous activity early (product views, add-to-cart) before a user logs in. This is where most cart recovery programs either become great or useless.
• Identify the user the moment you have a stable customer identifier (login, account creation, or checkout). This is the stitching moment—Customer.io can associate pre-identify events with the now-known profile when implemented correctly.
• Track events with properties that you’ll actually use downstream (SKU, product name, category, price, quantity, cart value, currency, variant). Without properties, you’ll end up with generic messages and weak segments.
• Use events to drive orchestration in Journeys: triggers (entered checkout), filters (has purchased in last 7 days), branching (high AOV vs low AOV), and goals (purchase completed).

Real D2C scenario: A shopper browses your app, adds a vitamin bundle to cart, then closes the app. If you tracked Product Viewed and Added To Cart anonymously, then call identify when they create an account later, Customer.io can still power a cart recovery push/email that references the exact bundle and value—without you building brittle backend joins.

Step-by-Step Setup

The fastest path is to instrument a small set of “money events” end-to-end, validate identity stitching, and only then expand coverage. Most retention programs we’ve seen stall because teams ship 40 events and can’t trust any of them.

1. Pick your canonical identifiers.
   Decide what Customer.io should treat as the stable customer ID (usually your internal user ID). Also decide what secondary identifiers you’ll attach as attributes (email, phone) for channel delivery.
2. Install the appropriate Customer.io SDK.
   Implement the SDK for your platform (iOS/Android/React Native/Flutter/Web). Confirm you’re sending to the right workspace/environment (prod vs staging) so QA doesn’t pollute real segments.
3. Start tracking key anonymous events immediately.
   Instrument events like Product Viewed, Collection Viewed, Added To Cart, and Checkout Started even before login. Keep names consistent and human-readable.
4. Call identify at the first reliable moment.
   When the user logs in, creates an account, or completes checkout, call identify with your stable ID and set core attributes (email/phone, country, acquisition source if you have it). This is where you win or lose cross-session stitching.
5. Track purchase and fulfillment milestones.
   At minimum: Order Completed with order_id, value, currency, and line items. If you have subscription/replenishment, also track Subscription Created, Subscription Canceled, Shipment Delivered.
6. Standardize event properties for personalization.
   For cart and product events, include: sku, product_name, variant, category, price, quantity, cart_value. The goal is to support “show me what they left behind” and “recommend adjacent items” without extra data plumbing.
7. Validate in Customer.io Activity Logs.
   Confirm events arrive on the expected profile, confirm timestamps match reality, and confirm anonymous-to-known stitching works by reproducing: browse anonymously → add to cart → identify → check profile timeline.
8. Wire events into Journeys with goals and exits.
   For cart recovery, trigger on Added To Cart or Checkout Started, then exit on Order Completed. This prevents the classic “thanks for your order—complete your purchase” mistake.

When Should You Use This Feature

SDK event tracking is the right move when you need behavioral precision and real-time triggers. If you’re relying on nightly imports or only purchase events, you’ll always be late to the moment that actually converts.

• Cart recovery in-app and push when the cart lives client-side or changes quickly (common in mobile-first D2C). Trigger on Checkout Started and personalize with cart contents.
• Product discovery loops like “viewed X but didn’t add” or “viewed category Y twice this week.” These are high-intent segments that outperform broad promos.
• Repeat purchase and replenishment when you can track consumption signals (e.g., Started Using, Refill Reminder Eligible) or at least purchase cadence with Order Completed.
• Reactivation based on app engagement decay (e.g., last App Opened or last Product Viewed) rather than just “hasn’t purchased.”

Operational Considerations

Once events start flowing, the real work is making them trustworthy for segmentation and orchestration. This tends to break when mobile, web, and backend teams all emit slightly different events and retention has to guess which one is “real.”

• Segmentation depends on event consistency.
  If iOS sends AddedToCart and Android sends Add To Cart, your segments will silently undercount. Lock a naming spec and enforce it in code review.
• Identity stitching is a retention lever.
  If you identify too late (only after purchase), you lose the ability to recover carts where the user signs up after browsing. Identify at account creation/login, not just order completion.
• Data flow reality: client events can be duplicated.
  Apps retry on poor networks; users double-tap. Add idempotency where possible (e.g., include event_id or use unique order_id for purchases) and design Journeys with frequency controls.
• Orchestration needs clear “stop” events.
  Every revenue Journey should have a goal/exit event (usually Order Completed) and a suppression window to prevent over-messaging recent buyers.
• Property hygiene matters more than volume.
  Five events with strong properties beat 50 events with empty payloads. Your future self building segments will thank you.

Implementation Checklist

Use this to ship a retention-ready tracking layer without getting stuck in instrumentation purgatory.

• SDK installed and sending to correct workspace/environment
• Canonical customer ID defined (stable, non-email) and used in identify
• Anonymous events tracked pre-login (at least view + cart + checkout start)
• identify called at login/account creation (not only at purchase)
• Core events implemented: Product Viewed, Added To Cart, Checkout Started, Order Completed
• Event properties standardized (SKU, name, variant, price, quantity, cart_value, currency)
• Purchase event includes unique order_id and total value
• Validated in Activity Logs: timestamps, properties, and stitched identity
• Journeys configured with exit on purchase + frequency controls

Expert Implementation Tips

The difference between “events are flowing” and “events drive revenue” is usually a handful of operator decisions that prevent messy segments and leaky automations.

• Model cart as a snapshot, not a single SKU.
  For Added To Cart and Checkout Started, include an array of line items plus cart_value. Cart recovery performs better when you can show the top item and total value.
• Send one purchase event per order.
  If your app fires Order Completed multiple times (confirmation screen + receipt screen), dedupe using order_id and suppress re-entry in Journeys.
• Keep event names stable; evolve with properties.
  Renaming events breaks historical segments. Add a property like source or screen instead of creating Added To Cart - PDP vs Added To Cart - Search.
• Instrument “intent” events for better reactivation.
  For example, track Search Performed with query or Quiz Completed with result. These give you angles beyond discounts when bringing people back.

Common Mistakes to Avoid

These are the issues that show up later as underperforming flows, broken segments, and customers getting the wrong message at the worst time.

• Identifying users with email as the primary ID.
  Emails change; internal IDs don’t. Use email/phone as attributes for delivery, not as your core identity key.
• Only tracking server-side purchases and nothing else.
  You’ll have “post-purchase” retention, but your cart recovery and product discovery programs will be blind.
• Missing exit conditions in Journeys.
  If cart recovery doesn’t exit on Order Completed, you will inevitably send recovery messages to buyers.
• Over-instrumenting without a naming spec.
  When every team invents their own event names, segmentation becomes a forensic exercise and confidence drops.
• Not validating anonymous-to-known stitching.
  Teams assume it works, ship flows, and then wonder why “added to cart” segments are tiny. Always test the full funnel on a fresh install.

Summary

If you want Customer.io to drive repeat purchase, cart recovery, and reactivation, SDK event tracking is the foundation. Get identity stitching right, track a tight set of money events with strong properties, and build Journeys with clean exits. If any of those pieces are shaky, performance will be too.

Implement Track Events with Propel

If you’re implementing SDK tracking and want it to hold up under real retention pressure (multi-platform naming, identity stitching, dedupe, and Journey-ready properties), we can help you get it right the first time inside Customer.io. When it’s helpful, book a strategy call and we’ll map the exact events/properties you need for cart recovery, replenishment, and reactivation—based on how your app and checkout actually behave.