Identify people (SDK) in Customer.io: the retention-critical way to stitch users across sessions and devices

Overview

If you’re running retention in Customer.io, Identify is the moment your data stops being “activity” and starts being “a customer.” It’s the call that ties anonymous browsing and app usage to a real profile so your cart recovery, post-purchase, and winback flows don’t fragment across multiple IDs.

If you want a second set of eyes on where identity stitching tends to break (and how to structure it for repeat purchase), you can book a strategy call—most issues here are fixable with a few disciplined rules.

How It Works

In practice, Identify is less about “creating a user” and more about choosing the one stable key Customer.io should trust. Once you do that consistently, every event you send from the SDK lands on the right person, segments stay clean, and your orchestration doesn’t leak revenue.

• Anonymous first, known later: Your SDK can start tracking behavior before login (product views, add-to-cart, quiz completion). Those events are anonymous until you call identify.
• Identify links activity to a person: When the user logs in, creates an account, or you otherwise know who they are, you call identify with your stable customer ID (and usually email/phone as attributes). From that point on, events attach to that profile.
• Identity stitching is the retention unlock: The real win is merging pre-login behavior (like a cart build) into the known profile so your abandonment flow can fire even if they add items before logging in.
• Attributes become segmentation fuel: Identify commonly includes attributes like email, phone, first_name, accepts_marketing, customer_status, last_order_at, etc. These drive suppression, frequency logic, and channel routing.

Real D2C scenario: A shopper opens your app from an ad, adds two items to cart, then creates an account at checkout. If you only track events anonymously and never stitch, Customer.io sees “anonymous cart” and “new customer” as two different people. Your cart recovery never sends (wrong profile), and your post-purchase flow hits a profile with zero browsing context (weak personalization). Identify is what prevents that split.

Step-by-Step Setup

The goal is simple: track immediately, identify as soon as you can, and keep the identifier consistent forever. Most retention programs we’ve seen fall apart because Identify is called late, called inconsistently, or uses a key that changes.

1. Install the Customer.io SDK in your app (web or mobile)
   Initialize the SDK as early as possible in app launch/page load so you capture pre-login behavior.
2. Start tracking anonymous events right away
   Track events like Product Viewed, Added to Cart, Checkout Started, and include useful properties (SKU, category, price, quantity).
3. Define your canonical identifier (do this before you write code)
   Use a stable internal customer_id (or equivalent). Avoid email as the primary ID if it can change. Email should be an attribute, not your identity anchor.
4. Call Identify immediately on a “known user” moment
   Typical triggers: account creation, login, magic link success, or when you’ve resolved identity via a backend session. Pass your stable ID and key attributes (email/phone, marketing consent, locale/timezone if you have it).
5. Ensure anonymous activity merges into the identified profile
   Confirm that events fired before Identify end up on the same person after login. This is the difference between “nice tracking” and “working cart recovery.”
6. Track post-identify events with the same naming and schema
   Keep event names consistent across anonymous and identified states (don’t switch from Added to Cart to AddToCart after login). Consistency keeps segments and triggers sane.
7. Handle logout explicitly
   When a user logs out, reset the SDK identity so the next person using the device doesn’t inherit the prior customer’s profile.

When Should You Use This Feature

Identify matters any time you need Customer.io to understand that multiple sessions and devices belong to the same buyer. If you’re doing retention seriously—repeat purchase, cart recovery, reactivation—you’re already depending on it whether you realize it or not.

• Cart recovery that starts pre-login: Users build carts before they authenticate. Identify is what makes those events eligible for “Abandoned Cart” journeys tied to a reachable profile.
• Repeat purchase orchestration: If a customer buys on desktop but browses on mobile, you need one profile to manage replenishment timing, cross-sell logic, and frequency caps.
• Reactivation with behavioral context: Winback performs better when you can reference last category viewed, last quiz result, or last PDP view—data often collected anonymously first.
• Multi-channel routing (email/SMS/push): Identify is typically when you attach deliverable contact points and consent flags. Without it, you’ll over-rely on one channel or message the wrong person.

