Authentication (SDK): stitch anonymous sessions to known customers in Customer.io

Overview

If you’re sending app events into Customer.io from a web or mobile SDK, authentication is the difference between “we saw a cart” and “we know who built that cart.” When identity stitching is clean, cart recovery and repeat purchase automations trigger on the right profile—if it’s messy, you’ll see duplicate people, missing attribution, and broken suppression logic.

If you want a second set of eyes on your identity plan (anonymous → logged-in → logged-out, multiple devices, email capture, etc.), book a strategy call—this is where most retention programs quietly leak revenue.

How It Works

In practice, authentication for SDK tracking is about one thing: making sure every event your app emits can be tied to the right person record over time, even when they start anonymous. You’re essentially managing an identity lifecycle—anonymous device/session identifiers first, then a durable customer identifier once they authenticate or you capture email/phone.

• Anonymous tracking starts with a device/session identity. Your SDK will generate (or you provide) an anonymous identifier so browsing, product views, and “Add to Cart” events aren’t lost before login.
• On login (or account creation), you “identify” the user. The key move is calling the SDK’s identify method with a stable customer ID (and optionally email/phone as attributes). This is what stitches pre-login activity to the known profile.
• After identify, all future events should reference the same stable ID. That consistency is what makes Customer.io segmentation and suppression reliable (e.g., don’t send cart recovery to someone who already purchased).
• Logout is a real edge case. If the user logs out, you typically reset/clear identity in the SDK so the next person on that device doesn’t inherit the previous user’s event stream.

Real D2C scenario: A shopper on iOS browses your new drops, adds a bundle to cart, then bounces. The next day they open the app again, create an account, and complete checkout. If you identified them correctly at signup, the cart activity and the purchase land on one profile—so your cart abandonment flow can exit instantly, your post-purchase cross-sell can personalize to the bundle they almost bought, and you don’t accidentally send “You left something behind” after they’ve already paid.

Step-by-Step Setup

Before you touch campaigns, get the app-side identity rules right. Most “Customer.io isn’t working” complaints in retention are actually “we’re identifying inconsistently across platforms,” which breaks segmentation and makes automations look flaky.

1. Pick your canonical customer identifier.
   Use a stable internal user ID (not email) as the primary identifier. Emails change; user IDs shouldn’t. Decide this once and use it everywhere (web + iOS + Android).
2. Install the Customer.io SDK(s) and confirm basic event delivery.
   Validate that events fire in dev/staging first. Don’t move on until you can see a simple event (e.g., Product Viewed) arriving consistently.
3. Start anonymous tracking immediately on app open / site load.
   Let the SDK establish an anonymous identity so pre-login behavior is captured. This is the backbone for product discovery and cart intent signals.
4. Call identify at the moment of authentication.
   On login/signup, call the SDK identify method with your canonical user ID. Attach key attributes you’ll segment on later (email, phone, acquisition source if you have it, etc.).
5. Send events after identify with the same ID context.
   Ensure your event pipeline doesn’t keep emitting events tied to the old anonymous identity after login—this is where duplicate profiles come from.
6. Handle logout explicitly.
   When a user logs out, reset/clear the SDK identity (implementation varies by SDK). This prevents the next session from polluting the previous customer’s profile.
7. Test stitching with a real flow.
   Run: anonymous browse → add to cart → create account → purchase. Confirm in Customer.io that the pre-login events appear on the same person profile as the post-login purchase.

When Should You Use This Feature

If your retention strategy depends on intent signals that often happen before login, authentication is non-negotiable. The moment you want to trigger messages off “behavior,” you need confidence those behaviors belong to the right person.

• Cart recovery in app-first or hybrid experiences. If shoppers can build carts before logging in, you need stitching so the cart flow triggers on the eventual logged-in customer—not a throwaway anonymous profile.
• Browse-to-buy retargeting. Product viewed and category affinity only become useful when they follow the customer across sessions and devices.
• Reactivation based on last activity. If “Last Seen” is split across duplicate profiles, your winback segments either undercount or spam active customers.
• Cross-device continuity. If someone browses on mobile and buys on desktop, consistent identify rules are what keep your post-purchase and replenishment logic accurate.

