Track Events with the Customer.io SDK (Mobile/Web)

Overview

If you want retention programs to actually work, your app-side event tracking has to be boringly reliable—clean names, consistent properties, and identity stitching that doesn’t fall apart the moment someone logs in. Customer.io’s SDK path is how most D2C brands get there, because it captures real product behavior (not just pageviews) and turns it into segments and triggers inside Customer.io. If you want a second set of eyes on your tracking plan before you ship it, book a strategy call and we’ll pressure-test it like an operator would.

In most retention programs, the difference between “cart recovery prints money” and “cart recovery is noise” is whether your SDK events are accurate enough to (1) know what happened, (2) know who did it, and (3) know what they touched right before they bounced.

How It Works

At a mechanics level, SDK tracking is a three-part system: initialize the SDK in your app, identify the person when you can, and track events with properties that make segmentation and orchestration possible later.

• Install + initialize the SDK so the app can send data to Customer.io as users interact (mobile or web). Do this as early as possible in the app lifecycle so you don’t miss critical first-session behavior.
• Track events for the behaviors that actually map to retention outcomes (e.g., Product Viewed, Added to Cart, Checkout Started, Order Completed, Subscription Paused).
• Identify users when you have a stable identifier (login, account creation, or checkout). This is where identity stitching happens—anonymous browsing becomes attributable to a real customer profile once they authenticate.
• Attach the right properties to every event so you can personalize and filter later without rebuilding tracking. For D2C, that usually means SKU, product name, category, price, currency, quantity, cart value, and an order/cart ID.

A realistic scenario: someone opens your app from a paid ad, views two products, adds one to cart, then closes the app before checkout. If you only identify at purchase, you’ll never tie that abandoned cart to a person. If you identify at account creation/login (or capture an email/phone early), you can stitch those events and trigger a push + email recovery sequence with the exact SKU they left behind.

Step-by-Step Setup

The goal here is not “send events.” The goal is “send the minimum set of events that reliably powers revenue workflows, with identity stitching that survives real-world user behavior.” Set this up once, then keep it stable.

1. Pick your identity strategy before engineering starts.
   Decide what your canonical identifier will be (usually your internal customer ID). Also decide when you’ll call identify: login, account creation, email capture, or checkout.
2. Install the Customer.io SDK for your platform.
   Implement the SDK in your iOS/Android app (or web app if you’re using a web SDK). Initialize it on app start so first-session events don’t get dropped.
3. Implement identify at the first “known user” moment.
   When the user authenticates (or you capture a verified email/phone), call identify with your stable user ID and key attributes you’ll segment on (email, phone, acquisition source if available, loyalty tier, etc.).
4. Track your core retention events with consistent naming.
   Start with a tight set that maps directly to workflows:
   • Product Viewed (include sku, category, price)
   • Added to Cart (include cart_id, sku, quantity, cart_value)
   • Checkout Started (include cart_id, cart_value, items)
   • Order Completed (include order_id, total, items, discount_code)
5. Send attributes separately from events when they’re “state,” not “action.”
   Things like last_order_date, lifetime_value, subscription_status, and preferred_category usually behave better as profile attributes (updated on change) rather than event properties.
6. Validate in Customer.io Activity Logs before you build workflows.
   Confirm events arrive with the right user attached, correct timestamps, and complete properties. Don’t skip this—most retention breakage starts here.
7. Only then build triggers and segments.
   Once the data is stable, create segments like “Added to Cart in last 2 hours AND no Order Completed” or “Viewed Product Category = ‘Skincare’ 3+ times in 7 days.”

When Should You Use This Feature

SDK event tracking is the right move when you need high-fidelity behavior data that webhooks or order syncs can’t capture—especially when timing and product context matter for recovery and repeat purchase.

• Cart recovery that actually reflects app behavior: trigger based on Added to Cart or Checkout Started from the app, not just “checkout session created” on the backend.
• Product discovery → repeat purchase loops: if someone repeatedly views a category (say “protein powder”) but hasn’t purchased in 30 days, you can nudge with replenishment or bundles.
• Reactivation based on intent signals: “opened app” alone is weak. “Viewed 4 products and bounced” is a real signal you can act on.
• Subscription retention: track Subscription Skipped, Paused, Reactivated in-app so you can suppress the wrong messages and send the right save flows.

