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

Overview

If you’re running Customer.io for a D2C brand, anonymous activity is what lets you capture real shopping intent before someone logs in or checks out—and then attach it to the right customer the moment they identify. If you want help pressure-testing your tracking plan (and avoiding the usual identity stitching pitfalls), you can book a strategy call and we’ll map it to your cart recovery and repeat purchase flows.

In practice, this is the difference between “we sent a generic welcome” and “we know they viewed the Espresso Bundle twice, added it to cart, then bounced”—and you can act on that.

How It Works

Anonymous activity is about letting your app (web or mobile) send events to Customer.io before you know who the person is, then stitching those events onto a known profile once they log in, sign up, or you otherwise identify them.

• Step 1: Track events anonymously. Your SDK generates/uses an anonymous identifier on-device (or in-browser). You fire events like Product Viewed, Added to Cart, Checkout Started even when the user is a guest.
• Step 2: Identify when you have a real user ID. The moment they authenticate (login), create an account, or you can reliably assign your internal customer ID, you call identify with that ID.
• Step 3: Merge/stitch the anonymous history to the identified profile. Customer.io associates the anonymous activity with the now-known person, so segmentation and automation can “see” the full journey—pre- and post-login.
• Step 4: Use that stitched data to trigger recovery + retention. Your cart abandonment, browse abandonment, and post-purchase upsell flows can reference the exact products/categories from the anonymous session.

Real D2C scenario: A shopper on iOS browses “Sensitive Skin Moisturizer,” adds it to cart, then bounces. Two days later they install your app again (or return), create an account to get free shipping, and you identify them. With anonymous activity stitched, your “cart recovery” journey can immediately send a push/email featuring the moisturizer they actually added—rather than a generic “come back” message.

Step-by-Step Setup

The goal here is simple: make sure the SDK is installed early, events fire consistently in guest mode, and the identify call happens exactly once you’re confident in the user’s identity. Most retention programs we’ve seen fail here because identification happens too late (after checkout) or too often (creating duplicates).

1. Install the Customer.io SDK on web and/or mobile.
   Initialize it at app start so it can capture pre-login sessions. Don’t wait until after authentication screens load.
2. Decide your identity source of truth.
   Pick the stable identifier you’ll use in Customer.io (typically your internal customer ID; email can work but is riskier if it changes). Document it.
3. Start tracking anonymous commerce intent events.
   At minimum for D2C retention: Product Viewed, Collection Viewed, Added to Cart, Removed from Cart, Checkout Started. Include product identifiers (SKU/variant ID), quantity, price, and category.
4. Call identify immediately after login/signup.
   Trigger it when the user session is authenticated and you have the final customer ID. Keep it consistent across platforms.
5. Confirm merge behavior in Customer.io.
   Validate that events sent before identify appear on the identified person’s activity timeline (not stranded on an anonymous profile).
6. Wire journeys off stitched events.
   Example: trigger “Browse Abandonment” off Product Viewed with no purchase within X hours, but only after the user becomes identifiable (or use anonymous-first messaging channels like in-app where appropriate).
7. QA with real devices and real flows.
   Test: guest browse → add to cart → close app → reopen → signup → confirm the cart events are now attached to the person.

When Should You Use This Feature

Anonymous activity matters anytime meaningful intent happens before you can reliably identify the shopper. If you’re only tracking server-side orders, you’re missing the highest-signal retention inputs: what they wanted but didn’t buy.

• Cart recovery for guest shoppers. Capture add-to-cart and checkout-started events even when they haven’t logged in.
• Browse abandonment with product-level personalization. Trigger messages based on viewed categories/SKUs once the user identifies later (signup, checkout, account creation).
• Product discovery → repeat purchase loops. If someone browses refills/subscriptions pre-login, stitch that intent so post-purchase flows can upsell the right replenishment product.
• Reactivation based on historical intent. When lapsed customers return as guests, you can capture new browsing signals and stitch them after login—powering “back-in-stock” or “still thinking about…” messages.

