Identify People (SDK): Stitch Anonymous to Known Users for Retention

Overview

If you want cart recovery, post-purchase, and winback to work reliably, your app needs clean identity—otherwise you’re messaging “ghost” profiles that never reconcile. This is where Customer.io identity comes in; if you want a second set of eyes on your tracking plan before you ship, book a strategy call and we’ll pressure-test it like we would for a live D2C program.

In practice, “Identify” is the moment you tell Customer.io: this device/session is now a real person (with a stable ID), and any future events should roll up to that same profile. When you get it right, you stop leaking revenue from broken cart abandonment and you can actually segment by behavior across sessions and devices.

How It Works

On SDK implementations, identity usually starts anonymous (app install, first browse session) and becomes known later (login, account creation, email/SMS capture at checkout). The identify call is the bridge that stitches those worlds together so your events and attributes land on the same person profile.

• Before identify: events often attach to an anonymous profile/device context. You’ll see browsing and add-to-cart activity, but you can’t reliably message if you don’t have a deliverable identifier (email/phone) and a stable person ID.
• At identify: your app sends a stable person identifier (the ID you will always use for that customer) plus optional attributes (email, phone, first_name, loyalty_tier, etc.). From this point on, Customer.io treats new events as belonging to that person.
• After identify: your tracking becomes retention-grade: cart events, product views, purchases, and subscription changes all tie back to one profile—so segments and automations don’t fragment.
• Identity stitching reality: most retention programs break when teams identify inconsistently (sometimes with email, sometimes with internal user_id) or identify too late (after key events already fired). The goal is simple: pick one canonical ID and call identify as soon as you legitimately know who the person is.

Step-by-Step Setup

You’re not “implementing a feature” here—you’re locking down the identity rules your entire retention program will depend on. Treat this like payment instrumentation: define the ID, define the moment, and make it impossible for engineers to guess.

1. Choose your canonical customer ID (do this first).
   Use a stable, internal customer_id/user_id that never changes. Avoid using email as the primary ID if it can change (people do update emails).
2. Install the Customer.io SDK and initialize it early in app startup.
   Initialize on app launch so you capture early-session events (product views, category browsing). If you initialize late, you’ll miss the exact behaviors you want for discovery and cart recovery.
3. Fire identify immediately after you know the user.
   Common D2C moments: login success, account creation, “continue with email” capture, or checkout where the email/phone is confirmed.
4. Send attributes with identify (keep it tight).
   At minimum: email (if you have it) and any retention-critical fields like phone, accepts_marketing, country, timezone. Don’t dump your entire user object—bloated profiles slow down segmentation and create messy conditions later.
5. Track events both before and after identify, but validate stitching.
   You want pre-identify events (browse/add-to-cart) to be useful once the person becomes known. After you ship, verify in Customer.io that the same person profile shows the full timeline (not split across multiple profiles).
6. Handle logout explicitly.
   When someone logs out, reset/clear the identified user in the SDK so the next person on that device doesn’t inherit the previous customer’s events and messaging eligibility.

When Should You Use This Feature

If your program depends on behavior-based triggers, identify is non-negotiable. It’s the difference between “we sent a cart email” and “we reliably hit the person who actually built the cart on mobile yesterday and completed purchase on desktop today.”

• Cart abandonment that starts anonymous and ends known.
  Scenario: a shopper browses in your app, adds two items, then enters email at checkout but bounces. If you identify at email capture, you can stitch the earlier add-to-cart events to the now-known profile and trigger a cart recovery sequence that includes the exact items.
• Repeat purchase and replenishment.
  If your “Purchased” events don’t consistently attach to the same person ID, your replenishment logic will misfire (wrong timing, wrong SKU, wrong channel eligibility).
• Reactivation based on last engagement across devices.
  Winback segments like “no sessions in 45 days” only work if sessions are stitched to the same person after login—otherwise you’ll mark active customers as inactive and annoy them.
• Loyalty/VIP orchestration.
  If you’re gating offers by tier or LTV, identify is how you keep tier attributes attached to the right profile and prevent duplicate VIP messaging.

Operational Considerations

