Identify people (SDK) in Customer.io

Overview

If you want retention flows to actually fire on the right person (and not a ghost profile), getting Identify right is the work. In Customer.io, Identify is the moment you tell Customer.io “this device/session belongs to this person,” so all future events, attributes, and message eligibility land on a single customer profile. If you want a second set of eyes on your identity plan before you scale campaigns, book a strategy call.

In most retention programs, we’ve seen Identify be the difference between a cart recovery flow that prints money and one that quietly underperforms because half the carts are tied to anonymous users you can’t message.

How It Works

At a practical level, Identify is identity stitching. Your app collects behavior (events) and customer context (attributes), and Identify tells Customer.io which person record should own that data going forward.

• Anonymous first, known later: A shopper can browse and even add to cart before they log in or enter email. The SDK can track those actions, but they’ll sit on an anonymous profile until you identify the person.
• Identify anchors a stable ID: You pass a unique identifier (typically your internal user_id; sometimes an email) to the SDK. Customer.io uses that to map activity to a single person.
• Attributes ride along: When you identify, you usually also send key attributes (email, phone, acquisition source, loyalty tier). Those become your segmentation backbone for repeat purchase and winback.
• Event attribution becomes reliable: Once identified, events like Product Viewed, Added to Cart, Checkout Started, and Order Completed consistently attach to the same profile—so journeys don’t fragment.

D2C scenario: A customer browses on mobile, adds a bundle to cart, then creates an account at checkout. If Identify happens right when the account is created (or email is captured), your cart abandonment journey can still trigger from the earlier Added to Cart event and send an email/SMS to the now-known customer—without losing the cart context.

Step-by-Step Setup

The goal here is simple: every meaningful event should be attributable to either (1) a known person you can message or (2) an anonymous profile that will later merge cleanly once you know who they are.

1. Choose your canonical identifier.
   Use a stable internal user_id whenever possible. Email changes; user IDs usually don’t. If your stack doesn’t have a stable ID pre-auth, plan for anonymous tracking until signup/login.
2. Install the appropriate Customer.io SDK.
   Implement the SDK for your platform (iOS/Android/React Native/etc.) and confirm the app successfully initializes before you attempt Identify. If initialization is flaky, Identify will be flaky.
3. Track anonymously before login (optional but recommended for ecommerce).
   Start capturing high-intent events immediately: Product Viewed, Added to Cart, Checkout Started. Keep payloads consistent (SKU, price, quantity, cart_id) so you can use the same data post-identification.
4. Call Identify at the first “real” identity moment.
   Trigger Identify when the user logs in, creates an account, or submits an email/phone in a way you trust (e.g., checkout email step). Pass your canonical ID and set key attributes (email, phone, first_name, marketing_opt_in, etc.).
5. Immediately send a “state sync” after Identify.
   Right after Identify, track one event that confirms state (e.g., Session Started or Logged In) and/or update attributes like last_seen_at, app_version, push_enabled. This makes troubleshooting segmentation way easier.
6. Handle logout explicitly.
   When a user logs out, reset the SDK identity back to anonymous (or clear the identified user) so the next user on the same device doesn’t inherit the previous person’s events—this is a classic retention data leak.
7. QA identity stitching end-to-end.
   Run a test: browse anonymously → add to cart → identify at signup → complete purchase. Confirm all events appear under one person in Customer.io and that segments/journeys pick them up.

When Should You Use This Feature

Identify is worth sweating anytime you rely on behavior-triggered messaging or multi-step journeys. If you’re doing retention “for real,” you’re doing Identify—because segmentation and orchestration depend on a clean person record.

• Cart recovery: When customers add to cart before logging in, Identify is what lets you recover that cart once you capture email/phone.
• Repeat purchase: To target “bought X, hasn’t bought Y” you need orders and product events tied to the same person across sessions and devices.
• Reactivation: Winback flows depend on last activity and last purchase timestamps. If those are split across profiles, your reactivation audience shrinks and your messaging gets noisy.
• Cross-device continuity: If someone browses on mobile and buys on desktop later, Identify (plus consistent IDs across platforms) is what keeps the story intact.

