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

Overview

In Customer.io, Identify is the moment you stop treating someone like “a device” and start treating them like “a customer”—with purchase history, cart intent, and lifecycle state tied to one profile. If you want tighter cart recovery, cleaner winbacks, and repeat purchase flows that don’t misfire, identity stitching is the foundation; if you want a second set of eyes on your tracking plan, book a strategy call.

In most retention programs, Identify is where things quietly break: someone browses anonymously, adds to cart, then logs in—and the cart abandonment flow never triggers because the cart event lives on an anonymous profile that never got merged.

How It Works

At the SDK level, you’re managing two states: anonymous activity (pre-login/pre-email capture) and known activity (after you can confidently tie actions to a person). The Identify call tells Customer.io: “this device/session belongs to this person,” and it’s what lets Customer.io merge earlier anonymous events into the right customer profile.

• Before Identify: events are attributed to an anonymous profile (often device-based). This is common during product discovery, browsing, and early cart building in mobile apps.
• Identify call: you send a stable identifier (typically your internal customer ID; sometimes email as a secondary key) plus customer attributes you want available for segmentation and personalization.
• After Identify: subsequent events land on the known person, and Customer.io can stitch prior anonymous activity to that person—so your cart, browse, and checkout intent actually powers retention automation.
• Attribute updates: Identify is also how many teams keep a person’s profile current (VIP tier, first order date, last purchase date, subscription status), which directly impacts who enters repeat purchase and reactivation journeys.

D2C scenario: A shopper installs your app, browses “hydration packs,” adds one to cart, then creates an account to save shipping info. If you call Identify at account creation/login, the earlier Viewed Product and Added to Cart events can be stitched to the now-known profile—so your push/email cart recovery can reference the actual product they added, not a generic fallback.

Step-by-Step Setup

You’re aiming for two outcomes: (1) one person = one profile, and (2) all high-intent events (view, cart, checkout, purchase) end up on that profile. The steps below are the order that tends to keep data clean in production.

1. Install the correct Customer.io SDK for your app (iOS/Android/React Native/Flutter/Expo). Confirm you can see SDK traffic in Customer.io before you touch Identify logic.
2. Define your “source of truth” identifier (recommended: your internal customer ID). Decide whether you’ll also store email/phone as attributes for messaging channels and support workflows.
3. Pick the exact moments you will call Identify:
   • Account creation (best: you’re creating the identity for the first time)
   • Login (required: returning customers)
   • Email capture (sometimes: if you allow “guest” checkout or newsletter capture in-app—only do this if you trust the email)
4. Send Identify with core attributes you’ll actually use (don’t dump your whole user table). Typical retention-critical attributes:
   • email (if you email)
   • phone (if you SMS/WhatsApp)
   • first_name
   • created_at (account created timestamp)
   • customer_status (prospect / first_time_buyer / repeat_buyer / subscriber)
   • last_order_at, order_count, lifetime_value (if you have them server-side, keep them updated)
5. Immediately track a “Login” or “Account Created” event after Identify. In practice, this becomes a reliable trigger for post-login personalization and a sanity check that Identify is firing.
6. Verify anonymous-to-known stitching by testing a full flow: fresh install → browse → add to cart → login → check the person profile in Customer.io and confirm the pre-login events appear under the known person.
7. Backstop identity on critical moments: if checkout requires authentication, call Identify again at checkout start. This prevents edge cases where the app session didn’t persist identity correctly.

When Should You Use This Feature

Identify is not optional if you want retention automation that behaves like it’s reading the same customer story across sessions and devices. You’ll feel the impact most when you’re relying on pre-purchase intent and post-purchase state to drive messaging.

• Cart recovery that references the exact cart: Identify ensures the cart events created while browsing anonymously attach to the customer once they log in or create an account.
• Repeat purchase timing: if your replenishment journeys depend on “last purchased SKU/category,” Identify helps consolidate purchases across app sessions so you don’t under-message (or over-message) returning buyers.
• Reactivation based on true inactivity: without identity stitching, someone who reinstalled the app can look “new,” and you’ll accidentally send winbacks to active customers (or miss real churn risk).
• Cross-device continuity: shoppers browse on mobile, buy on desktop, then come back in-app. Identify helps unify that behavior so your segmentation doesn’t fragment.

