Identify people (SDK) in Customer.io: the call that makes your retention data trustworthy

Overview

If you want retention automations to behave predictably, identify is the first thing to get right in Customer.io. It’s the moment your app stops treating someone as “a device” and starts treating them as “a customer,” which is what makes cart recovery, post-purchase, and winback journeys actually line up across sessions and devices. If you want a second set of eyes on your identity model before you scale spend or expand channels, book a strategy call and we’ll pressure-test the setup the way we do in most retention programs.

In practice, teams think they have an “abandon cart” problem when they actually have an identity problem: the same shopper exists as three profiles (anonymous web, logged-in app, checkout email), so the journey can’t see the full story.

How It Works

At a mechanical level, Identify ties an external identifier (your customer ID, or at minimum an email) to the current SDK user context so Customer.io can attach future events, device tokens, and attribute updates to the right person. Once you call identify, every subsequent track event from that app install should land on that same person—unless you later overwrite it or accidentally create a second identity.

• Before identify: the SDK can still collect activity, but it’s effectively “unowned” or tied to an anonymous profile/device context. That data won’t reliably power cross-device retention.
• At identify: you send a stable identifier (ideally customer_id) plus useful attributes (email, phone, acquisition source, etc.). Customer.io uses this to create or update the person.
• After identify: events like Viewed Product, Added to Cart, and Order Completed attach to the identified person, enabling segmentation and orchestration across email/SMS/push.
• Identity stitching reality: stitching only works as well as your rules. If your app identifies by email sometimes and by internal ID other times, you’ll create duplicates and your “single customer view” fractures.

Step-by-Step Setup

The goal here is simple: call identify exactly when you have a trustworthy customer identifier, and make that identifier consistent everywhere. If you do that, the rest of your tracking (and therefore your retention journeys) becomes dramatically easier to reason about.

1. Pick your canonical identifier.
   Use your internal customer ID if you have one. Treat email as an attribute, not the primary key, unless you truly don’t have a stable ID.
2. Install the appropriate Customer.io SDK in your app.
   Implement the SDK for iOS/Android/React Native/etc. Keep the SDK init early in app launch so you don’t miss pre-login events, but don’t identify until you actually know who the person is.
3. Call identify on authentication.
   Trigger identify immediately after a successful login or account creation (and after you’ve received the definitive user object from your backend). Include:
   
   • id: your canonical customer ID
   • attributes: email, phone (if used), first_name, last_name, marketing_opt_in, timezone, etc.
4. Update attributes when they change.
   If someone updates email/phone, don’t re-key the user. Keep the same canonical ID and update the attribute. This avoids “new person created” issues.
5. Track events only after you’ve confirmed identity where it matters.
   For retention-critical events (checkout started, payment failed, subscription renewed), make sure they’re tracked in a context where the user is already identified—or pass the same identifier via your server-side pipeline if the event happens off-device.
6. Handle logout explicitly.
   When a user logs out, reset the SDK user context per your platform’s best practice so the next user on the device doesn’t inherit the previous user’s identity.

When Should You Use This Feature

Identify isn’t optional once you care about repeat purchase and winback. Any time you need Customer.io to understand “this is the same person as last week,” you’re relying on Identify—even if you don’t realize it.

• Cart recovery across devices: shopper adds to cart on mobile app, completes checkout later on desktop. If the app never identified them (or identified inconsistently), your recovery flow either won’t fire or will fire to the wrong profile.
• Repeat purchase timing: you want a replenishment journey (e.g., 21 days after first purchase) that suppresses if they already reordered. That suppression breaks immediately if orders land on a different profile than the app activity.
• Reactivation with push: winback campaigns depend on accurate device-token ownership. Identify ensures push tokens attach to the right person so “lapsed 60 days” segments don’t spam shared devices.
• VIP segmentation: when LTV, order count, and app engagement need to live on one profile, Identify is what keeps those attributes from fragmenting.

Operational Considerations

This is where most implementations get messy: the SDK is doing its job, but your data model and orchestration rules aren’t. If you want reliable retention performance, treat identity as a system, not a single API call.