Operational Considerations

Anonymous tracking is easy to ship and surprisingly easy to break. The operational win comes from being disciplined about event design, identity rules, and how you orchestrate journeys off that data.

• Segmentation depends on event consistency. If Android sends added_to_cart and web sends Added to Cart, your segments will silently undercount. Standardize names and payload keys.
• Identity stitching is only as good as your identify timing. Identify too early (before account creation completes) and you risk attaching events to the wrong person. Identify too late and you lose the window to recover carts with urgency.
• Cross-device reality: anonymous IDs don’t magically connect across devices. If someone browses on mobile web and later buys in-app, you only stitch if there’s a shared identifier at identify time (same customer ID/email) and your integration strategy supports it.
• Data flow latency affects “fast” recovery. If events arrive late, your 30-minute cart recovery message becomes a 4-hour message. Monitor pipeline delays and build buffers into timing.
• Orchestration with other systems. If you also send events to your data warehouse, CDP, or ad platforms, keep a single event schema so you’re not debugging three versions of “cart.”

Implementation Checklist

Before you build automations, lock the tracking foundation. This checklist is the difference between a cart program that prints money and one that “kind of works” but can’t be trusted.

• SDK initializes on app start / site load (not gated behind login)
• Anonymous events fire for guest users (view, cart, checkout)
• Event names and properties are standardized across platforms
• identify fires exactly when the user is truly known (post-auth)
• Anonymous activity appears on the identified profile after identify
• Duplicate profiles are not being created during login/logout cycles
• Key segments (Viewed X, Added to Cart, Started Checkout) match expected counts
• Journey triggers reference the stitched events and correct time windows

Expert Implementation Tips

These are the operator moves that usually matter more than the SDK install itself—because they keep your data clean enough to automate against.

• Track variant IDs, not just product IDs. Cart recovery falls apart when the message shows “T-Shirt” but they wanted “Black / Medium.” Include variant_id, size, color.
• Send a single “Cart Updated” event with a cart payload. Instead of relying on a chain of add/remove events, a periodic cart snapshot (items array, total, currency) makes segmentation and debugging much easier.
• Make identify idempotent. On mobile, app restarts and token refreshes happen. Guard your identify call so you don’t spam identity updates or create unexpected merges.
• Use a short grace period before firing recovery. Especially on mobile, network delays and backgrounding can cause late events. A 20–45 minute delay often outperforms “instant” sends and reduces false positives.
• Instrument logout explicitly. If your app supports logout, decide what should happen to the anonymous identifier after logout. In practice, this tends to break when shared devices are involved.

Common Mistakes to Avoid

Most issues show up as “why are counts off?” or “why did this customer get the wrong product?” These are the usual culprits.

• Identifying with email when emails change. If customers update email, you can fragment histories. Prefer a stable internal customer ID.
• Calling identify before authentication is final. If signup fails or the user switches accounts, you risk stitching anonymous activity to the wrong profile.
• Inconsistent event schemas across web/iOS/Android. Your segments and journeys will miss people, and you’ll blame deliverability instead of tracking.
• Not passing enough product context. “Added to cart” without SKU/variant/category kills personalization and makes recovery generic.
• Assuming anonymous activity solves cross-device by itself. It stitches within the identity you provide—if you don’t identify consistently across devices, you still have gaps.

Summary

If you care about cart recovery and repeat purchase, anonymous activity is the tracking layer that captures intent before login and makes it usable after identify. Get the SDK firing early, standardize your event schema, and be intentional about when you stitch identities. When it’s clean, your automations stop guessing and start converting.

Implement Anonymous Activity with Propel

If you’re rolling this out across web + mobile, the hard part usually isn’t the SDK install—it’s keeping identity stitching stable and event payloads consistent enough to trust for segmentation and orchestration. We routinely sanity-check anonymous-to-known flows inside Customer.io and map them directly to cart recovery, browse abandonment, and post-purchase journeys; if that would help, book a strategy call and we’ll walk through your tracking plan and QA approach.