Identify people (SDK) in Customer.io: the retention operator’s guide

Overview

If you want Customer.io to reliably power cart recovery, repeat purchase, and reactivation, you need clean identity—meaning the same shopper is the same profile across sessions, devices, and channels. If you’re not sure whether your current app tracking is stitching correctly (or you’re seeing “ghost” duplicates), book a strategy call and we’ll pressure-test your Identify + event plan against real retention use cases.

In most retention programs, Identify is the difference between “we sent an abandoned cart” and “we sent it to the right person, with the right cart, at the right time”—especially once shoppers start browsing logged-out, then log in later on a different device.

How It Works

At a practical level, Identify is the moment your app tells Customer.io: “this anonymous device/session is actually Sarah, and here’s her stable customer ID and attributes.” Once you do that consistently, Customer.io can stitch pre-login activity to the known profile and your campaigns stop fragmenting across multiple profiles.

• Anonymous first, known later: A shopper can generate events (product views, add_to_cart) before logging in. When they authenticate, your app calls identify with a stable identifier (usually your internal user/customer ID). That’s the bridge that ties earlier activity to the known person.
• Stable identifier is the whole game: Use a durable ID that won’t change (not email as the primary key if it can change; not phone if it’s optional). Email/phone work well as attributes you update over time.
• Attributes ride along with identity: On identify (and later updates), you set fields like email, phone, first_name, accepts_sms, loyalty_tier, last_order_at. These become segmentation and personalization fuel.
• Events become actionable once identity is correct: Your SDK tracks events (e.g., add_to_cart, checkout_started, order_completed) with properties. Customer.io uses those events to trigger Journeys and to build segments—but only as cleanly as your identity stitching.

Real D2C scenario: A shopper browses on mobile web, adds a product to cart, then installs your app and logs in to check shipping. If you identify on login and your event schema is consistent, you can send a push within 30 minutes: “Your cart’s still waiting—free shipping ends tonight.” Without Identify, that cart event stays stranded on an anonymous profile and your recovery flow underperforms for reasons that look like “creative” but are actually “data.”

Step-by-Step Setup

Before you touch Journeys, get the app-side basics right: install the SDK, decide when you’ll identify, and standardize your event names/properties. This is the part that prevents duplicate profiles and broken cart recovery triggers later.

1. Install the correct Customer.io SDK for your app stack
   Pick the native SDK (iOS/Android) or your wrapper (React Native/Flutter/Expo). Confirm you’re initializing the SDK on app start and that network calls are firing in a dev build.
2. Define your “stable ID” and commit to it
   Use your internal customer/user ID as the primary identifier. Treat email and phone as attributes that can change.
3. Call Identify immediately after authentication
   Trigger identify right after login/signup succeeds (and after you have the stable ID). Include key attributes you’ll segment on.
   Operator note: if you delay identify until “profile screen loaded,” you’ll lose attribution for the most valuable events that happen right after login.
4. Track pre- and post-login events consistently
   Track the same event names whether the user is logged out or logged in (e.g., add_to_cart should not become add_to_cart_logged_in). Identity stitching should handle the rest.
5. Standardize cart and product properties
   For cart recovery, pass properties that your messages will need: sku, product_id, product_name, price, quantity, currency, and ideally a cart_id or checkout_id.
6. Handle logout explicitly
   When a user logs out, reset/clear the identified user in the SDK so the next user on the device doesn’t inherit the previous identity.
7. QA identity stitching in Customer.io, not just in logs
   In a test environment, create a flow: browse anonymously → add to cart → login → add another item. Confirm Customer.io shows one person with a continuous event timeline.

When Should You Use This Feature

Identify matters whenever your retention outcomes depend on joining behavior across sessions or devices. If your brand has any meaningful logged-out browsing (most do), this is foundational—not optional.

• Cart recovery that actually matches the shopper: Trigger on add_to_cart or checkout_started, then identify on login so the right person gets the right reminder across email/push/SMS.
• Repeat purchase flows tied to the real buyer: If the order happens on web but the customer uses the app later, Identify helps keep replenishment and cross-sell flows on one profile.
• Reactivation based on true inactivity: Without stitching, “inactive 45 days” gets polluted by duplicates—your winback audience becomes noisy and performance drops.
• Preference capture and channel eligibility: When a shopper opts into SMS or push, Identify makes sure consent attaches to the right person, not a throwaway anonymous profile.

