Identify people (SDK) in Customer.io: stitch anonymous behavior to real customers

Overview

Customer.io only becomes a retention engine when your app knows who the person is at the moment it matters—login, checkout, subscription start, etc. If you want help pressure-testing your identity plan (and avoiding the classic “duplicate profiles + broken abandon flows” mess), book a strategy call and we’ll map it to your funnels.

In practice, “Identify” is the move that turns anonymous browsing into attributable revenue. It’s how you make sure the cart built while someone was anonymous shows up on the same profile as the purchase they make after logging in.

How It Works

Before a user logs in, your SDK can still capture events—product views, add-to-cart, checkout started—but they’re tied to an anonymous identifier. The moment you call identify with a stable customer ID, Customer.io stitches future activity (and often prior anonymous activity, depending on your setup) onto a single person profile.

• Anonymous phase: SDK tracks events against an anonymous profile (device/app instance). Useful for browse and cart intent, but limited for cross-device and long-term retention.
• Identification moment: When the user logs in, creates an account, or you otherwise know who they are, you call identify(userId) and optionally pass traits (email, phone, etc.).
• Stitching: Customer.io links the device/activity stream to that person. From here on, segmentation and orchestration behave like you’d expect (cart recovery, replenishment, winback) because the profile is stable.
• Trait updates: Subsequent identify calls can update attributes (like SMS consent, loyalty tier, subscription status) without creating new people—assuming you keep the same ID.

Where this matters operationally: if you don’t identify at the right time (or you identify with the wrong ID), your “abandoned checkout” flow will trigger on ghosts, your purchasers won’t exit campaigns, and you’ll over-message people who already converted.

Step-by-Step Setup

The goal is simple: pick one durable customer identifier, call identify at the right lifecycle moments, and make sure every key retention event is attached to that same person. Do this once and your segmentation stops fighting you.

1. Choose your canonical customer ID (do this first).
   Use a stable internal ID (e.g., your user UUID). Avoid email as the primary ID if it can change. Email is a trait, not your identity backbone.
2. Install the Customer.io SDK in your app(s).
   Implement on iOS/Android (and web if applicable). Consistency matters: if web uses one ID scheme and mobile uses another, you’ll split profiles and your retention reporting won’t reconcile.
3. Track anonymous intent events immediately.
   Start tracking Product Viewed, Add to Cart, Checkout Started even before login. These are the events you’ll want to recover later.
4. Call identify at authentication (and only when you’re sure).
   Trigger identify right after a successful login/signup. Pass the canonical ID and key traits like email, phone, first_name, marketing_opt_in.
5. Track post-identify revenue events tied to the same person.
   Send Order Completed with order_id, value, currency, items, and any subscription metadata. This is what powers repeat purchase timing, VIP segmentation, and suppression logic.
6. Handle logout explicitly.
   When a user logs out, reset/clear the identified user in the SDK so the next person on that device doesn’t inherit the previous customer’s identity.
7. Validate in Customer.io with real devices.
   Run a test: browse anonymously → add to cart → create account → purchase. Confirm it lands on one profile, with events in the right order, and that segments update quickly enough for your flows.

When Should You Use This Feature

If you’re running any retention program beyond basic newsletters, identify is non-negotiable. The minute you rely on behavioral triggers (cart, browse, purchase cadence), you need identity stitching to keep campaigns honest.

• Cart recovery that survives login: Someone adds to cart while anonymous, then logs in at checkout. Identify ensures the cart event and the purchase land on the same profile so your abandon flow exits correctly.
• Cross-device continuity: A customer browses on mobile, buys on desktop. With a stable ID, you can still trigger replenishment and winback from the full history, not half of it.
• Reactivation based on true last purchase: If purchases are split across duplicate profiles, your “60-day winback” hits active buyers. Identify reduces that risk dramatically.
• VIP / tiered retention: LTV, order count, and subscription status only work when all orders map to one person.

Real scenario: A skincare brand drives paid traffic to a product quiz inside their app. Users take the quiz anonymously, add a routine to cart, then create an account to save results. If identify fires at account creation, you can (1) send a 1-hour cart reminder via push/SMS, (2) suppress if they purchased, and (3) start a replenishment timer off the exact products they bought—without losing the quiz context.

