Track Events with the Customer.io SDK (for Retention Programs)

Overview

If you want Customer.io to drive repeat purchase and recovery flows off real customer behavior, your SDK events need to be consistent, attributable, and stitched to the right person—every time. If you’re tightening up tracking before scaling automations (or you’ve already felt the pain of “why didn’t they enter the cart flow?”), it’s usually worth a quick audit—book a strategy call and we’ll pressure-test your event plan against how Customer.io actually segments and triggers.

At a practical level, “Track events” is how you turn app behavior into retention levers: cart recovery, browse abandonment, replenishment nudges, post-purchase cross-sell, and winback—without relying on brittle pageview hacks or delayed warehouse syncs.

How It Works

In retention programs, SDK tracking lives or dies on identity stitching. The SDK sends two core things into Customer.io: (1) who the user is (identify) and (2) what they did (track). Customer.io then uses those events to power segments and to trigger campaigns/Journeys in close to real time.

• Identify anchors events to a person. When a user logs in, creates an account, or you otherwise know who they are, the app calls identify(userId, attributes). From that point on, events tie cleanly to that profile.
• Anonymous activity still matters—if you merge it. Many D2C apps see high-intent browsing before login. The SDK can collect anonymous events, but you need a plan to merge anonymous activity into the identified profile after signup/login. In practice, this tends to break when teams fire identify too late (after checkout) or inconsistently (only on some screens).
• Track events are your behavioral building blocks. Events like Product Viewed, Added to Cart, Checkout Started, and Order Completed become triggers, filters, and segment conditions. The event name and its properties (SKU, category, cart value, etc.) determine how targeted your retention can get.
• Event properties are what make messages feel “1:1”. If you send “Still thinking it over?” without the product name, image, or price, you’ll see recovery rates stall. Those should come directly from event payloads (or from objects, but the SDK event is usually the first step).

Real D2C scenario: A shopper in your mobile app views three products, adds one to cart, then gets distracted. If you’ve implemented identify at login and track on Added to Cart with product + cart properties, you can trigger a push within 30 minutes, then an email later that day, and suppress both if Order Completed fires. Without clean event tracking, you’ll either over-message (no suppression) or miss the recovery window entirely.

Step-by-Step Setup

The goal here isn’t “send events.” The goal is: every high-intent action reliably lands in Customer.io with the right user attached, so your recovery and repeat-purchase orchestration doesn’t leak.

1. Install the right Customer.io SDK for your app.
   Use the platform SDK (iOS/Android) or your framework SDK (React Native/Flutter/Expo). Make sure you’re on a current version before you design the event plan—older implementations are where identity and device handling usually get weird.
2. Initialize the SDK at app start.
   Initialize as early as possible so you don’t miss “first session” events (product discovery and browse are often your highest-volume signals).
3. Define your identity strategy (this is the non-negotiable part).
   Pick a stable userId (typically your internal customer ID). Decide when you’ll call identify:
   • On login success
   • On account creation
   • On app relaunch if the user is already authenticated (so events from the next session attach correctly)
4. Call identify with retention-relevant attributes.
   At minimum: email/phone (if you use those channels), first/last name, locale, and any lifecycle flags you trust (e.g., first_order_date, vip_tier). Don’t dump your entire user table—only attributes you’ll actually segment on or personalize with.
5. Implement track for your retention-critical events.
   Start with a tight set that maps to revenue:
   • Product Viewed (include product_id, name, category, price)
   • Added to Cart (include cart_id, value, items)
   • Checkout Started (include value, shipping_method if known)
   • Order Completed (include order_id, value, items, discount_code)
   Keep event names consistent across platforms—Customer.io treats Added to Cart and add_to_cart as different events.
6. Handle anonymous-to-known merging.
   If your app supports browsing before login, ensure anonymous events are merged when you identify. Test it explicitly: view product anonymously → login → confirm the event appears on the identified profile activity timeline.
7. Verify events in Customer.io before building automations.
   Use the Activity Log / person profile event stream to confirm:
   • Event names match exactly
   • Properties arrive as expected (types matter—numbers as numbers, timestamps as timestamps)
   • Events attach to the correct profile (not duplicates)

When Should You Use This Feature

SDK event tracking is the right move when you need reliable, real-time behavioral signals from the app—especially when email alone isn’t enough and you’re coordinating push, SMS, and in-app.