Operational Considerations

In practice, event tracking tends to break less from code and more from messy naming, inconsistent IDs, and teams building workflows on unstable properties. Treat your tracking plan like infrastructure.

• Segmentation depends on property discipline. If sku is sometimes SKU or nested differently across platforms, your segments will silently miss people.
• Identity stitching is the whole game. If you identify too late (only at purchase), you lose the ability to recover carts and browse abandon. Identify at login/account creation whenever possible.
• Decide where “truth” lives for purchase events. Many D2C teams track Order Completed from the backend for accuracy, then use SDK events for pre-purchase intent. Mixing sources is fine—just don’t double-count.
• Orchestration reality: suppression logic needs clean events. Your cart flow should exit on Order Completed with the same cart_id/order_id logic you used to enter, otherwise people keep getting recovery messages after they buy.
• Latency matters for recovery. If mobile events batch for too long, your “15-minute cart push” becomes a “3-hour cart push,” and performance drops. Tune batching/flush behavior to match your urgency.

Implementation Checklist

Before you call tracking “done,” you want confidence that events are accurate, attributable, and usable for segmentation without additional engineering.

• SDK installed and initialized on app start (mobile/web as applicable)
• identify implemented at login/account creation (not only at purchase)
• Event naming standardized (one canonical name per action)
• Core events implemented: Product Viewed, Added to Cart, Checkout Started, Order Completed
• Required properties present and consistent (sku, price, currency, quantity, cart_id/order_id)
• Tested anonymous → known stitching (browse, then login, then confirm event history attaches)
• Validated in Customer.io Activity Logs (correct profile, timestamps, properties)
• Built at least one segment and one trigger off each core event
• Suppression/exit conditions defined for recovery flows (purchase cancels recovery)

Expert Implementation Tips

If you want retention workflows to scale, optimize for “future segmentation” on day one. It’s cheaper to add the right properties now than to refactor 12 campaigns later.

• Track an items array for cart/order events (SKU, name, qty, price). Even if you don’t use it immediately, it unlocks dynamic content and better recommendations later.
• Always include a stable join key like cart_id and order_id. This is what makes exits, deduping, and attribution sane.
• Separate “category interest” from “category purchased.” Viewing behavior is top-of-funnel intent; purchase is outcome. Use both to avoid spamming buyers with discovery messages.
• Instrument “friction” events like Payment Failed or Address Error. These are gold for recovery and support deflection.
• Version your event schema internally. A simple spreadsheet with event names + required properties prevents the slow drift that kills segmentation accuracy.

Common Mistakes to Avoid

Most teams don’t fail because they didn’t track events—they fail because the events aren’t trustworthy enough to automate against.

• Identifying only after purchase. This kills cart/browse recovery because you can’t tie pre-purchase intent to a person.
• Using inconsistent event names across platforms. iOS sends add_to_cart, Android sends Added to Cart, web sends cart_add—now every segment is wrong.
• Missing core properties. An Added to Cart event without SKU or cart value forces generic messages and weak personalization.
• Double-counting purchases. Tracking Order Completed from both SDK and backend without dedupe inflates conversion and breaks exit logic.
• Building workflows before validating the data. If you don’t confirm identity stitching and property presence in logs, you’ll debug campaigns forever.

Summary

If you’re serious about cart recovery, repeat purchase, and reactivation, SDK event tracking is the foundation—not the nice-to-have. Get identity stitching right, keep event names consistent, and attach properties you’ll actually segment on.

Once the data is stable, your retention workflows become straightforward to orchestrate and much easier to optimize.

Implement Track Events with Propel

When teams implement SDK tracking fast, they usually ship “some events” and then spend weeks cleaning up naming, IDs, and stitching once campaigns start misfiring. If you want to avoid that loop, we’ll map the retention use cases first (cart recovery, replenishment, winback), then translate them into a tight event schema that works cleanly inside Customer.io. If that would help, book a strategy call and we’ll walk through your app flows and instrumentation plan.

The outcome you’re aiming for: events you can trust, segments that don’t leak, and journeys that trigger on real intent—not guesswork.