Identify people (SDK) in Customer.io for retention-grade tracking

Overview

If you want Customer.io to drive repeat purchase, cart recovery, and reactivation reliably, your identity layer has to be clean—especially on mobile. Identify is the moment you tell Customer.io “this device/session belongs to this person,” which is what makes downstream segmentation and orchestration work. If you want a second set of eyes on your tracking plan before you wire it into production, you can book a strategy call and we’ll pressure-test it like an operator would.

In most D2C retention programs, the biggest hidden leak isn’t creative—it’s mis-attributed behavior (anonymous browsing, logged-in sessions, and purchases landing on different profiles). Identify is how you stop that from breaking your cart recovery and post-purchase flows.

How It Works

On app and web, users often start anonymous, then become known when they log in, create an account, or you capture an email/phone at checkout. Identify stitches those worlds together so events and attributes roll up to one person profile in Customer.io.

• Before Identify: events can still fire, but they’re tied to an anonymous profile/device. That’s fine for product analytics, but it tends to fail for retention because you can’t confidently message or suppress.
• At Identify: your SDK sends a stable person identifier (typically your internal user_id; sometimes email if you truly don’t have an ID). Customer.io then associates the current device/session with that person.
• After Identify: events, purchases, and attribute updates resolve to the identified person—meaning your segments (e.g., “Viewed product but didn’t purchase”) and journeys (cart recovery, replenishment, winback) behave predictably.
• Identity stitching reality: the goal is one person → many devices. In practice, this tends to break when teams identify with email sometimes, user_id other times, or they delay identify until too late (after key events already fired).

Real D2C scenario: A shopper installs your app from an Instagram ad, views a product twice, adds to cart, then bounces. The next day they come back, log in, and complete checkout. If you call Identify at login (and ideally as soon as you capture email), Customer.io can connect the earlier browse/cart events to the same person—so you can suppress cart recovery after purchase, trigger the right post-purchase cross-sell, and avoid double-sending.

Step-by-Step Setup

The setup is straightforward, but the sequencing matters. You’re not “adding tracking”—you’re deciding when a user becomes known and what identifier is canonical across app, web, and backend purchase events.

1. Pick your canonical identifier.
   Use a stable internal user_id whenever possible. Treat email/phone as attributes, not the primary ID, unless you truly don’t have an internal ID at the time of identify.
2. Install the Customer.io SDK(s) where behavior happens.
   Implement on iOS/Android (or React Native/Flutter/Expo) and your web experience if you have meaningful web browsing/checkout. The win is cross-device stitching, not “more events.”
3. Initialize the SDK early in the app lifecycle.
   Do this at app start so anonymous events (product views, add-to-cart) are captured even before login.
4. Call Identify immediately when the user becomes known.
   Typical moments:
   • Account created
   • Login success
   • Email captured (newsletter sign-up, checkout email step) if you can map it to a person record
5. Attach key customer attributes during Identify (or immediately after).
   At minimum: email, phone (if SMS), first_name, marketing_opt_in, country, and any loyalty tier/VIP flag you’ll actually segment on.
6. Track events consistently pre- and post-identify.
   Standardize event names and payloads for retention flows:
   • Product Viewed (sku, product_id, category)
   • Added to Cart (sku, quantity, value)
   • Checkout Started (cart_value, item_count)
   • Order Completed (order_id, value, items[])
7. Handle logout explicitly.
   When a user logs out, reset the SDK identity (so the next user on the same device doesn’t inherit the previous person’s profile). This is a common source of “why did this person get someone else’s winback?” issues.
8. Validate identity stitching in Customer.io.
   Use real devices and test accounts. Confirm that: (a) anonymous events exist before login, (b) after identify those events associate to the known person, and (c) subsequent events land on the same person across sessions.

When Should You Use This Feature

Identify is worth obsessing over any time your retention program depends on correctly understanding “who did what” across sessions and devices. If you’re sending cart recovery, browse abandonment, or replenishment, identity issues will quietly destroy performance.