Operational Considerations

Most “Customer.io isn’t working” complaints are really identity and data-flow problems. Get these right and your orchestration becomes predictable.

• Segmentation depends on identity stability. If you identify with email sometimes and user_id other times, you’ll create duplicates. Your segments (e.g., “Added to cart in last 4 hours AND no purchase”) won’t behave reliably.
• Event timing affects message timing. Mobile SDKs can batch or delay events when the app is backgrounded. For cart recovery, that can mean your 30-minute reminder becomes a 2-hour reminder. Build with a buffer and validate on real network conditions.
• Trait governance matters. Decide which system is source of truth for traits like SMS consent, loyalty tier, and subscription status. If the app overwrites these incorrectly during identify, you’ll message people who opted out or miss high-value cohorts.
• Orchestration needs clean “exit” signals. Your abandon and winback flows should exit on Order Completed. If purchases are tracked server-side but identify is app-side, make sure both reference the same customer ID.
• Anonymous-to-known stitching is where programs break. In most retention programs, we’ve seen the biggest lift come from fixing the handoff between anonymous cart activity and known customer messaging.

Implementation Checklist

Use this to QA before you scale spend or turn on high-volume automations like browse abandon and cart recovery.

• Canonical customer ID defined and used everywhere (mobile, web, backend)
• SDK installed and initialized correctly in each app environment (prod vs staging)
• Anonymous events tracked pre-login (view, add_to_cart, checkout_started)
• identify called immediately after successful login/signup
• Key traits passed on identify (email/phone, consent flags, locale/timezone if available)
• Logout clears identity/reset SDK user
• Purchase event includes order_id + value + currency + line items
• Test flow confirms one profile owns the full journey (anonymous → identify → purchase)

Expert Implementation Tips

These are the small operator moves that keep your retention machine from leaking revenue through bad data.

• Identify once you’re confident, not when you “think” you know. Don’t identify off an email typed into a form unless it’s verified—otherwise you’ll stitch anonymous behavior to the wrong person and your messaging gets creepy fast.
• Send consent as a first-class trait. If SMS/push consent is stored in-app, pass it on identify and update it on change. Then gate SMS/push sends off those traits.
• Standardize event names and payloads across platforms. “AddToCart” on iOS and “add_to_cart” on Android will fragment segments. Pick one schema and enforce it.
• Use order_id for dedupe. Mobile purchase events can double-fire (retries, app relaunch). Including order_id lets you dedupe downstream and prevents “thanks for your order” spam.
• QA with a real cart recovery journey. Build a test segment: “Added to cart in last 2 hours AND no Order Completed.” Then run the full path end-to-end on a device.

Common Mistakes to Avoid

Most teams don’t fail because they didn’t track events—they fail because identity is inconsistent and the orchestration can’t trust the data.

• Using email as the ID. Emails change, get aliased, and can be shared. Use a stable internal ID and store email as an attribute.
• Identifying too late. If identify only happens after purchase, you’ve already lost the ability to recover carts created during the anonymous phase.
• Not clearing identity on logout. Shared devices (tablets, family phones) will contaminate profiles and trigger messages to the wrong person.
• Splitting identity across app and backend. If backend sends purchases under customer_id but the app identifies under a different ID, you’ll create duplicates and “purchasers” won’t suppress abandon flows.
• Overwriting traits with nulls. Some implementations pass empty values during identify and wipe good data (like phone number or consent). Guard against null/empty updates.

Summary

If you want cart recovery, replenishment, and winback to work reliably, you need clean Identify calls tied to a stable customer ID. Track intent while anonymous, identify at login, and make sure purchases land on the same profile. Once identity is stitched, segmentation and orchestration stop fighting you.

Implement Identify with Propel

If you’re implementing Identify across iOS/Android/web and want to avoid duplicates, missing carts, or broken suppression logic, we can help you design the ID strategy and validate the full data flow inside Customer.io. If it’s useful, book a strategy call and we’ll review your current tracking plan against the retention programs you’re trying to run (cart recovery, repeat purchase, reactivation).