• Segmentation depends on profile integrity.
  If “Added to Cart” is tracked anonymously but “Order Completed” is tracked post-login, your cart abandon segment will undercount, and your post-purchase flows will over-message because they can’t see the pre-purchase intent.
• Decide where truth lives for key events.
  For purchases, refunds, subscription status, and loyalty tier, server-side events are usually the source of truth. Use the SDK for behavioral signals (browse, wishlist, app sessions) and make sure both paths share the same canonical identifier.
• Orchestration breaks on duplicates.
  In most retention programs, we’ve seen duplicate profiles cause: double sends, suppression failures, and broken frequency caps—especially when SMS and email consent live on different profiles.
• Anonymous-to-known transitions need a plan.
  If you allow guest checkout or pre-login cart building, you need a clear strategy for when the anonymous activity should merge into the identified profile. If you don’t, your “high intent” signals never reach the person you’re messaging.

Implementation Checklist

Before you ship this to production, you want to be confident you’re identifying the same way across every app state and every platform. This checklist catches the stuff that quietly wrecks retention later.

• Canonical identifier chosen (internal customer ID preferred) and documented
• identify called immediately after login and account creation
• Attribute updates do not change the canonical ID (email changes update attributes only)
• Logout clears/reset SDK user context
• Purchase and subscription events share the same identifier (SDK and/or server-side)
• Consent fields (email/SMS/push) are modeled as attributes and updated on change
• QA: one user logs in/out on a shared device without cross-contaminating profiles
• QA: cart → login → checkout keeps all events on one person

Expert Implementation Tips

These are the small choices that make the difference between “events are flowing” and “retention journeys are trustworthy.” They’re also the things teams usually only learn after a few painful debugging cycles.

• Identify once, then trust it.
  Don’t spam identify on every app open. Call it when identity becomes known (login/signup) and when it materially changes (rare). Re-identifying with different IDs is a fast path to duplicates.
• Keep email as an attribute even if it’s your login.
  People change emails. If email is your key, you’ll eventually split a high-value customer into “old email” and “new email” profiles and your LTV segments will lie.
• Use a single naming convention for attributes across app + backend.
  If the app sends phone and backend sends phone_number, your SMS eligibility segments will be inconsistent and hard to debug.
• Test identity stitching with a real scenario, not a unit test.
  Example: A shopper browses anonymously, adds a product to cart, then creates an account, then completes purchase. You should see one profile with the full timeline—if not, fix identity before you build more journeys.

Common Mistakes to Avoid

Most “Customer.io isn’t sending correctly” tickets we see in D2C come back to one of these identity mistakes. They’re easy to make, and annoying to unwind after you’ve already built campaigns on top.

• Using different identifiers in different places.
  App identifies by email, backend identifies by customer_id. Result: duplicate people and broken suppression.
• Identifying too early with a placeholder ID.
  If you identify with a temporary guest ID and later identify with a real customer ID, you’ve created two people unless you explicitly merge.
• Not clearing identity on logout.
  Shared devices (tablets, family phones) become a compliance and CX nightmare when the wrong person gets messages.
• Tracking purchases only on-device.
  App tracking can miss edge cases (payment retries, web checkout, refunds). Your retention logic needs a server-side truth source for revenue events.
• Forgetting consent attributes.
  If opt-in/opt-out isn’t captured cleanly on the profile tied to the device token, you’ll either undersend (lost revenue) or oversend (complaints).

Summary

If you care about retention performance, Identify is the foundation—not a nice-to-have. Get the canonical ID consistent, call identify at the right moment, and your segments and journeys stop leaking. If your data looks “mostly right” but automations still misfire, identity stitching is usually where the story breaks.

Implement Identify with Propel

When we implement Identify cleanly, downstream retention work gets simpler: fewer duplicate profiles, cleaner suppression, and more reliable cart recovery and winback logic inside Customer.io. If you want us to review your current SDK calls, attribute schema, and anonymous-to-known stitching approach, book a strategy call—we’ll focus on the practical fixes that improve revenue outcomes, not just “events are firing.”