• Cart recovery that doesn’t embarrass you. Identify ensures you suppress abandon messages after purchase and avoid sending to the wrong profile when someone logs in on a shared device.
• Browse-to-buy retargeting in-app and push. If product views happen before login, identify is how those views become usable for “viewed X, didn’t buy” segments.
• Repeat purchase and replenishment. If purchases come from backend/order system but engagement comes from the app, you need a shared identifier so “last purchase date” and “last app session” live on the same person.
• Reactivation with accurate suppression. Winback journeys depend on excluding people who already returned. Identity stitching prevents “reactivation” messages to someone who actually purchased yesterday on another device.

Operational Considerations

Once Identify is live, the operational work is keeping segmentation and orchestration aligned with how identity actually behaves in the wild. Most teams don’t fail on implementation—they fail on consistency and data flow ownership.

• One identifier policy. Decide what Customer.io’s primary identifier is (usually user_id) and enforce it across app SDK, web SDK, and server-side purchase events. Mixing IDs creates duplicates that inflate audience size and tank conversion rates.
• Anonymous-to-known timing. If you delay identify until “Order Completed,” you lose the ability to run pre-purchase flows (browse/cart). Call identify at login/email capture, not at the end.
• Attribute governance. Only send attributes you will segment on or personalize with. Bloated profiles make debugging harder and slow down iteration.
• Cross-channel readiness. Identify doesn’t magically make SMS/push work—make sure opt-in status and tokens/device registration are tied to the same person profile you identify.
• Orchestration reality. If your order events come from Shopify/backend and your app events come from SDK, confirm they resolve to the same person. Otherwise, your journey will branch incorrectly (e.g., treating a buyer like an abandoner).

Implementation Checklist

Before you ship to production, you want confidence that identity stitching will hold up under real customer behavior—multiple devices, shared tablets, guest checkout, and delayed logins.

• Canonical ID chosen (prefer user_id), documented, and used consistently
• SDK initialized early enough to capture pre-login events
• Identify called on login/account creation (and any email capture moment you support)
• Logout resets identity to prevent profile contamination
• Core retention events implemented with consistent naming and required properties
• Opt-in attributes (email/SMS/push) tracked and kept current
• Test plan executed on at least 2 devices + 1 shared device scenario
• Customer.io profile review confirms events land on the intended person

Expert Implementation Tips

These are the small choices that keep your retention machine stable when volume scales and multiple teams touch tracking.

• Identify once, update often. Treat Identify as the “link” operation. Then send attribute updates as they change (VIP status, subscription preference, loyalty points) rather than re-identifying constantly.
• Standardize event schemas like you standardize creative. If “Added to Cart” sometimes sends productId and sometimes sku, your segments will silently undercount and your cart recovery will look “random.”
• Use a single source of truth for purchase. For most D2C brands, server-side order events are more reliable than client-side. Let the SDK handle intent (views/cart), and let backend handle revenue (orders/refunds).
• Plan for guest checkout. If users can buy without creating an account, decide how you’ll identify them (email as ID vs creating a user record). This decision directly impacts repeat purchase and winback accuracy.

Common Mistakes to Avoid

Most retention “bugs” show up as weird audience counts, duplicate sends, or suppression failures. They usually trace back to one of these mistakes.

• Using email as the ID in one place and user_id in another. This creates duplicate people and splits event history, which breaks segmentation and frequency control.
• Calling Identify too late. If you only identify after purchase, you can’t reliably run browse/cart journeys, and you’ll mis-handle suppression.
• Not resetting on logout. Shared devices (family iPad, retail kiosk, borrowed phone) will contaminate profiles and cause mis-targeted messages.
• Tracking purchases only client-side. App-side purchase events can fail due to network drops or app backgrounding—then your “purchased” suppression doesn’t fire and cart recovery keeps sending.
• Over-sending attributes without a segmentation plan. Teams dump everything “just in case,” then can’t debug why segments don’t match expectations.

Summary

If you care about retention performance, Identify is not optional—it’s the foundation for accurate cart recovery, post-purchase, and winback. Implement it early (at login/email capture), keep the identifier consistent, and pair SDK intent events with server-side purchase truth. When identity is clean, everything downstream gets easier to optimize.

Implement Identify with Propel

If you’re rolling out Identify across app + web + backend, the hard part is rarely the SDK call—it’s making sure every event and attribute resolves to the same person so your Customer.io segments and journeys don’t drift over time. If you want an operator-led implementation plan (naming, schemas, stitching rules, and a test matrix), book a strategy call and we’ll map it to your actual purchase paths and retention flows.