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

Overview

If you’re using Customer.io for retention, anonymous activity is what keeps you from losing the highest-intent behavior the moment someone isn’t logged in yet. It’s the difference between “we know they browsed and added to cart” and “we only know they exist after signup.” If you want a second set of eyes on your tracking plan before you scale spend or rebuild flows, book a strategy call and we’ll pressure-test identity stitching and event design.

In most D2C programs, anonymous activity shows up in two places that matter: cart recovery (especially on mobile web where logins are rare) and product discovery retargeting (browse, view item, quiz results) before you have an email or user ID.

How It Works

Anonymous activity in Customer.io is basically “events and attributes tied to an anonymous profile ID” until you can confidently connect that activity to a real person. The SDK generates/holds an anonymous identifier on the device/app session, you track events against it, and then you merge that history into the identified profile when the customer logs in, signs up, or submits email/SMS.

• Anonymous profile ID exists first. The SDK maintains an anonymous identifier (device/app-scoped) so events like Product Viewed and Added to Cart aren’t dropped just because the user hasn’t authenticated.
• You track events normally. Your app/web layer sends events with properties (SKU, variant, price, category, cart value, etc.) while the person is still anonymous.
• Identify call stitches the timeline. When the user becomes known (login, account creation, email capture), you call identify with your canonical customer ID (and usually email/phone). Customer.io then merges the anonymous activity into the identified person based on the SDK’s anonymous identifier.
• Merging is where retention wins or breaks. In practice, this tends to break when teams fire identify too early (temporary IDs), too late (after key events), or inconsistently across web vs app—leading to split profiles and “missing cart” automations.

Real D2C scenario: A shopper lands on your mobile site from TikTok, views two products, adds a bundle to cart, then bounces. The next day they open the app and create an account. If you captured anonymous activity correctly and stitched it on signup, you can trigger a cart/browse recovery push or email with the exact items they touched—without relying on cookies or hoping they logged in on session one.

Step-by-Step Setup

The goal here is simple: start tracking immediately (anonymous), then stitch cleanly when you earn an identifier. Don’t overcomplicate it—just be strict about when you call identify and what IDs you consider “real.”

1. Install the Customer.io SDK for your platform.
   Use the official Mobile SDK for iOS/Android/React Native/Flutter (or your web implementation if you’re doing anonymous web activity). Validate that the SDK initializes on app launch/page load and persists the anonymous identifier across sessions.
2. Decide your canonical identity key.
   Pick the one ID that will never change (e.g., your internal customer_id). Use that as the primary identifier in Customer.io. Email and phone should be attributes—not the primary key—unless your system truly treats them as immutable identifiers.
3. Start tracking anonymous events immediately.
   Implement event tracking for your highest-value pre-login actions:
   • Product Viewed (sku, variant_id, category, price)
   • Collection Viewed (collection_id, name)
   • Added to Cart (sku(s), qty, cart_value)
   • Checkout Started (cart_value, item_count, shipping_country)
   • Email Captured (source: popup/quiz/checkout)
4. Call identify at the right moment.
   Only call identify when you have a stable, server-backed customer identity (account created or authenticated session). Pass:
   • id: your canonical customer_id
   • email and/or phone if collected
   • any baseline attributes you segment on (e.g., acquisition_source, first_seen_at)
5. Merge/confirm anonymous activity is stitched.
   In Customer.io, verify that:
   • the identified profile shows the pre-login events in the activity feed
   • segments built on those events include the person post-identify
   • journeys triggered by those events can still fire after identify (depending on your orchestration)
6. Wire events into retention automations.
   Use the stitched events to drive cart recovery, browse recovery, and post-purchase upsell flows without needing the user to have been logged in during the original session.

When Should You Use This Feature

If your funnel has meaningful intent before login (most D2C does), anonymous activity is table stakes. The best time to implement it is before you build “smart” recovery flows—otherwise you’re optimizing creative on incomplete data.

• Cart recovery when most shoppers aren’t logged in. Especially common on mobile web and for first-time buyers. Anonymous tracking captures cart builds that would otherwise be invisible.
• Browse recovery and product discovery retargeting. If you want “viewed X, didn’t buy” messaging, you need pre-identify product views and collection views.
• Quiz-to-purchase flows. If someone completes a skincare quiz anonymously and later creates an account, you want those results on the profile for segmentation and upsells.
• Reactivation based on pre-login intent. When lapsed customers return anonymously (no login yet), you can still capture what they’re interested in and personalize the winback once they identify.