Operational Considerations

Most teams don’t fail on “sending messages”—they fail on the seams between product analytics, identity, and orchestration. These are the realities that show up once you scale beyond a single abandoned cart email.

• Segmentation depends on attribute discipline: Decide which attributes are source-of-truth from the app (e.g., loyalty_tier, push_enabled, sms_opt_in) vs from your backend/order system (e.g., lifetime_value, order_count). Don’t let the app overwrite backend-calculated fields.
• Event timing impacts triggers: If your app batches events or sends them late, your “send within 30 minutes” cart recovery becomes “send whenever the app feels like it.” Validate delivery latency, especially on poor networks.
• Identity stitching breaks on shared devices: If you don’t reset identity on logout, you’ll message the wrong person. This shows up as “weird unsubscribes” and support tickets.
• Cross-platform naming drift kills orchestration: If iOS sends checkout_started and Android sends begin_checkout, your Journey logic becomes a mess. Lock a single schema and enforce it in code review.
• Orchestration needs a single ‘purchase’ truth: For repeat purchase and suppression (“don’t send cart reminder after purchase”), make sure order_completed is consistent and arrives fast enough to stop downstream messages.

Implementation Checklist

If you want Identify to hold up under real retention pressure (multiple devices, login/logout, paid acquisition spikes), run this checklist before you build more campaigns on top.

• SDK installed and initialized on app start in all environments (dev/stage/prod)
• Stable customer ID chosen and used consistently for Identify
• Identify called immediately after login/signup success
• Logout clears the identified user state in the SDK
• Core commerce events tracked with consistent names across platforms
• Cart/checkout events include usable properties (SKU, product name, price, cart/checkout ID)
• Order completed event fires reliably and quickly (used for suppression + post-purchase)
• QA confirms anonymous-to-known activity is stitched into one profile in Customer.io

Expert Implementation Tips

These are the small operator moves that keep your retention program from quietly bleeding performance due to identity and event drift.

• Identify once, then update attributes intentionally: Don’t spam identify calls on every screen. Identify on auth; use targeted attribute updates when something meaningful changes (opt-in, tier, address availability).
• Send both ID and email early when you have it: Even if your stable ID is primary, setting email as an attribute early improves deliverability workflows and reduces “unknown email” gaps in triggered sends.
• Model cart as a first-class object in event properties: For higher AOV brands, include an array of line items (or a summarized representation) so your cart recovery message can show the right products without brittle lookups.
• Design for suppression first: Build your event flow so purchase events can cancel cart reminders and winbacks. In practice, this is where teams accidentally over-message and burn list health.

Common Mistakes to Avoid

Most “Customer.io isn’t working” complaints end up being one of these. Fixing them usually lifts revenue faster than rewriting copy.

• Using email as the primary identifier when it can change: This creates duplicate profiles and broken history. Use a stable internal ID; treat email as an attribute.
• Identifying too late: If you identify after key events fire (like checkout_started), those events attach to anonymous profiles and your triggers miss.
• Not clearing identity on logout: Shared devices and family iPads will poison your data and send messages to the wrong person.
• Inconsistent event schemas across platforms: Different names/properties for the same behavior forces you into complex Journey logic and unreliable segments.
• Tracking “purchase” only server-side without timely delivery: If the purchase event arrives hours later, you’ll send cart reminders after someone already bought.

Summary

If you care about cart recovery, repeat purchase, and reactivation performance, Identify is the foundation that keeps profiles clean and triggers trustworthy. Implement it right in the SDK (stable ID, timely identify, consistent events), then build Journeys on top of data you actually trust.

Implement Identify with Propel

If you’re rolling out Identify (or cleaning up a messy implementation), the fastest path is usually a tight audit: when identify fires, what ID you’re using, and whether anonymous activity stitches the way your retention flows assume it does. We work alongside teams running Customer.io to validate SDK identity, event schemas, and suppression logic so your cart and winback programs don’t get kneecapped by tracking gaps—if you want a second set of operator eyes, book a strategy call.