Most teams get identify “working” and still end up with messy segments, duplicate profiles, and unreliable triggers. The fix isn’t more campaigns—it’s tightening the data flow and identity rules so your orchestration behaves predictably.

• Segmentation depends on stable IDs.
  Pick one canonical ID and stick to it everywhere (SDK, server, imports). Mixing identifiers (email in one place, numeric ID in another) is the fastest path to duplicates and broken suppression logic.
• Attribute hygiene matters more than attribute volume.
  Decide which fields are “source of truth” from the app vs. backend. For example, let the backend own total_spent and order_count, while the app owns push_enabled and last_app_version.
• Event ordering and timing can break journeys.
  If add_to_cart fires before SDK init or before identify, you might still be fine—if stitching works. But if identify happens much later (or not at all), your cart journey will trigger on an anonymous profile and never reach the right person.
• Cross-device reality:
  SDK identity is device-scoped until you identify. If your customers browse on mobile and buy on desktop, you need the same canonical ID across platforms or you’ll undercount LTV and over-send winbacks.
• QA like an operator:
  Don’t just confirm events are arriving. Confirm that one person profile shows: anonymous browse → identify → add payment → purchase, with no duplicate profiles created along the way.

Implementation Checklist

If you run through this checklist before you ship, you’ll avoid the common “it tracks, but nothing segments correctly” trap that slows retention teams down for months.

• Canonical person ID defined (stable, non-email, documented)
• SDK initialized on app launch (not delayed until after login)
• identify fired on login/signup/email capture (earliest legitimate moment)
• Identify payload includes email/phone (when available) + only retention-critical attributes
• Logout clears/reset identity to prevent profile contamination
• Key events tracked: product_view, add_to_cart, begin_checkout, purchase
• Stitching QA: pre-identify events visible on the identified profile
• Duplicate profile monitoring plan (weekly check during first month)

Expert Implementation Tips

These are the moves that keep identity clean when your catalog, channels, and traffic scale—especially once you start layering in paid retargeting audiences and multi-step journeys.

• Identify earlier than you think (but only when it’s real).
  Email capture at checkout is usually earlier than account creation. If you wait for “account created,” you’ll lose a big chunk of cart recoveries.
• Standardize event naming and properties around retention questions.
  For cart recovery, you care about cart_id, line items, and value. For replenishment, you care about SKU and quantity. Define these once so your journeys don’t require fragile Liquid gymnastics later.
• Use one-way enrichment where possible.
  Let the backend enrich high-trust fields (order_count, LTV) and keep the app focused on behavioral signals. This prevents “attribute thrash” where values flip back and forth and segments churn.
• Build a stitching test script for QA.
  Example: install app → browse 3 products → add to cart → enter email → force close → reopen → confirm the same Customer.io profile shows the full chain and is eligible for the cart journey.

Common Mistakes to Avoid

Most retention issues blamed on “campaign performance” are actually identity issues. Fix these and your existing flows often lift without changing a single subject line.

• Using email as the primary ID and later changing it.
  That’s how you create duplicates and lose historical events.
• Calling identify multiple ways across platforms.
  Web uses email, mobile uses user_id—now you have two people for one customer.
• Identifying too late (after the valuable events).
  If identify happens after checkout completion, you can’t reliably use pre-purchase intent signals for recovery and upsell.
• Not resetting on logout/shared devices.
  This is a quiet disaster in households: one person logs in, logs out, someone else browses, and you start sending the wrong messages to the wrong inbox.
• Overstuffing attributes.
  Huge payloads create inconsistent data types (string vs number), slow down segmentation, and make journeys brittle.

Summary

If you care about retention outcomes, identify is the foundation: it stitches behavior to a real customer profile so your segments and journeys hit the right person. Get the canonical ID and timing right, and cart recovery + repeat purchase flows become dramatically more reliable.

Implement Identify with Propel

If you’re rolling out identify across mobile/web and want to avoid the usual duplicate-profile and broken-stitching pitfalls, we can help you design the canonical ID rules, event schema, and QA plan inside Customer.io. If that’s useful, book a strategy call—we’ll map the exact identify moments in your funnel (browse → cart → checkout → purchase) and make sure your retention automations have clean inputs.