Get Started with Customer.io SDK Tracking (So Retention Flows Actually Fire)

Overview

If you’re using Customer.io for retention, the SDK is the difference between “we sent a cart flow” and “we sent a cart flow to the right person, at the right time, with the right items.” If you want a second set of eyes on your tracking plan before you bake it into your app release cycle, book a strategy call—it’s usually faster than debugging identity issues after the fact.

The goal of SDK setup isn’t “get data into Customer.io.” It’s to create dependable identity stitching and event timing so cart recovery, repeat purchase, and reactivation automations trigger cleanly and don’t spam the wrong profiles.

How It Works

In practice, Customer.io retention programs live or die on two things: (1) how you identify a person, and (2) whether the events you track match the decisions you want to automate. The SDK sits in your app (mobile or web) and sends Customer.io two streams of information: person updates (attributes) and behavioral events.

• People (profiles) are created/updated when you call identify with a stable identifier (almost always your internal user ID, sometimes email as a secondary attribute). This is what Customer.io uses to build segments like “Purchased 2+ times” or “Viewed product but didn’t add to cart.”
• Anonymous activity is captured when someone browses before logging in. Then, when they authenticate, you stitch that anonymous history onto the known profile by calling identify at login/signup. This is where most cart recovery programs break: the cart event lands on an anonymous profile, but the email goes to the known profile—so nothing sends.
• Events drive automation entry (e.g., product_viewed, added_to_cart, checkout_started, order_completed). You’ll typically trigger campaigns off these events, then use event properties (like SKU, category, cart value) to personalize and branch.
• Devices matter for push. If you plan to use push notifications, you need device registration tied to the same identified profile; otherwise you’ll see “sent” but not “delivered” outcomes because the device never got associated correctly.

Real D2C scenario: A shopper adds a cleanser + moisturizer to cart on mobile, then creates an account at checkout. If you track added_to_cart anonymously but don’t stitch on signup, your cart flow either won’t fire or will fire without items. With clean stitching, you can send a push 30 minutes later showing the exact products, then an email the next morning with a bundle incentive if cart value is above your threshold.

Step-by-Step Setup

Before you touch any automation, get the SDK foundation right. You want stable identity, consistent event names, and a small set of high-signal attributes—otherwise segmentation becomes fragile and orchestration turns into guesswork.

1. Create your workspace and grab credentials
   In Customer.io, set up the workspace you’ll use for production data. Pull the site/app credentials you’ll need for the SDK initialization (keep dev/staging separate from prod if you can—mixing data ruins segmentation).
2. Install the appropriate Customer.io SDK
   Add the SDK to your mobile app (iOS/Android/React Native/Flutter, etc.) or web app, following Customer.io’s Mobile SDK docs for your platform. Do this in a way that supports environment toggles (dev vs prod) so QA doesn’t pollute real customer profiles.
3. Initialize the SDK early in app lifecycle
   Initialize on app start so you capture pre-login browsing and can attach device context for push. If initialization happens late, you’ll miss early funnel events (product views, category browsing) that are useful for discovery and reactivation segments.
4. Implement identify on login/signup
   Call identify immediately after authentication with a stable id (your internal user ID). Include email as an attribute (not necessarily as the primary ID) and any high-signal attributes you’ll segment on (e.g., first_name, customer_status, acquisition_source, sms_opt_in).
5. Stitch anonymous to known consistently
   Make sure the same device/session that generated anonymous events calls identify once the user becomes known. In most retention programs, we’ve seen this fail when login happens in a webview, or when the app uses multiple auth states and only identifies on “full account creation.”
6. Track your core retention events with properties
   Start with a minimal, reliable taxonomy:
   • product_viewed: sku, product_name, category, price
   • added_to_cart: cart_id, items (array), cart_value, currency
   • checkout_started: cart_id, cart_value, shipping_country
   • order_completed: order_id, items, revenue, discount_code, is_subscription
   These properties become the levers for personalization (show the exact product) and orchestration (branch: high AOV vs low AOV).
7. Update person attributes at meaningful lifecycle moments
   Use attribute updates for durable state, not every click. Examples: last_order_date, orders_count, lifetime_value, preferred_category. This makes segments stable and reduces reliance on complex event-based logic.
8. Validate in Customer.io before building automations
   Open a few test profiles and confirm: events show up on the right person, timestamps look correct, and properties are populated. If the cart event is landing on an anonymous profile while the email exists on a known profile, fix identity before you ship flows.

When Should You Use This Feature

