Anonymous Activity (SDK): Track Pre-Login Behavior and Stitch It to Known Customers

Overview

Customer.io becomes dramatically more useful for retention once you can see what people did before they logged in or gave you an email. If you stitch that anonymous browsing/cart activity to the right profile at the moment of identify, you stop losing high-intent signals and your cart recovery + repeat purchase flows get smarter fast. If you want a second set of eyes on your event plan and identity stitching, you can book a strategy call.

Anonymous Activity is the pattern where your app/site tracks events against an anonymous identifier first, then merges that activity into a known person once they authenticate or submit an email/phone.

How It Works

In practice, most D2C brands leak intent because they only start tracking once they have an email. Anonymous activity closes that gap: your SDK generates (or you provide) an anonymous ID, events get stored against it, and when the user identifies, Customer.io can merge the anonymous timeline into the identified profile.

• Anonymous session starts: your mobile/web SDK initializes and assigns an anonymous identifier (often stored in a cookie/localStorage on web or app storage/device context on mobile).
• You track events normally: product views, collection views, add-to-cart, begin-checkout, quiz answers, PDP scroll depth—whatever matters for retention and recovery.
• Identify moment happens: login, account creation, email capture modal, SMS capture, checkout step where you finally get an email/phone.
• Identity stitching: you call identify with your durable customer ID (and attributes). Customer.io associates the anonymous activity with the now-known person (either by merging or linking, depending on your integration pattern).
• Campaigns can trigger off the “real” behavior: cart recovery can trigger from an anonymous add-to-cart that later becomes known, and browse-based replenishment can use anonymous PDP views that happened before signup.

D2C scenario: A shopper on iOS views three SKUs, adds a bundle to cart, then bounces. Two days later they come back, enter email for a first-order discount, and complete checkout. With anonymous activity stitched correctly, your post-purchase cross-sell can reference what they browsed earlier, and your next cart recovery won’t miss the “added bundle” signal just because it happened pre-email.

Step-by-Step Setup

The goal here is simple: track high-intent events immediately (anonymous), then make sure you fire identify exactly once you have a durable identifier so Customer.io can stitch timelines cleanly.

1. Install the Customer.io SDK (web or mobile) and confirm it initializes on first app/site open.
   • Make sure initialization happens before you emit any commerce events (especially Viewed Product and Added to Cart).
   • Verify the SDK persists the anonymous identifier across sessions (cookie/storage on web; persistent storage on mobile).
2. Define your “anonymous-first” event taxonomy.
   • Minimum viable for D2C retention: Viewed Product, Viewed Collection, Added to Cart, Started Checkout, Removed From Cart.
   • Include stable properties you’ll actually segment on later: product_id, variant_id, price, currency, collection, quantity.
3. Track events immediately, even when the user is unknown.
   • Do not wait for email capture to start tracking—this is where most retention programs quietly underperform.
   • On web, ensure events still fire for users who decline cookies where required; if you gate tracking, align that with your consent strategy.
4. Pick a single durable identifier and standardize it across systems.
   • Best practice: your internal customer ID (not email) as the primary ID, then store email/phone as attributes.
   • This prevents profile fragmentation when emails change or when you support both email + SMS capture.
5. Call identify at the moment you actually know who they are.
   • Typical triggers: account created, login success, email submitted on capture modal, checkout step where email is collected.
   • Send key attributes at identify time (email, phone, first_seen_channel, acquisition source if you have it).
6. Validate stitching in Customer.io before you build automations.
   • In the activity feed, confirm anonymous events appear on the identified profile after identify.
   • Test edge case: anonymous browsing on one device, identify on another. Decide whether you’ll support cross-device stitching (usually requires login-based identity, not just cookies).
7. Only then wire up retention automations that depend on those events.
   • Cart recovery: trigger from Added to Cart or Started Checkout even if it happened pre-identify.
   • Product discovery: trigger browse follow-ups using Viewed Product frequency + category affinity.

When Should You Use This Feature

Anonymous activity is worth the effort when meaningful shopping behavior happens before you capture an email/phone—which is basically every modern D2C funnel. It’s especially high-leverage when you’re trying to improve recovery and increase second purchase rate with better intent signals.

• Cart recovery where email is collected late: shoppers add to cart, then only enter email at checkout or on a discount gate. Without anonymous activity, you miss the original cart build.
• Browse-based follow-ups: send “still thinking about…” messages based on multiple PDP views, even if the user only identifies later via account creation.
• Reactivation with preference signals: when someone comes back after 90 days and browses quietly, you can use that activity to tailor winback once they log in.
• Quiz or finder flows: people answer 5–10 questions anonymously; stitching lets you persist those preferences into segmentation and post-purchase upsell.

