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

Overview

If you want Customer.io to drive repeat purchase and recovery flows that actually feel timely, your SDK event tracking has to be clean: correct identity, consistent event names, and the right properties on every event. If you’re trying to tighten this up quickly across web + app, it’s usually faster to book a strategy call and map the exact events and stitching rules before you ship more noise into your workspace.

In most retention programs, the difference between “we have events” and “our automations print revenue” is whether events represent real customer intent (viewed product, started checkout, added payment) and whether those events reliably attach to the same person across sessions and devices.

How It Works

At a practical level, SDK tracking is how you turn in-app behavior into triggers, segments, and message personalization. The SDK sends two things to Customer.io: (1) identity signals (who this is) and (2) behavioral events (what they did), plus properties that explain context.

• Install the SDK in your mobile app (iOS/Android/React Native/etc.) or web app so events fire client-side at the moment actions happen.
• Identify the user as soon as you have a durable identifier (login, account creation, or verified email/phone). This is the backbone for identity stitching.
• Track events for high-intent actions (e.g., Product Viewed, Added to Cart, Checkout Started, Order Completed) with consistent properties like product_id, variant_id, price, currency, cart_id, and quantity.
• Handle anonymous-to-known stitching so pre-login activity (browsing, cart building) attaches to the same person after they authenticate. In practice, this tends to break when teams only identify on “account created” and not on “login,” or when they rotate user IDs.
• Use event properties for orchestration: properties become filters (only abandonments over $50), branching logic (category = skincare), and personalization (show the exact items they left behind).

Real D2C scenario: A shopper browses on mobile, adds a bundle to cart, then bounces. If your SDK fires Added to Cart with cart_id and item-level properties and you identify them when they enter email at checkout (or when they log in), Customer.io can trigger a cart recovery push/email with the exact bundle, not a generic “come back.” Without stitching, that cart event sits on an anonymous profile and your recovery flow never fires for the real customer.

Step-by-Step Setup

The goal here is simple: get to a place where every meaningful action in your app produces a reliable event on a single person profile. Do this in order—teams that skip identity first usually spend weeks debugging “missing” conversions.

1. Install the Customer.io SDK for your platform (iOS/Android/web framework). Confirm it initializes once per app session and uses the correct site/workspace credentials.
2. Decide your canonical identifier (usually your internal customer_id or user_id). Treat email/phone as attributes, not the primary key, unless your system truly uses email as the durable ID.
3. Implement Identify at the moment you can confidently tie behavior to a real person:
   • On login (not just on signup)
   • On account creation
   • On checkout email capture if your UX collects email before payment (common in D2C)
4. Implement core retention events and keep naming consistent across platforms:
   • Product Viewed (include product_id, category, price)
   • Added to Cart (include cart_id, line items, value)
   • Checkout Started (include cart_id, value, payment_method_available)
   • Order Completed (include order_id, value, items, discount_code)
5. Send item context as properties. If you can’t send full line items, at least send top_item_id, item_count, and value so you can segment and personalize.
6. Validate in Customer.io by checking:
   • The person profile shows the right identifier and attributes
   • The event appears with properties populated
   • Anonymous activity merges into the known profile after identify
7. Wire events into journeys (cart recovery, replenishment, winback) only after you’ve seen a clean end-to-end test: anonymous browse → identify → event triggers → message sends.

When Should You Use This Feature

SDK event tracking matters most when timing and context drive conversion—especially on mobile where a lot of intent never hits your backend until it’s too late. If you’re trying to improve recovery and repeat purchase, app-side events are often the missing layer.

• Cart recovery on mobile where the cart is built in-app and may not sync to your ecommerce backend until checkout. SDK events let you trigger within minutes, not hours.
• Browse-to-buy nudges like “Still thinking about the hydration bundle?” based on Product Viewed frequency and category affinity.
• Reactivation when churn shows up as “no app activity,” not just “no orders.” App events like App Opened or Category Viewed help you suppress winbacks for already-active users.
• Post-purchase CX that drives LTV (how-to content, reorder education) triggered by Order Completed plus item properties.