Operational Considerations

Once you wire authentication, the next set of problems are operational: how identity choices ripple into segmentation, data flow, and orchestration. This is where teams accidentally create “ghost audiences” or suppress the wrong people.

• Segmentation depends on identity stability. If you segment on email but identify on user ID (or vice versa) inconsistently across platforms, you’ll see mismatched audiences and confusing counts.
• Event timing matters for orchestration. If identify happens after you emit key events (like Checkout Started), your cart recovery entry logic can miss the trigger or attach it to an anonymous profile.
• Duplicate profiles break frequency controls. In most retention programs, frequency caps and “exit on purchase” rules assume one person = one profile. Duplicates mean customers can get both the abandonment series and the post-purchase series.
• Attribute hygiene is part of authentication. Treat email/phone as attributes that can update over time. Decide whether your app overwrites blanks, how you handle nulls, and what source of truth wins.
• Plan for guest checkout and email capture. If you capture email before login (newsletter modal, checkout email step), decide whether you identify at capture time or wait until account creation—either choice affects how quickly you can trigger recovery.

Implementation Checklist

Use this to sanity-check the build before you scale any retention automations. Most issues show up here first—long before you notice performance drops in a cart or winback flow.

• Canonical customer ID defined and used consistently across web + mobile
• Anonymous tracking enabled and verified (pre-login events arrive)
• identify called immediately on login/signup (not minutes later)
• Key events (product view, add to cart, checkout started, purchase) fire with consistent naming and payloads
• Logout clears/resets identity to prevent cross-user contamination
• Stitching test passed: anonymous → identify → purchase shows as one profile in Customer.io
• Duplicate profile monitoring plan (spot checks + periodic audits)

Expert Implementation Tips

The difference between “working” and “reliable at scale” is usually a couple of opinionated rules in the app implementation. These are the ones that tend to hold up under real-world behavior.

• Identify on the earliest durable moment. If you can confidently assign a stable ID at email capture (not just at full account creation), you’ll recover more carts—because you can message sooner with less reliance on push token availability.
• Standardize event schemas across platforms. Don’t let iOS send add_to_cart while web sends Added to Cart. Normalization is what keeps segments and triggers consistent.
• Send purchase as the “source of truth” exit event. Your cart abandonment flow should exit on a single, unambiguous purchase event—not on a brittle attribute update that might lag.
• Be strict about logout resets on shared devices. This matters more than teams think for tablet-heavy households and retail-store devices—one bad session can poison your reactivation segments for weeks.

Common Mistakes to Avoid

Most identity bugs look like messaging problems downstream. If your cart recovery is “random,” it’s usually one of these.

• Using email as the primary identifier everywhere. Email changes and formatting varies. Use a stable internal ID and treat email as an attribute.
• Calling identify multiple times with different IDs for the same person. This creates duplicates and splits event history, which kills personalization and exit logic.
• Delaying identify until after key events fire. If the user adds to cart while anonymous and you only identify later, the cart event may never attach to the profile you message.
• Not resetting identity on logout. This is how you end up sending “Your order is on the way” to the wrong household member.
• Assuming stitching works the same across web and mobile. Web has cookies/session quirks; mobile has device IDs/push tokens. Treat them as different environments with one shared identity contract.

Summary

If you want retention automations to behave predictably, authentication has to be boring and consistent: anonymous capture first, identify at login, and clean resets on logout. Get that right and your cart recovery, post-purchase, and winback flows stop guessing and start targeting.

Implement Auth with Propel

If you’re rolling this out across web + iOS + Android, the hard part isn’t the SDK calls—it’s agreeing on identity rules and validating stitching against real shopping behavior. If you want an operator-led implementation plan tied to retention outcomes inside Customer.io, book a strategy call and we’ll map your anonymous-to-known flow, event schema, and the segments your programs actually depend on.