Anonymous Activity (SDK): Track Pre-Login Behavior and Stitch It to a Customer Profile

Overview

If you’re using Customer.io for retention, anonymous activity is how you stop losing the highest-intent behavior that happens before a shopper logs in or identifies (product views, add-to-cart, checkout starts). If you want help pressure-testing your tracking plan against real retention flows, book a strategy call—most issues we see aren’t “missing events,” they’re identity stitching and timing.

In D2C, this is the difference between sending a generic “come back” email and sending a cart recovery that actually reflects what happened in-session, even if the shopper only identifies at the end.

How It Works

Anonymous activity works by letting your app/web client send events tied to an anonymous identifier first, then later merging those events into a known person profile when you finally learn who the shopper is (email, customer ID, login, or account creation). In practice, this tends to break when teams identify too late, identify inconsistently across devices, or fire duplicate events from both client and server.

• Before identification: Your SDK generates/uses an anonymous ID and tracks events (e.g., Product Viewed, Added to Cart, Checkout Started) against that anonymous profile.
• When you learn identity: You call identify (or equivalent) with your stable user identifier (email/customer_id). Customer.io stitches the anonymous activity onto the identified person.
• After stitching: Segments, campaigns, and message personalization can use the pre-login events as if they were always part of the known profile—so your cart recovery and browse follow-ups don’t lose context.
• Key mechanic: Stitching is only as good as the consistency of the identifier you pass at identify-time. If you sometimes identify by email and sometimes by internal ID without a mapping strategy, you’ll create split profiles and orphaned intent.

Step-by-Step Setup

You’re setting this up so the SDK captures intent immediately, then cleanly merges it when the shopper becomes known. Treat this like revenue instrumentation: define events first, then wire them, then validate stitching with real device tests.

1. Install the Customer.io SDK in your app/web client.
   Use the appropriate Customer.io SDK (iOS/Android/React Native/etc.) and confirm events are reaching your workspace in real time (Activity Log / event stream).
2. Decide your “stable identity” rule.
   Pick the identifier you’ll use at identify time (most D2C brands use email once captured; some use a customer ID). Document it and enforce it across platforms.
3. Start tracking anonymous events immediately on session start.
   Fire events as the shopper browses—don’t wait for login. At minimum for retention:
   • Product Viewed (include product_id, variant_id, category, price)
   • Added to Cart (include cart_id, line items, quantities)
   • Checkout Started (include cart_id, subtotal, currency)
4. Call identify the moment you capture identity.
   Common D2C moments:
   • Account login
   • Email capture (newsletter modal, checkout email step)
   • Order confirmation (if you truly can’t identify earlier)
   The earlier you identify, the more reliable your recovery and recommendation flows become.
5. Attach customer attributes at identify-time.
   Send attributes you’ll actually segment on (e.g., first_purchase_date, last_order_date, vip_tier, sms_opt_in). Don’t bloat profiles with noise—operators end up fighting messy segmentation later.
6. Validate stitching with a real scenario test.
   Do a full run on a fresh install/device:
   • Browse 2 products → add one to cart (still anonymous)
   • Enter email / log in → call identify
   • Confirm the known profile now shows the earlier events

When Should You Use This Feature

You use anonymous activity whenever meaningful purchase intent happens before you can reliably identify the shopper. For most D2C brands, that’s basically every mobile session and a big chunk of web traffic.

• Cart abandonment that starts anonymous. A shopper adds a product, gets distracted, then later enters email at checkout—anonymous activity ensures your cart recovery reflects the actual cart, not a generic “still thinking?” message.
• Browse-to-buy personalization. If someone views “hydration serum” twice before subscribing, you can trigger a post-identify education sequence based on those views rather than guessing.
• Reactivation with remembered intent. When a lapsed customer returns anonymously (common on mobile), you can stitch their new browsing session once they log in and avoid treating them like a cold prospect.
• Paid traffic protection. For high-CAC campaigns, anonymous intent capture is often the only way to prove and monetize what happened before identity capture.

Operational Considerations

