Identify people (SDK) so your retention flows hit the right customer every time

Overview

If you’re running retention in Customer.io, Identify is the moment your app stops treating someone like “a device” and starts treating them like “a customer.” If you want help pressure-testing your identity plan before you ship it (and before it quietly breaks attribution and segments), book a strategy call.

In practice, most D2C teams feel Identify pain when cart recovery or post-purchase flows underperform for “no obvious reason.” The usual culprit isn’t copy—it’s identity: events tied to an anonymous profile, purchases tied to a different profile, and messages going to the wrong person (or not going at all).

How It Works

On SDK implementations, you typically start with an anonymous app user (Customer.io still sees activity, but it’s not reliably marketable until you attach a real customer identity). Identify stitches that app activity to a known person profile by assigning a stable identifier and (optionally) updating attributes.

• Before Identify: the SDK can collect behavior (screen views, add-to-cart, product views) under an anonymous profile/device context.
• At Identify: you call identify with a stable customer identifier (most teams use customer_id from your auth/user table; some use email if it’s guaranteed unique and permanent).
• After Identify: subsequent events are tied to the known person, and Customer.io can reliably evaluate segments, frequency rules, and campaign eligibility.
• Attribute updates: many SDKs let you send traits alongside Identify (e.g., email, phone, first_name, marketing_opt_in, last_order_at). This is what unlocks practical segmentation like “VIPs,” “first-time buyers,” and “lapsed 60 days.”

Real D2C scenario: a shopper browses on mobile, adds a product to cart, then logs in at checkout. If you only track Added to Cart anonymously and forget to Identify at login, your cart recovery flow may never fire for the known customer—or it fires against an anonymous profile that can’t receive email/SMS.

Step-by-Step Setup

The goal here is simple: Identify once you have a trustworthy customer ID, then keep it consistent forever. Most retention programs improve immediately when Identify is called at the right moments and you stop generating duplicate people.

1. Pick your canonical identifier. Use a stable internal ID (recommended) or a truly stable unique email. Don’t use anything that can change (like phone-only if customers swap numbers) unless you have a migration plan.
2. Install the Customer.io SDK and initialize it early. Initialize on app start so pre-login activity is captured. Keep this consistent across iOS/Android/web if you support multiple surfaces.
3. Track anonymously before login (optional but common). Track key discovery events like Product Viewed and Added to Cart even before login—these become valuable once stitched.
4. Call identify immediately after authentication. Trigger Identify on login, account creation, and any “email capture” moment that creates a real user record.
5. Send core traits with Identify. At minimum: email (if you have it), phone (if opted in), created_at, marketing_opt_in, and anything you use for suppression/eligibility (like sms_opt_in).
6. Verify stitching in Customer.io. In Activity Logs / person profile, confirm that pre-login events appear on the identified profile after login and that new events continue on the same profile.
7. Handle logout explicitly. When a user logs out, reset/clear the identified user in the SDK so the next person on the device doesn’t inherit the previous identity.

When Should You Use This Feature

Identify matters any time you want Customer.io to make “person-level” decisions—eligibility, frequency, suppression, and personalization. If you’re sending based on behavior, you’re already depending on Identify whether you realize it or not.

• Cart recovery on mobile: shoppers add to cart while anonymous, then authenticate at checkout. Identify is what ties the cart event to a reachable customer profile.
• Post-purchase cross-sell: purchase happens in-app, but email/SMS is only on the account record. Identify ensures purchase events land on the same profile that has deliverable channels.
• Reactivation: you can’t accurately compute “last seen” or “last purchase” if a customer’s activity is split across multiple profiles.
• Multi-device behavior: the same customer browses on iPad and buys on phone. A consistent identifier lets Customer.io treat that as one customer journey, not two half-stories.

Operational Considerations

Identity is one of those things that looks “done” after the first implementation, then quietly degrades as the app evolves. The operators who win keep identity boring: consistent IDs, consistent event naming, and predictable data flow into segments.

• Segmentation depends on identity stability. If customers get duplicated, segments like “Viewed product X in last 7 days AND not purchased” will undercount and your retargeting will look weaker than it should.
• Data flow timing matters. If Added to Cart fires before Identify and you don’t stitch, your cart triggers may run against an anonymous profile. Decide whether you want to: (a) delay cart automation until identity is known, or (b) stitch reliably so it doesn’t matter.
• Orchestration across channels. Email/SMS eligibility usually sits on the person profile (attributes like email, sms_opt_in). If Identify happens late, your workflow may evaluate eligibility before those attributes exist.
• Duplicate resolution is not a growth lever. It’s hygiene. But it directly impacts frequency caps, suppression, and revenue attribution—so treat it like production infrastructure.

Implementation Checklist

Before you call this “shipped,” make sure the basics are locked. These checks prevent the classic failure mode where everything works in QA but breaks under real user behavior.

• Canonical identifier selected and documented (and shared with engineering + retention)
• identify called on login, account creation, and any authenticated session restore
• Logout clears identity in the SDK
• Core traits sent with Identify (email/phone/opt-in flags)
• Key pre-login events tracked (at least product view + add to cart) and confirmed stitched post-login
• Customer.io profile shows a single person per customer in common paths (browse → login → purchase)
• Segments relying on “last activity” and “last purchase” match expected counts after rollout

Expert Implementation Tips

Most retention teams don’t need more events—they need fewer, cleaner identities. These are the patterns that keep your automations reliable as you scale spend and complexity.

• Prefer internal IDs over email as the primary key. Emails change. Internal IDs don’t. Store email as an attribute and update it when it changes.
• Identify as early as you can, but not earlier than you should. Don’t Identify on a random email field blur unless it actually creates a user record you’ll keep. Otherwise you create “ghost customers” that inflate counts and confuse suppression.
• Bundle opt-in state with Identify. If SMS opt-in arrives a step after account creation, you’ll see missed sends or compliance risk. Keep email_opt_in/sms_opt_in current.
• Instrument a ‘Logged In’ event after Identify. It’s a clean debugging hook in Customer.io when you’re validating stitching and session behavior.

Common Mistakes to Avoid

These are the mistakes that make cart recovery look “fine” in dashboards while revenue quietly leaks.

• Calling Identify with different IDs for the same person. Example: using email sometimes and customer_id other times. That’s how you get duplicates and broken frequency caps.
• Identifying too late in the funnel. If Identify happens after checkout, your pre-purchase intent never informs recovery or upsell logic.
• Not clearing identity on logout/shared devices. This leads to messaging the wrong person—especially common on tablets in retail environments or shared family devices.
• Relying on anonymous profiles for deliverable sends. Anonymous activity is useful, but your money flows come from known profiles with channels attached.
• Letting traits drift. If email/phone/opt-in flags aren’t updated, segments become stale and you’ll see unexplained drops in reachable audience size.

Summary

If you want Customer.io automations to behave like a retention system (not a best-effort broadcaster), Identify is non-negotiable. Get the ID right, call it at the right moments, and validate stitching on real user paths. Once identity is stable, your cart recovery, post-purchase, and winback flows stop fighting hidden data issues.

Implement Identify with Propel

If you’re implementing Identify and want to avoid the usual traps—duplicate people, late identity, opt-in drift—we can help you map the exact calls and traits your retention program depends on in Customer.io. If it’s useful, book a strategy call and we’ll pressure-test your identity stitching against your highest-impact flows (cart recovery, post-purchase, and reactivation).