Operational Considerations

This tends to break not because the SDK can’t track anonymous events, but because identity and orchestration get messy across devices, platforms, and teams. Treat anonymous activity like a data product: define ownership, validate regularly, and build segments that assume some percentage of users won’t stitch cleanly.

• Segmentation reality: build segments that key off events and
• Data flow timing: if your identify call happens after purchase (common in rushed implementations), your cart recovery triggers will misfire or arrive too late. Identify should happen at login/email capture—not after order confirmation.
• Orchestration across channels: if you’re using push + email + SMS, make sure the profile has the right device tokens and subscription states at the time you want to message. Anonymous browsing without a reachable channel is still useful—but only once stitched.
• Deduplication: define a clear “Purchase” source of truth (SDK vs backend). If you track purchase client-side and server-side, you’ll inflate conversion metrics and break suppression logic.
• Cross-device stitching: cookies won’t solve this. If cross-device matters (it usually does), the only reliable bridge is authentication (login) or a deterministic identifier captured on both devices.

Implementation Checklist

If you run through this list and everything is true in production, your anonymous-to-known stitching is usually solid enough to build dependable retention automations on top.

• SDK initializes before any commerce events fire (web + iOS/Android as applicable).
• Anonymous identifier persists across sessions (and isn’t reset on app close or page refresh).
• Core events are tracked anonymously: Viewed Product, Added to Cart, Started Checkout, Purchase.
• identify fires at login/email capture (not after purchase).
• Identify payload includes your durable customer ID and channel attributes (email/phone) when available.
• Anonymous events appear on the identified profile after identify (spot check with real devices).
• Purchase deduplication rules are defined and tested (one event per order ID).
• Key segments account for “reachable” state (email deliverable, SMS subscribed, push token present).

Expert Implementation Tips

Once the basics are in, the wins come from tightening identity timing and making your events segmentation-friendly. In most retention programs, these details are the difference between “we have the data” and “the flows actually print money.”

• Identify earlier than you think: if you have an email capture modal, identify immediately on submit—don’t wait for account creation.
• Use stable IDs in event properties: always include product_id/variant_id so you can build dynamic content and suppress repeats (e.g., don’t recommend what they just bought).
• Track cart as both events and state: events tell you what happened; a cart “state snapshot” (line items array) helps you render accurate cart recovery content when the cart changes.
• Guard against event spam: throttle “Viewed Product” so you don’t send 40 events in a single scroll session. Your segments and reporting will thank you.
• Test stitching with real journeys: run a full flow—anonymous browse → add to cart → close app → reopen → email capture → confirm the cart recovery trigger sees the original add-to-cart timestamp.

Common Mistakes to Avoid

Most mistakes show up as duplicated profiles, missing cart triggers, or browse data that never becomes actionable because it doesn’t attach to a reachable person.

• Using email as the primary ID: it seems convenient until someone checks out with a different email, and now you’ve split lifetime value across profiles.
• Calling identify multiple times with different IDs: this creates hard-to-debug merges and “ghost” profiles.
• Firing identify after purchase: you’ll lose the ability to suppress cart recovery properly and your attribution gets muddy.
• Inconsistent event naming across platforms: “AddToCart” on iOS and “Added to Cart” on web will fracture segments and triggers.
• No order_id on Purchase: you can’t dedupe, and you’ll inflate revenue in reporting and break post-purchase logic.
• Assuming anonymous = unreachable forever: anonymous activity is only valuable if you have a plan to convert it into identified profiles via capture moments.

Summary

If you capture meaningful shopping intent before login, anonymous activity is a must. Track events immediately, identify the moment you have a durable ID, and validate stitching before you build recovery and repeat purchase automations. When it’s working, you stop losing the highest-intent signals in your funnel.

Implement Anonymous Activity with Propel

If you’re rolling this out across web + mobile, the tricky part isn’t “sending events”—it’s getting identity stitching, deduplication, and segmentation to hold up under real customer behavior. We can sanity-check your SDK instrumentation plan, identify timing, and event schema so your Customer.io flows (cart recovery, browse follow-ups, winback) actually trigger off the right signals. If that would help, book a strategy call and we’ll map the cleanest path from anonymous intent to revenue-driving automations.