Operational Considerations

Most teams don’t fail on “sending Identify.” They fail on consistency: inconsistent IDs, inconsistent event schemas, and messy orchestration between app, backend, and Customer.io.

• Segmentation depends on attribute hygiene: Decide which attributes are source-of-truth from the app (e.g., push_enabled, app_language) vs backend (e.g., lifetime_value, order_count). If both write the same field, you’ll eventually overwrite something important.
• Data flow timing matters: If your purchase event is server-side but Identify is app-side, you can get race conditions (order lands before identity). In practice, this tends to break attribution for first purchases unless you standardize on a shared ID and ensure the backend sends the same identifier.
• Orchestration realities: Journeys that trigger on Added to Cart should include a short delay + “has email/phone” check to give Identify time to happen at checkout. Otherwise you’ll trigger a flow on an anonymous profile you can’t message.
• Duplicate people: If you sometimes identify by email and sometimes by user_id, you’ll create duplicates. Pick one canonical ID and stick to it everywhere.

Implementation Checklist

If you want Identify to hold up under scale (new devices, guest checkout, app reinstalls), lock these in before you start optimizing creative.

• Canonical identifier selected (prefer internal user_id) and documented
• Identify called on login/signup and on trusted email capture during checkout
• Logout clears identity to prevent cross-user contamination on shared devices
• Anonymous pre-auth events tracked with consistent schema (SKU, cart_id, value)
• Post-identify “state sync” event/attribute update implemented for QA
• Backend events (orders, refunds) use the same identifier as the SDK
• Journeys include timing buffers/guards (e.g., delay then check contactability)
• QA plan covers anonymous → identify → purchase → reactivation segmentation

Expert Implementation Tips

These are the small operator moves that keep your retention machine from wobbling when traffic spikes or product changes roll out.

• Identify as early as you can—without lying. If you capture email in a form but it’s frequently mistyped, consider identifying only after verification or after the email step is confirmed. Bad Identify is worse than late Identify.
• Use a “cart_id” consistently. For cart recovery, include cart_id on Added to Cart and Checkout Started. Then your journey can reference the latest cart reliably, even if multiple carts exist.
• Send device capability attributes. Store push_enabled, device_os, and app_version. This lets you suppress push for users who disabled it and avoid blaming creative for a deliverability problem.
• Guard against “identify storms.” Don’t spam Identify on every app open. Call it when identity changes or when you need to attach a new session to a known user.

Common Mistakes to Avoid

Most retention underperformance looks like “creative isn’t working,” but the root cause is usually identity and event integrity.

• Identifying by email on one platform and user_id on another: You’ll split profiles and your LTV math and frequency controls will be wrong.
• Not clearing identity on logout: Shared devices (tablets, family phones) will pollute profiles and trigger embarrassing messages.
• Triggering cart recovery immediately on add-to-cart: Without a delay + contactability check, you’ll enroll anonymous users and wonder why sends are low.
• Inconsistent event payloads: If Added to Cart sometimes sends sku and sometimes product_id, your dynamic cart blocks and segmentation will break.
• Assuming SDK events equal purchase truth: For revenue, rely on server-side order confirmation when possible, but keep IDs aligned so the purchase attaches to the same person identified in-app.

Summary

Identify is the foundation for reliable retention in Customer.io: it stitches anonymous intent to a messageable customer profile. Get the ID strategy, timing, and logout behavior right, and your cart recovery, repeat purchase, and winback flows become dramatically more predictable.

Implement Identify with Propel

If you’re rolling out Identify across mobile/web and want to avoid duplicate profiles, race conditions, and broken cart recovery attribution, it helps to pressure-test the plan before you ship. We’ll typically map your canonical ID, define the exact Identify moments (login, checkout email, signup), and sanity-check event schemas so your Customer.io journeys trigger on the right person. If you want to walk through your setup, book a strategy call.