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

Overview

If you want cart recovery and product-browse retargeting to work in Customer.io, you need clean tracking before a shopper ever logs in or checks out. Anonymous Activity is the part that captures pre-identify behavior (browse, add-to-cart, quiz answers) and then stitches it to the known profile the moment you can identify them—if you implement it correctly. If you want a second set of eyes on your event plan and identity stitching, book a strategy call and we’ll pressure-test it like we would for a live retention program.

In most D2C programs, anonymous activity is the difference between “we sent a generic abandon flow” and “we recovered revenue with the exact product, variant, and intent signals the shopper already gave you.”

How It Works

Anonymous activity is basically a temporary identity layer. Your app or site generates an anonymous identifier, sends events against it, and then merges that history into a real person profile once you know who they are (email, customer ID, etc.).

• Before identify: Your SDK tracks events (e.g., Product Viewed, Added to Cart) against an anonymous ID stored on-device/in-browser.
• At identify: When the shopper logs in, creates an account, or enters email at checkout, you call identify with your chosen primary identifier. Customer.io merges the anonymous timeline into the identified person (identity stitching).
• After identify: All future events attach to the known profile, and the pre-login events become available for segmentation and automation triggers.

Where this tends to break in practice: teams track events anonymously but never call identify at the right moment, or they identify with inconsistent IDs (email sometimes, internal ID other times). That creates duplicates and “missing cart” issues inside campaigns.

Step-by-Step Setup

You’re aiming for two things: (1) capture meaningful intent signals before login, and (2) stitch them to the right person the instant you have a stable identifier. Set this up once and it becomes the foundation for cart recovery, browse retargeting, and reactivation targeting.

1. Install the Customer.io SDK (web or mobile) and confirm it initializes on app/site start.
   Do this as early as possible (app launch / first page load) so you don’t miss the first product view.
2. Decide your identity strategy (pick one “source of truth”).
   Use a stable identifier like customer_id (preferred) or email. The key is consistency—don’t switch between identifiers across platforms.
3. Start tracking anonymous events immediately.
   Track high-signal retention events like:
   • Product Viewed (include product_id, variant_id, price, category)
   • Added to Cart (include line items and quantities)
   • Checkout Started (include cart value and items)
4. Call identify the moment you collect a reliable identifier.
   Common D2C moments: account creation, login, email capture step in checkout, post-purchase confirmation. Include core attributes you’ll segment on (e.g., email, phone, first_name, accepts_marketing).
5. Verify the merge (identity stitching) actually happened.
   Check a few test users in Customer.io: you should see anonymous events in their activity feed after identify. If you don’t, you likely identified too late, used a different identifier, or reinitialized the SDK incorrectly.
6. Normalize event names and payloads across web + app.
   If your iOS app sends AddedToCart and your web sends Added to Cart, your segments and campaigns will be brittle. Standardize now or you’ll pay for it forever.

When Should You Use This Feature

Anonymous activity matters whenever meaningful shopping behavior happens before you “know” the customer. For most D2C brands, that’s basically always—especially on mobile where people browse multiple sessions before converting.

• Cart abandonment with email captured late in checkout: A shopper adds a supplement bundle to cart, starts checkout, then drops off. If you only identify post-purchase, you’ll never have the cart event tied to a person—your recovery flow fires blind (or not at all).
• Browse retargeting for product discovery: Someone views three SKUs in your “Sensitive Skin” category but doesn’t add to cart. With anonymous activity stitched on identify, you can trigger a personalized browse follow-up once they subscribe or create an account.
• Reactivate lapsed customers who browse anonymously first: Existing customers often browse logged-out. Anonymous activity lets you capture intent (they’re back, looking at refills) and connect it once they log in or click through an identified email.

Operational Considerations

Anonymous tracking is easy to “turn on” and surprisingly easy to get wrong at scale. The operational win comes from designing your data flow so segmentation and orchestration stay reliable as traffic grows and channels multiply.

• Segmentation depends on payload quality: If Added to Cart doesn’t include product_id and value, you’ll end up with generic recovery messages. Decide the minimum viable schema and enforce it.
• Identity stitching needs a single rule: Pick the canonical identifier and use it everywhere. If you must support both email and customer ID, define when each is used and how you prevent duplicates.
• Cross-device reality: Anonymous IDs are device/browser-specific. If someone browses on mobile Safari and converts in your iOS app, you won’t magically stitch that without an identify event in both contexts. Plan flows that collect email early if cross-device is common.
• Orchestration timing: Don’t trigger high-stakes messages purely off anonymous events unless you’re confident you’ll identify soon. A common pattern is: log anonymous intent immediately, but only start messaging once identify happens (or once you have permission + channel eligibility).
• Deduping purchase and checkout events: If web and app both fire Order Completed, you’ll inflate revenue attribution and break frequency controls. Implement idempotency keys (e.g., order_id) and dedupe downstream.

Implementation Checklist

Before you build campaigns on top of anonymous activity, lock down the fundamentals. These checks prevent the classic “why didn’t the abandon flow fire?” debugging spiral.

• SDK initializes on first app open / first page load
• Anonymous ID persists across sessions (until identify)
• Event taxonomy is standardized across platforms (names + required properties)
• identify fires at the earliest reliable moment (login, email capture, account create)
• Test user shows pre-identify events merged into the identified profile in Customer.io
• Purchase/checkout events include unique IDs (order_id, cart_id) for dedupe
• Consent/marketing preference attributes are captured and respected in orchestration

Expert Implementation Tips

Once the basics work, the next gains come from making anonymous signals more actionable and less noisy for retention automation.

• Capture “cart changed” not just “added to cart”: In practice, carts evolve. Track a Cart Updated event with full line items so your recovery message reflects the latest state, not the first add.
• Send variant-level IDs: For apparel/beauty, product_id isn’t enough. Include variant_id, shade, size. This is what makes recovery emails feel like a concierge instead of a template.
• Use a short “identity grace window”: If you often identify within 10–30 minutes (email capture in checkout), delay abandon triggers slightly so the merge happens before the journey evaluates conditions.
• Track intent tiers: Separate low-intent (Product Viewed) from high-intent (Checkout Started). Your segmentation and suppression logic becomes dramatically cleaner.

Common Mistakes to Avoid

These are the ones that quietly kill recovery and reactivation performance while everything “looks” like it’s tracking.

• Identifying too late: If identify only happens post-purchase, you lose the entire pre-purchase funnel for non-converters.
• Using different identifiers across web and mobile: Email on web, internal ID on app = duplicate profiles and split event histories.
• Event payloads missing the fields you need to personalize: Teams track Added to Cart without items, then wonder why messages are generic.
• Reinitializing the SDK and rotating anonymous IDs: If your anonymous ID changes every session due to misconfiguration, you’ll never build a coherent intent timeline.
• No dedupe on purchases: Double-fired purchase events create bad segments (e.g., “purchased twice”) and break post-purchase suppression.

Summary

If you care about retention revenue, anonymous activity is foundational: it captures pre-login intent and stitches it to the customer once you can identify them.

Implement it with a consistent identity rule, standardized events, and payloads built for personalization—then your cart recovery and repeat purchase automation has real signal to work with.

Implement Anonymous Activity with Propel

If you’re rolling this out across web + mobile, the hardest part isn’t sending events—it’s keeping identity stitching, deduping, and segmentation stable as your program scales. We’ll typically map your event schema, define the identify moments, and QA merge behavior in Customer.io before you build journeys on top.

If you want to sanity-check your tracking plan against your cart recovery and repeat purchase goals, book a strategy call.