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

Overview

If you want reliable retention automations, you need clean app-side events flowing into Customer.io—not “best effort” webhooks that arrive late or break when the frontend changes. If you’re rebuilding tracking or dealing with identity gaps between anonymous browsing and logged-in customers, it’s usually worth pressure-testing your event plan with a second set of eyes—book a strategy call and we’ll map the minimum viable event spec that actually powers repeat purchase and recovery.

In practice, the SDK is where retention teams win or lose: it’s the difference between “cart abandon” firing 60% of the time and a system you can confidently orchestrate across push, in-app, and email.

How It Works

SDK tracking is about sending two things consistently: (1) who the user is, and (2) what they did—at the moment it happened in the app. Customer.io stores those events on the person profile, then you use them to trigger campaigns, build segments, and suppress people who already converted.

• Identity first (stitching matters): The SDK can track activity for anonymous users (pre-login) and then associate that history to the known profile when you call identify. This is the backbone for “browse → add to cart → login → abandon” flows that otherwise get split across profiles.
• Events are your triggers: You send named events (like Product Viewed, Added to Cart, Checkout Started, Order Completed) with properties (SKU, price, category, cart value). Journeys and segments reference both the event name and its properties.
• Attributes are your targeting layer: Alongside events, you update person attributes (email, phone, push permission, last_order_date, lifetime_value). Attributes keep segmentation stable when event volume is high.
• Devices power push/in-app: On mobile, the SDK also manages device registration, which is what makes push and in-app messaging addressable. If device identity isn’t tied to the right person, your “winback push” goes to the wrong device—or nobody.

Real D2C scenario: A skincare brand sees a ton of “Added to Cart” events on iOS, but cart recovery is underperforming. The issue usually isn’t the message—it’s identity stitching. Users add to cart anonymously, then log in at checkout. If identify happens too late (or not at all), the abandon event stays on an anonymous profile and never triggers the recovery journey for the real customer.

Step-by-Step Setup

The goal here is simple: install the SDK, establish a consistent identity strategy, and ship a small set of high-signal events that map directly to retention plays (recovery, repeat purchase, reactivation). Don’t start by tracking everything—start by tracking what you’ll actually orchestrate against.

1. Install the Customer.io SDK in your app
   • Add the appropriate SDK for your stack (iOS/Android/React Native/Flutter/etc.).
   • Initialize it as early as possible in app startup so sessions and early events aren’t missed.
2. Define your identity plan (anonymous → known)
   • Decide what your canonical user identifier is (typically your internal customer_id).
   • Confirm when a user becomes “known” (account creation, login, checkout email capture).
   • Plan to call identify(customer_id, attributes) immediately at that moment—not later in the session.
3. Call identify with durable attributes
   • Send stable fields: email, phone (if you use SMS), first_name, country, timezone.
   • Send retention-critical computed attributes if you have them app-side: last_order_date, orders_count, lifetime_value. If those live server-side, keep them out of the SDK and update via your backend instead—mixed sources tend to drift.
4. Track the “money events” with properties
   • Product Viewed: sku, product_id, category, price
   • Added to Cart: sku, quantity, cart_value
   • Checkout Started: cart_value, items_count
   • Order Completed: ideally comes from your backend for accuracy, but if you must track app-side include order_id, revenue, discount_code
5. Validate event delivery and naming
   • Check that events appear on the correct person profile (not stuck on anonymous).
   • Confirm property types are consistent (numbers as numbers, timestamps formatted consistently).
   • Lock event names early—renaming later breaks existing segments and journey triggers.
6. Use events to orchestrate retention journeys
   • Trigger cart recovery on Checkout Started without Order Completed within X minutes/hours.
   • Trigger replenishment on Order Completed + product type + expected cadence.
   • Trigger reactivation when no App Opened or no purchase events occur within a defined window.

When Should You Use This Feature

SDK event tracking is the right move when you need retention triggers that are both timely and attributable to the right person—especially on mobile where email-only tracking falls apart. Most retention programs we’ve seen hit a ceiling when they rely on backend purchase events only; you need pre-purchase intent signals to recover revenue and personalize the next message.

• Cart and checkout recovery (mobile-heavy brands): When users abandon inside the app, SDK events are the only reliable way to know they started checkout and what was in the cart.
• Product discovery → repeat purchase loops: Track Product Viewed and Added to Cart to build “interested in X” segments and follow up with back-in-stock, bundles, or routines.
• Reactivation based on behavior, not just time: “No purchase in 60 days” is blunt. “Viewed category A twice this week but didn’t buy” is actionable.
• Identity stitching across anonymous browsing and logged-in purchase: If your funnel includes guest browsing, the SDK is where you prevent profile fragmentation that kills journey eligibility.