Operational Considerations

Once Identify is live, the real work is keeping your data model clean enough that segmentation and orchestration don’t become a guessing game. This is where teams usually feel pain a few weeks later—when numbers don’t match between analytics, Shopify, and Customer.io.

• Segmentation depends on stable IDs: If you identify by email and the customer updates it, you risk creating duplicates and splitting LTV history. Use a stable internal ID and store email as an attribute.
• Data flow timing affects triggers: If Identify fires after Checkout Started (or after Added to Cart), your abandonment workflow might not enroll them correctly. Aim to identify at login/account creation, not “eventually.”
• Orchestration realities (frequency + suppression): Most retention stacks run multiple flows at once (cart, browse abandon, post-purchase, replenishment). If identity is fragmented, frequency caps won’t work and customers get spammed across duplicate profiles.
• Cross-device stitching requires consistent identity: If your app uses user_id but your web uses email, you’ve already split the customer. Align the identifier across platforms.
• Consent and compliance: Treat accepts_marketing, SMS consent, and region flags as first-class attributes at Identify time so you can gate channels correctly.

Implementation Checklist

Before you ship, you want to be confident that a customer’s journey doesn’t fork into multiple profiles. This checklist is what we use to sanity-check identity stitching before we scale spend or launch new flows.

• SDK initialized early enough to capture pre-login browsing and cart events
• Canonical ID chosen (stable internal ID) and used consistently across web + mobile
• identify called on login/account creation (not delayed)
• Email/phone stored as attributes (and updated when they change)
• Anonymous pre-login events successfully merge into the identified profile
• Logout resets identity so shared devices don’t contaminate profiles
• Event naming + properties consistent across anonymous/known states
• Consent attributes available for channel gating and suppression

Expert Implementation Tips

The difference between “implemented” and “operationally reliable” is usually a handful of rules your engineers follow every time. These are the ones that protect retention performance as you add channels and flows.

• Identify earlier than you think: If you have a persisted session token on app open, identify on launch—not after the first screen interaction. It tightens attribution for browse/cart triggers.
• Send a lightweight “Identity Confirmed” event after identify: It’s a clean debugging hook in Customer.io to verify the stitch happened, and it helps QA journeys without guessing.
• Normalize your IDs across systems: If Shopify is your source of truth, map Shopify customer ID (or your internal customer ID) to the same identifier used in the SDK and any server-side events.
• Keep attributes boring and durable: Put volatile stuff (like cart contents) on events, not on the profile. Profiles should hold segmentation primitives (status, consent, VIP tier, last_order_at).

Common Mistakes to Avoid

Most Customer.io “retention bugs” aren’t messaging problems—they’re identity problems that show up as missing enrollments, duplicate sends, or segments that never match.

• Using email as the primary identifier: It seems convenient until customers change emails, use Apple private relay, or you ingest multiple emails per person. Duplicates follow.
• Calling identify too late: If identify happens after key funnel events, your cart/browse abandonment triggers won’t attach to a reachable profile.
• Not resetting identity on logout: Shared devices (tablets, family phones) can cause one customer to inherit another’s behavior—brutal for personalization and trust.
• Inconsistent event schemas pre- vs post-login: Different event names/properties create segmentation gaps and force you to maintain parallel journeys.
• Letting web and app identify differently: Two identifiers across platforms equals two customers in your orchestration layer, even if everything else is “correct.”

Summary

If you want retention flows to behave predictably, Identify has to be boringly consistent. Call it early, use a stable ID, and make sure anonymous behavior stitches cleanly into the known profile.

If your cart recovery or winback performance looks “random,” identity fragmentation is often the first thing to rule out.

Implement Identify with Propel

When we help teams operationalize identity in Customer.io, the work is usually aligning one canonical ID across app + web, confirming anonymous-to-known stitching, and then tightening the orchestration rules that depend on it (cart, post-purchase, winback, frequency caps). If you want help pressure-testing your Identify timing and schema before you scale, you can book a strategy call.