Identify people (SDK) in Customer.io

Overview

If you want retention automation to work, you need clean identity in Customer.io—not “maybe this device is the same person” guesses. Identify is the moment your app tells Customer.io, “this anonymous device is actually Sarah, here’s her customer ID and attributes,” so cart recovery, replenishment, and winback flows don’t fragment across multiple profiles. If you want a second set of eyes on your identity plan before you ship it, book a strategy call.

In most retention programs, the biggest lift from Identify isn’t theoretical—it’s that your abandoned checkout push, your post-purchase cross-sell email, and your reactivation SMS all land on the same person with the right suppression rules.

How It Works

On mobile/web, users start as anonymous until you have a stable identifier (login, account creation, or verified email/phone). The SDK keeps tracking events either way, but Identify is what stitches that activity to a known profile so segmentation and orchestration don’t break.

• Anonymous activity first: The SDK can record events before a user logs in (e.g., Viewed Product, Added to Cart).
• Identify call: When the user becomes known, you call identify with your canonical customer identifier (usually your internal customer_id) and optional traits (email, phone, first_name, lifecycle flags).
• Stitching: Customer.io associates future events with that identified person. If you implement Identify at the right moment, you also avoid creating duplicate people (the classic “guest checkout profile” + “logged-in profile” problem).
• Attributes become segmentation fuel: Traits you pass on Identify (or subsequent profile updates) power real retention logic—VIP tiers, subscription status, last_order_date, push opt-in state, etc.

D2C scenario: A shopper browses on your iOS app, adds a cleanser to cart, then creates an account to save their routine. If you track Added to Cart anonymously and fire Identify on account creation, your cart recovery journey can still trigger correctly (and suppress if they purchase) because the cart event and the user identity live on the same profile.

Step-by-Step Setup

The goal is simple: pick one ID strategy, implement Identify at the right app moments, and make sure events before/after login land on the same person. This is where teams either get clean retention data—or they spend months debugging “why did this person get three winbacks?”

1. Choose your canonical identifier (don’t skip this).
   Use a stable, unique ID from your system of record (e.g., customer_id from your commerce platform or backend). Avoid using email as the primary key if it can change.
2. Install the Customer.io SDK in your app (mobile/web).
   Complete the SDK install for your platform (iOS/Android/React Native/Web). Confirm the SDK is sending data in your dev environment before you wire Identify.
3. Track key anonymous events immediately.
   Start with high-leverage retention events that happen pre-login: Viewed Product, Added to Cart, Started Checkout, Viewed Collection. Keep naming consistent across platforms.
4. Call Identify at the “identity becomes real” moment.
   Fire identify when the user logs in, creates an account, or completes a verified checkout step—any moment you can confidently map the device/session to a real customer.
5. Send traits that retention will actually use.
   Pass only what you’ll segment or personalize on in the next 30–60 days: email, phone, first_name, country, marketing_opt_in, push_enabled, sms_subscribed, vip_tier.
6. Verify stitching in Customer.io before launching journeys.
   In Activity Logs / person profiles, confirm: anonymous events appear before Identify, then the profile shows identified traits, and post-login events continue on the same person.
7. Lock your event + identity contract.
   Document: when Identify fires, what ID is used, and what traits are required. This prevents future app releases from silently breaking your segmentation.

When Should You Use This Feature

Identify matters any time you’re trying to run retention workflows off behavior that happens before someone is logged in or before you’ve captured email/phone. If you’re serious about cart recovery and repeat purchase, you’ll hit this fast.

• Cart recovery in-app → email/SMS: Capture Added to Cart anonymously, then Identify at login/checkout so the recovery message goes to the right channel and suppresses on purchase.
• Browse-to-buy retargeting: Product discovery events are often anonymous; Identify ensures your “Still thinking about this?” push/email isn’t lost.
• Reactivation with clean suppression: Winback flows break when one human has multiple profiles. Identify reduces duplicates so you don’t spam lapsed customers.
• Cross-device continuity: If a customer browses on mobile but purchases on desktop later, a consistent identifier strategy makes your segments and exclusions accurate.

Operational Considerations