Operational Considerations

Once events are flowing, the work becomes operational: keeping naming stable, making segments trustworthy, and ensuring journeys don’t fight each other. This is where most retention programs either scale cleanly or slowly degrade.

• Segmentation depends on property hygiene. If category is sometimes “Skin Care” and sometimes “skincare,” your category-based cross-sell segments will leak. Normalize values at the source.
• Identity stitching is the make-or-break. If a user browses anonymously and you only identify after purchase, your recovery programs will undercount and you’ll over-message “new” profiles. Identify earlier (login/email capture) and keep the ID stable.
• Event volume vs signal. Track the actions that change intent. Don’t fire Button Clicked for everything and expect clean orchestration later—Customer.io will faithfully ingest noise.
• Cross-platform consistency. If web uses Added To Cart and iOS uses add_to_cart, you’ll end up duplicating journeys or missing users. Pick one schema and enforce it.
• Orchestration realities. If you run cart recovery in both your ecommerce platform and Customer.io, customers get double-tapped. Decide which system is the source of truth for each flow and suppress accordingly.

Implementation Checklist

Before you build more journeys, get these basics locked. This checklist is the fastest way to avoid weeks of “why didn’t they enter the campaign?” debugging.

• SDK installed and initializing once per session
• Canonical customer_id/user_id chosen and documented
• Identify called on login and account creation (and on checkout email capture if applicable)
• Anonymous activity successfully merges into known profiles after identify
• Core events implemented with consistent naming across platforms
• Each core event includes required properties (product_id, cart_id, order_id, value, currency)
• At least one end-to-end test proves: event → segment/journey trigger → message send
• Suppression rules defined to prevent duplicate recovery messaging across tools

Expert Implementation Tips

These are the patterns that tend to hold up once you’re sending at scale and iterating weekly, not just “getting data in.”

• Design events around decisions. If an event won’t change a segment or branch in a journey, it’s probably not worth tracking client-side.
• Prefer fewer events with richer properties. One Added to Cart event with item arrays beats five different cart events that you later have to reconcile.
• Track “value” everywhere you can. Even rough value lets you prioritize: recover high-AOV carts faster, hold back discounts for low-risk buyers.
• Use a shared tracking plan. In practice, this tends to break when iOS and Android ship independently. Keep a single schema doc and treat changes like API versioning.
• Validate identity on real devices. Emulators often hide push permission flows and deep link behavior that impacts when identify/event calls happen.

Common Mistakes to Avoid

Most “Customer.io isn’t working” issues are actually tracking issues. Fix these and your journeys usually stabilize immediately.

• Identifying too late. If you only identify after purchase, you’ll miss cart recovery and browse-based personalization for a huge share of sessions.
• Changing user IDs. Rotating IDs or using session IDs as the identifier fragments profiles and kills LTV measurement.
• Inconsistent event names across platforms. You’ll end up with duplicate segments and unreliable triggers.
• Missing required properties. A cart event without cart_id or value forces generic messaging and weak prioritization.
• Over-tracking low-signal events. Flooding Customer.io with UI events makes segmentation slower and analysis noisier, and it distracts from revenue-driving triggers.

Summary

If you want Customer.io to perform like a retention engine, your SDK needs to do three things reliably: identify the person, stitch anonymous intent, and send high-signal events with usable properties. Get that foundation right and cart recovery, repeat purchase, and reactivation flows become straightforward to orchestrate.

Implement Track Events with Propel

If you’re already on Customer.io and your events feel “mostly there” but journeys still miss people, it’s usually an identity stitching or schema consistency issue—not a campaign problem. We’ll typically start by auditing identify timing (login vs checkout vs post-purchase), then tighten the event/property spec so your recovery and repeat purchase segments stop leaking.

If you want a second set of operator eyes on your tracking plan and how it maps to retention flows, book a strategy call.