Operational Considerations

Anonymous activity is only valuable if it’s consistent enough to segment and orchestrate off of. The operational work is making sure identity, naming, and event payloads don’t drift across app versions and platforms.

• Segmentation: design for “pre-identity” and “post-identity.”
  Build segments that tolerate the stitching delay. For example, a cart recovery segment should be based on Added to Cart AND “no Order Completed within X hours,” not “is logged in.”
• Data flow: watch for profile splitting.
  If web and app both generate anonymous profiles and you only identify in one place, you’ll end up with multiple partial timelines. Decide where identification happens and make it consistent.
• Orchestration reality: triggers vs joins.
  If your journey triggers on an anonymous event, but the message requires email/phone, you need a join strategy—e.g., hold until email exists, or trigger on identify and look back at recent events.
• Event payload hygiene matters more than volume.
  A single clean Added to Cart event with structured items beats five noisy events you can’t reliably template into messages.

Implementation Checklist

Before you declare this “done,” run through the checks that prevent silent data loss and broken stitching—these are the ones that usually bite teams a month later when they scale campaigns.

• SDK initializes on every app launch/page load and persists an anonymous identifier across sessions
• Canonical customer_id chosen and used consistently in identify
• identify fires only after authentication/account creation (not on app open)
• Core pre-login events implemented: Product Viewed, Added to Cart, Checkout Started (with consistent naming)
• Event properties standardized (sku/variant_id, price, quantity, cart_value, currency)
• Post-identify profile shows pre-login events in Customer.io activity feed
• Segments based on pre-login events evaluate correctly after identify
• Journeys handle “event happened before email existed” (hold/lookback strategy)

Expert Implementation Tips

The teams that get real lift from anonymous activity treat it like identity infrastructure, not a tracking nice-to-have. A few operator moves tend to make the difference.

• Use a “lookback window” pattern for recovery.
  Instead of triggering immediately on Added to Cart (anonymous) and then failing to send, trigger on identify and check: “did they add to cart in the last 4 hours and not purchase?” This captures both anonymous and known behavior cleanly.
• Normalize item arrays early.
  If you want dynamic cart lines in email/push, standardize an items array payload (sku, name, qty, price, image_url, product_url). Retrofitting this after campaigns exist is painful.
• Version your event schema.
  When apps update, payloads drift. Add a property like schema_version so you can segment/debug without breaking templates.
• Be strict about “temporary IDs.”
  Guest checkout IDs, device IDs, or session IDs often change. If you identify with them, you’ll create duplicate people and lose stitching. Wait for a real customer ID.

Common Mistakes to Avoid

Most failures here aren’t technical—they’re operational. The SDK is doing its job, but the identity rules are sloppy or inconsistent across surfaces.

• Calling identify on app open with a placeholder ID. This creates permanent split profiles when the real account is created later.
• Tracking “Added to Cart” without the cart contents. You’ll trigger recovery, but you can’t personalize it—conversion suffers and you end up blasting generic reminders.
• Different event names on web vs app. If web sends add_to_cart and app sends Added to Cart, your segments and journeys won’t behave consistently.
• No plan for anonymous-to-known timing. Journeys that require email/phone should either wait until the attribute exists or trigger off identify with a lookback. Otherwise, you’ll see “entered journey” counts with low send volume.
• Ignoring duplicate resolution. If you already have duplicates, stitching can get messy. Clean identity before you scale recovery flows.

Summary

Anonymous activity is how you keep high-intent behavior from disappearing before login. Track pre-auth events, identify at the right moment, and design journeys that account for the stitching delay. If cart and browse recovery are underperforming, this is often the missing layer.

Implement Anonymous Activity with Propel

If you’re rolling this out across app + mobile web, the hard part is rarely the SDK install—it’s getting identity stitching, event schema, and journey triggers aligned so you can actually monetize the data. We typically review your Customer.io workspace alongside your SDK instrumentation plan, then map it into recovery/reactivation orchestration that won’t break when traffic scales. If you want that kind of operator-level review, book a strategy call.