• Cart recovery in mobile-first funnels. If checkout happens in-app, server-side “order created” events arrive too late to catch abandonment. Checkout Started and Added to Cart are your early warning signals.
• Browse abandonment and product discovery. Trigger a “still considering?” push based on Product Viewed with category/SKU properties, then suppress if they add to cart.
• Repeat purchase and replenishment. Use Order Completed item properties to drive replenishment timing (e.g., 21/30/45 days by product type) and cross-sell based on category affinity.
• Reactivation based on true inactivity. App events let you define “inactive” as no sessions + no key events, not just “hasn’t purchased.” That’s how you avoid discounting people who are actively browsing.

Operational Considerations

Most tracking plans look fine in a spec doc and then fall apart in production because of identity drift, inconsistent payloads, and orchestration gaps between channels. These are the things to lock down early so your segments and suppression logic stay trustworthy.

• Segmentation depends on event hygiene. If half your app sends productId and the other half sends product_id, you’ll end up building duplicate segments and your targeting will quietly degrade.
• Data flow timing impacts recovery rate. For cart recovery, minutes matter. SDK events typically arrive fast; warehouse syncs often don’t. Use SDK events for triggers/suppression, then enrich later if needed.
• Identity stitching affects frequency control. Duplicate profiles (anonymous + known not merged, or multiple IDs per person) lead to double sends and broken holdouts. In most retention programs, we’ve seen “mystery over-messaging” trace back to identity, not frequency settings.
• Orchestration needs explicit suppression events. If you trigger off Added to Cart, you also need a clean Order Completed (and ideally Cart Emptied) to stop messages. Don’t rely on “wait 24 hours and hope.”
• Property typing matters for filters. A cart value sent as a string breaks numeric comparisons (e.g., “only message carts > $75”). Decide types once and enforce them.

Implementation Checklist

Before you build or refactor automations, run through this list. It’s the difference between a flow that prints money and a flow that mostly prints questions in Slack.

• SDK installed and initialized early in the app lifecycle
• identify called on login, signup, and authenticated app relaunch
• Stable userId chosen (not email, not device ID)
• Anonymous browsing events are merged into known profiles after identify
• Standardized event names across iOS/Android/web (exact string match)
• Core revenue events implemented: Product Viewed, Added to Cart, Checkout Started, Order Completed
• Event properties include the minimum needed for personalization + segmentation (SKU/category/value/items)
• Suppression events exist and are reliable (purchase cancels cart/browse flows)
• Events verified in Customer.io person activity feed with correct property types

Expert Implementation Tips

Once the basics are in, these are the operator moves that usually unlock better recovery and higher LTV without spamming.

• Design events around decisions, not screens. “Viewed PDP” is less useful than Product Viewed with product context. You want events that map to: recover, upsell, replenish, or suppress.
• Send the full cart payload on Added to Cart (not just the last item). Recovery messages perform better when they reflect the actual cart state. If you only send the last SKU, your email will look wrong the moment someone adds a second item.
• Use consistent item schemas. Keep items as an array of objects with the same keys everywhere (e.g., product_id, name, qty, price). This saves hours when you build Liquid later.
• Track “session start” or “app opened” intentionally. For reactivation, you need a clean activity signal. But don’t overuse it as a trigger—use it as a filter (“active in last X days”).
• Test identity edge cases. Logout/login, account switching, reinstalling the app—these are where duplicate profiles and mis-attribution show up first.

Common Mistakes to Avoid

These are the mistakes that create silent failure—campaigns still send, but performance tanks and you can’t trust your reporting.

• Calling identify only at checkout. You’ll lose attribution for browse/cart behavior and your recovery triggers won’t attach to a person.
• Using email as the primary ID. Emails change, get aliased, and create duplicates. Use a stable internal ID and store email as an attribute.
• Inconsistent event naming between platforms. iOS sends AddedToCart, Android sends Added to Cart—now you have two segments, two triggers, and half the audience in each.
• Forgetting suppression. Triggering cart recovery without a reliable Order Completed event is how you message people after they bought—guaranteed complaints.
• Sending huge payloads “just in case.” Bloated properties make debugging harder and increase the chance of schema drift. Send what you’ll use.
• Not validating property types. Values as strings, timestamps in random formats, arrays that sometimes come through as JSON strings—your segments will misbehave.

Summary

If your retention engine runs on behavior, SDK event tracking is the foundation: identify cleanly, track consistently, and merge anonymous activity so you don’t lose intent. Get the core commerce events right first, then expand once your cart recovery and post-purchase flows are stable.

Implement Track Events with Propel

When teams ask why a cart flow is underperforming in Customer.io, it’s usually not the copy—it’s missing or mis-attributed events, inconsistent schemas, or suppression that doesn’t fire. If you want a second set of eyes on your SDK instrumentation plan (and how it maps to segments, triggers, and channel orchestration), book a strategy call and we’ll walk through what to track, where it tends to break, and how to make the data trustworthy enough to scale.