Anonymous activity is easy to “turn on” and surprisingly easy to ruin with sloppy identity and event design. The retention impact comes from clean data flow and orchestration that respects how shoppers actually move across devices and sessions.

• Segmentation design: Build segments that assume identity arrives late. Example: “Checkout Started in last 2 hours AND no Purchase event” should work even if the checkout started anonymously and the user identified 10 minutes later.
• Event naming + payload discipline: Keep event names stable and payloads predictable. If Added to Cart sometimes includes line items and sometimes doesn’t, your cart recovery personalization breaks at the worst time.
• Identity stitching realities:
  • Identify too late = you miss the window for fast channels (push/SMS) and you’ll over-rely on email.
  • Multiple identifiers = duplicate profiles. Pick one primary key and stick to it.
  • Cross-device = not magic. Anonymous activity stitches when you identify on that device/session. If a shopper browses on mobile and buys on desktop without logging in, you’ll still have gaps.
• Orchestration timing: Add short delays or “wait until identified” logic in flows that require email/SMS. Otherwise you’ll trigger a cart flow before the profile has a sendable address, then wonder why conversion attribution looks off.
• Source-of-truth conflicts: If you also send server-side ecommerce events (Shopify/warehouse), decide which events are authoritative to avoid double-firing purchases or cart updates.

Implementation Checklist

Before you rely on anonymous activity for revenue-critical automations, run through this list and confirm it’s true in production—not just in staging.

• SDK installed and sending events from all supported platforms (iOS/Android/web).
• Anonymous events fire on key intent actions (view, add-to-cart, checkout start) without requiring login.
• identify fires immediately when email/login is captured (not only after purchase).
• Identifier strategy documented (email vs customer_id) and consistent across platforms.
• Event payloads include the fields your messages need (product name, image URL, price, cart line items, cart_id).
• Test confirms anonymous events appear on the identified profile after stitching.
• Deduplication plan in place if server-side events also exist (especially Purchase).

Expert Implementation Tips

These are the things that separate “we track anonymous events” from “our recovery flows print money.” In most retention programs, we’ve seen the lift come from earlier identity capture and cleaner stitching, not from adding more message steps.

• Identify at email capture, not at account creation. If checkout collects email first, identify right there. That’s your earliest reliable key for cart recovery.
• Use a single cart identifier end-to-end. Pass cart_id on Added to Cart and Checkout Started. Then your workflow can reconcile “cart changed” vs “same cart” instead of spamming.
• Design events for message assembly. If you want a 3-item cart module in email/SMS landing pages, include line items (name, variant, image, URL) at track-time. Relying on later lookups is where latency and missing data show up.
• Gate high-intent flows on a short window. For example, wait 10–20 minutes after Checkout Started before sending, but exit immediately on Purchase. That protects CX and reduces “I already bought” complaints.

Common Mistakes to Avoid

Most teams don’t fail because the SDK is broken—they fail because the identity story isn’t enforced and the event schema isn’t built for retention execution.

• Only tracking after login. That defeats the point and leaves your highest-intent funnel stages invisible.
• Identifying with different keys in different places. Email in one flow, customer_id in another → duplicate people → fragmented lifecycle history → unreliable segmentation.
• Triggering campaigns before profiles are sendable. If the person doesn’t have email/SMS yet, the workflow “runs” but never delivers—then you misread performance.
• Double-counting purchases. Client-side purchase + server-side purchase without dedupe creates false conversions and breaks holdouts and incrementality reads.
• Event payloads too thin to personalize. If Added to Cart doesn’t include product context, your cart email becomes generic and conversion drops.

Summary

If pre-login intent matters (it does), anonymous activity is the tracking layer that keeps it usable for retention. Get the SDK events firing early, identify as soon as you capture email/login, and enforce one identity rule so stitching stays clean.

Implement Anonymous Activity with Propel

If you’re implementing anonymous activity inside Customer.io, the fastest path is usually a tight tracking spec (events + payloads + identify timing) tied directly to your cart recovery and repeat purchase flows. If you want a second set of eyes on your identity stitching and orchestration plan before it hits production, book a strategy call—we’ll sanity-check it the same way we do for live D2C retention programs.