The SDK matters most when you need accurate, real-time behavioral triggers and cross-session identity. If your retention plan relies on “what they did in the app” (not just orders in Shopify), SDK tracking is usually the backbone.

• Cart recovery that actually personalizes: trigger on added_to_cart or checkout_started, then render items, value, and category-based incentives.
• Repeat purchase timing: trigger replenishment nudges off order_completed + product type (e.g., 21 days for skincare, 45 days for supplements) using item properties.
• Reactivation based on browsing intent: if someone hasn’t purchased in 90 days but has product_viewed in the last 7, that’s a very different message than a cold winback.
• Push-first retention: device-level tracking and identity association are required if push is a meaningful channel for you.

Operational Considerations

Once you move past “events are firing,” the real work is making the data usable for segmentation and orchestration. This is where teams either build a clean retention engine—or end up with brittle flows that require constant patching.

• Segmentation depends on durable attributes: if every segment requires event gymnastics, it’ll be slow to build and hard to maintain. Promote key states (VIP tier, last purchase date, subscription status) into person attributes.
• Event naming consistency is non-negotiable: pick a taxonomy and stick to it. Changing order_completed to purchase mid-quarter will silently break triggers and reporting.
• Identity stitching impacts deliverability and frequency: duplicates inflate audience size, distort conversion rates, and can cause over-messaging when the same human has multiple profiles.
• Data flow realities: mobile events can arrive late or out of order. Don’t build orchestration that assumes perfect sequencing (e.g., “checkout_started always happens after added_to_cart”). Use guardrails like “has not purchased since event” checks.
• Channel orchestration needs a single source of truth: if email opt-in lives in one system and SMS opt-in lives in another, mirror those flags into Customer.io attributes so your journeys don’t guess.

Implementation Checklist

Use this as the pre-flight check before you start wiring campaigns. If you can’t check these off, you’ll spend your time debugging instead of iterating offers and creative.

• SDK installed and initialized in the correct environment (dev/staging/prod separated)
• identify fires on login/signup with stable internal user ID
• Anonymous browsing/cart events stitch to the known profile after auth
• Core retention events implemented: product_viewed, added_to_cart, checkout_started, order_completed
• Event properties include identifiers (SKU/order_id/cart_id) and value fields (revenue/cart_value/currency)
• Person attributes support segmentation (orders_count, last_order_date, LTV, subscription status, opt-in flags)
• Test profiles confirm events land on the correct person with correct timestamps

Expert Implementation Tips

These are the operator moves that keep your retention machine stable when traffic scales and the app team ships changes.

• Use internal user ID as primary identity: emails change; IDs don’t. Store email as an attribute and update it when it changes.
• Send “items” as a structured array: it’s the difference between “You left something behind” and “You left the 2-pack moisturizer behind.” Your cart and post-purchase flows get dramatically better.
• Track order_completed from the source of truth: if you have both app-side and backend confirmations, prefer the one that reflects a real successful payment to avoid false positives entering post-purchase.
• Build a thin event layer in your app: don’t sprinkle SDK calls everywhere. Centralize tracking so event names/properties don’t drift across screens and releases.
• QA with real journeys, not just event logs: run a test user through browse → cart → login → purchase, then confirm they enter/exit the right campaigns and don’t get recovery messages after purchase.

Common Mistakes to Avoid

Most “Customer.io isn’t working” issues are really tracking and identity issues. Fix these early and your retention team stops fighting fires.

• Identifying too late: waiting until after purchase to call identify means cart and browse intent never attaches to the person you can message.
• Using email as the only identifier: it creates messy merges when people change emails or check out with Apple private relay.
• Tracking cart as a single number: if you only send cart_value and not items, you can’t personalize or recommend alternatives when something goes out of stock.
• Event spam: firing product_viewed on every scroll or image carousel interaction bloats data and makes intent harder to read.
• Ignoring duplicates: multiple profiles per person will inflate sends and distort conversion attribution—especially painful in reactivation where frequency control matters.

Summary

If you want cart recovery, replenishment, and winback flows you can trust, start with SDK identity and a tight event taxonomy. Get identify and stitching right, track a small set of high-signal events with useful properties, then build segments and journeys on top of stable attributes.

Implement 1.x with Propel

When teams implement SDK tracking, the hard part usually isn’t the install—it’s deciding what to track, where identity can break, and how to structure properties so campaigns stay flexible. If you’re building or refactoring your Customer.io event layer and want an operator’s take on the tracking plan and retention triggers, book a strategy call and we’ll pressure-test it against your cart, post-purchase, and reactivation goals.