Operational Considerations

Once Identify is live, the work shifts from “is data flowing?” to “is data usable for segmentation and orchestration?” This is where most teams either get clean automation—or months of debugging duplicate profiles and inconsistent triggers.

• Segmentation depends on stable IDs: pick one primary identifier and stick to it. If you mix email-based IDs and internal IDs inconsistently, you’ll create duplicates that split purchase history and break frequency logic.
• Attribute ownership matters: decide which attributes are set app-side (real-time, session context) vs server-side (orders, LTV, subscription status). In practice, order metrics are safer server-side; the SDK should focus on behavioral intent.
• Event timing vs Identify timing: if you track “Added to Cart” before Identify and never stitch, your cart recovery triggers won’t see it. When in doubt, call Identify as early as you can do it confidently, then track high-intent events.
• Orchestration reality: your journeys will reference attributes and events. If Identify updates overwrite attributes (like customer_status) incorrectly, you’ll route people into the wrong flows (e.g., treating repeat buyers like prospects).
• Device management: for mobile, make sure the identified person retains device tokens for push. If identity resets on logout/login, you can end up with “known customer, no device,” which tanks push delivery rates.

Implementation Checklist

If you want Identify to actually improve retention performance (not just “send data”), run through this checklist before you scale campaigns.

• Primary identifier chosen (internal customer ID preferred) and documented
• Identify fires on account creation and login (and optionally at checkout start)
• Core attributes mapped and intentionally limited (email/phone/status/order metrics)
• Anonymous browsing + cart events are visible on the known profile after login
• Duplicate profile risk assessed (email changes, guest checkout, multiple devices)
• At least one segment built to validate: “Added to Cart in last 4 hours AND no Purchase”
• At least one journey tested end-to-end using a real device (not just simulator logs)

Expert Implementation Tips

These are the small operator moves that keep your identity layer from becoming the silent reason your retention numbers stall.

• Identify early, but only when you trust the identity: login and verified email capture are safe. Unverified newsletter capture can create long-term profile pollution if people typo emails.
• Keep “state” attributes server-truthy: things like order_count and last_order_at should come from your backend/order system. Let the SDK focus on intent signals like view/cart/checkout.
• Log identity transitions: track an event like identity_linked with fields (method: login/signup/checkout) so you can debug stitching issues without guessing.
• Use consistent naming for commerce events: if your cart event payload changes between anonymous and logged-in states, your journey conditions will miss half the audience.
• Test reinstall behavior: uninstall/reinstall is common in D2C. Make sure a returning customer who logs in after reinstall ends up on the same profile and doesn’t re-enter new customer flows.

Common Mistakes to Avoid

Most Identify problems don’t show up as errors—they show up as “why is cart recovery underperforming?” or “why are segments smaller than expected?” These are the usual culprits.

• Using email as the only identifier when emails can change: this often creates duplicates and splits purchase history.
• Calling Identify too late: if Identify only fires after purchase, you lose the entire pre-purchase intent layer that powers recovery and conversion.
• Overwriting good attributes with nulls: some implementations send empty values on Identify, wiping fields used in segmentation (VIP tier, SMS opt-in, etc.).
• Tracking cart/checkout events on anonymous profiles and never stitching: journeys won’t trigger reliably, and message personalization falls back to generic copy.
• Not handling logout: if your app supports logout, make sure subsequent anonymous behavior doesn’t accidentally attach to the prior user on shared devices.
• Assuming “data in Customer.io” means “usable in journeys”: always validate with a real segment and a real journey trigger, not just event logs.

Summary

If you care about cart recovery, repeat purchase timing, and clean reactivation, Identify is the lever that makes your behavioral data actionable. Implement it early in the session, keep identifiers stable, and validate stitching with real device testing before you scale spend and sends.

Implement Identify with Propel

If your team is seeing duplicates, missing cart triggers, or “mystery gaps” between app behavior and what Customer.io segments show, it’s usually an Identify/stitching issue—not a copy issue. If you want an operator’s pass on your SDK tracking plan and how it maps to retention journeys, book a strategy call and we’ll pressure-test the identity layer against the flows that drive revenue.