Operational Considerations

The SDK is easy to ship and surprisingly easy to get wrong. The operational work is making sure events stay stable as the app evolves, and that your segmentation and orchestration don’t depend on brittle properties.

• Segmentation design: Prefer segments based on a small number of well-defined events and a few durable properties (category, SKU, cart_value). If you segment on 12 different properties, someone will change one and your audience will silently collapse.
• Data flow ownership: Decide what is “source of truth” for purchase and revenue. In most D2C stacks, Order Completed should come from your backend or ecommerce platform for accuracy; app-side is fine for intent events.
• Orchestration realities: Build suppression logic that assumes duplicates and retries can happen. For recovery flows, always suppress on Order Completed regardless of how the user entered the journey.
• Anonymous-to-known merge timing: This tends to break when identify is called only on app launch, not on login. If a user logs in mid-session, you need to identify immediately or you’ll lose the pre-login intent events.
• Event volume and cost/complexity: Track fewer, higher-signal events. “Scroll depth” rarely drives retention outcomes; “Added to Cart” does.

Implementation Checklist

Before you build journeys off SDK events, make sure the foundation is solid. These are the checks that prevent weeks of debugging “why didn’t they enter?” later.

• SDK installed and initialized early in app lifecycle
• identify called on login/account creation (not just on cold start)
• Anonymous activity successfully stitches to the known profile after identify
• Core retention events implemented: Product Viewed, Added to Cart, Checkout Started, Order Completed
• Event properties standardized (types, naming, required fields)
• Purchase suppression event (Order Completed) is reliable and deduped (order_id)
• Test profiles show the full funnel in chronological order
• Segments built off events match expected users in QA

Expert Implementation Tips

The difference between “events exist” and “events drive revenue” is usually a handful of operator decisions: naming discipline, identity timing, and properties that map to merchandising and offers.

• Use an event naming convention you can live with for years: Title case, past tense (e.g., Added to Cart), and keep it consistent across platforms. If Android says add_to_cart and iOS says AddedToCart, your segments become a mess.
• Always include a stable product key: Send sku or product_id on every commerce-intent event. Category-only tracking limits you to generic follow-ups.
• Design for suppression first: For cart recovery, build the journey around “entered checkout” and exit on “order completed.” Don’t rely on a delay alone—people convert at unpredictable times.
• Keep revenue attribution clean: If the SDK fires Order Completed and your backend also fires it, you’ll double-count conversions and prematurely suppress people. Pick one source, or dedupe with order_id and strict rules.
• QA identity stitching with a realistic flow: Install app → browse → add to cart → login → abandon → reopen. If the abandon journey doesn’t trigger for the known user, fix identify timing before touching creative.

Common Mistakes to Avoid

Most “Customer.io isn’t working” complaints are actually tracking and identity issues. These are the ones that repeatedly show up in D2C app programs.

• Calling identify only after purchase: You lose the entire pre-purchase intent trail, which is exactly what powers recovery and discovery flows.
• Tracking carts without item detail: If Added to Cart doesn’t include SKU/category, you can’t personalize recovery or recommend substitutes when items go out of stock.
• Renaming events after journeys are live: Segments and triggers won’t match, and it fails silently until performance drops.
• Relying on app-side purchase events for truth: App events can fire twice, fail offline, or miss server-side adjustments (refunds, partial shipments). Use backend/platform events for financial truth when possible.
• Not testing anonymous merge: If anonymous profiles never merge, your recovery audience shrinks and you’ll chase “deliverability” or “creative” problems that aren’t real.

Summary

If you want retention journeys you can trust, implement SDK tracking with identity stitching as the priority. Start with a tight set of commerce intent events, standardize properties, and build suppression around a reliable purchase signal. Once the data is clean, cart recovery and repeat purchase flows become straightforward to operate and optimize.

Implement Track Events with Propel

If you’re wiring up SDK events and want them to map cleanly to real retention outcomes (recovery, replenishment, winback), it helps to treat tracking like an operational system—not a one-time dev task. We’ll typically review your identity plan, event spec, and suppression logic, then pressure-test it against how you’re actually orchestrating in Customer.io. If you want that kind of implementation support, book a strategy call and we’ll walk through your current tracking and what to fix first.