In practice, identity is where orchestration gets messy: multiple devices, guest checkout, changing emails, and partial opt-ins. The way you implement Identify determines whether your segments behave or drift over time.

• Segmentation depends on identity consistency: If iOS uses email as ID and Android uses customer_id, you’ll create split-brain audiences. Standardize one canonical ID everywhere.
• Data flow timing matters: If Identify fires after you trigger a cart abandonment journey, the user may enter as anonymous and never qualify for email/SMS steps. Fire Identify as early as you can confidently do it.
• Trait hygiene beats trait volume: Over-sending traits (especially nested JSON) creates confusion in segment builders and makes QA harder. Send the minimum set that powers retention decisions.
• Orchestration reality: You’ll often run multi-channel flows (push → email → SMS). Identify is what lets you branch based on channel availability (push token present, sms_subscribed true) without duplicating audiences.
• Duplicate handling: If your business has guest checkout + later account creation, plan how you’ll reconcile those identities. Don’t assume it “just merges” the way you want without validating in logs.

Implementation Checklist

Before you ship Identify to production, you want confidence that one human maps to one profile and that pre-login events still power post-login retention. This checklist is what we use to avoid the most common identity regressions.

• Canonical ID chosen (prefer internal customer_id) and used across all platforms
• Identify fires on login/account creation/verified checkout (defined and documented)
• Anonymous events tracked for browse + cart milestones
• Traits sent are retention-relevant (email/phone/opt-ins/tier/location)
• QA confirms pre-Identify and post-Identify events land on the same profile
• Purchase event and order identifiers are consistent for suppression + attribution
• Channel eligibility traits exist (push_enabled, sms_subscribed, etc.)
• Duplicate profile audit plan (monthly) and a remediation owner

Expert Implementation Tips

Most teams implement Identify once and move on. The teams that get outsized retention gains treat identity like infrastructure—stable, monitored, and designed around real customer behavior.

• Identify early, but not speculatively: Don’t identify on “email entered” unless you validate it (or you’ll pollute profiles with typos and burner emails). Prefer account creation, OTP verification, or completed checkout.
• Use a single “source of truth” ID: If Shopify is your backbone, map to the Shopify customer ID (or your backend customer UUID). Email can be a trait, not the key.
• Normalize event names across app + web: If web sends Added To Cart and app sends AddToCart, you’ll end up building duplicate journeys and inconsistent reporting.
• Plan for logged-out states: Users log out, reinstall, or switch devices. Make sure your app re-identifies on next login and doesn’t create a net-new person each time.
• Design segments that assume imperfection: For cart recovery, segment on “Added to Cart AND no Purchase” with a short delay, but also guard with “has email OR push token” so you don’t enqueue dead-end profiles.

Common Mistakes to Avoid

Most retention fires we put out in Customer.io come back to identity mistakes—either duplicates, late Identify calls, or inconsistent IDs across platforms. Fix these and your journeys get dramatically more reliable.

• Using email as the primary identifier: People change emails, type them wrong, or use Apple Private Relay. You’ll split profiles and break suppression.
• Calling Identify too late: If the cart abandonment trigger happens before Identify, the person may enter the workflow anonymously and never receive email/SMS steps.
• Creating multiple IDs for the same human: One platform uses user_id, another uses customer_id, and support imports use email—now your VIPs get winbacks.
• Overwriting traits with nulls: Some implementations send empty strings or null values on Identify, accidentally clearing good data (like phone or opt-in state).
• Not validating stitching in logs: Teams assume merges happened, then discover later that “repeat purchase” segments exclude half their buyers.

Summary

Identify is the backbone of retention in Customer.io: it stitches anonymous app behavior to a real customer profile so your cart recovery, replenishment, and winback logic stays accurate. If you’re seeing duplicate sends, broken suppression, or “missing” conversions, start by auditing when and how Identify fires.

Implement Identify with Propel

If you’re rolling out Identify across mobile and web, the hard part isn’t the call itself—it’s choosing the right ID, timing it correctly, and keeping events consistent so your segments don’t drift. We’ll usually map your identity strategy to your highest-impact flows (cart recovery, post-purchase, winback) and validate it end-to-end in Customer.io. If you want help pressure-testing your implementation plan before it hits production, book a strategy call.