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

Overview

If you’re running Customer.io for retention, anonymous activity is how you stop losing the most valuable intent signals: the stuff shoppers do before they log in, start checkout, or give you an email. When it’s wired correctly, you capture product views, category browsing, add-to-cart, and checkout steps as an anonymous profile, then stitch it to the real customer profile the moment they identify.

If you want a second set of eyes on your identity stitching and event taxonomy (where most retention programs quietly leak money), book a strategy call and we’ll pressure-test it like an operator would.

How It Works

In practice, anonymous activity is just “events without a known person ID yet.” Your app (mobile or web) initializes the Customer.io SDK, starts tracking events against an anonymous identifier, and later calls identify when you finally know who the user is (login, account creation, email capture, etc.). Customer.io can then merge the anonymous history onto the identified person so your campaigns and segments can use the full journey.

• Before login: SDK tracks events (e.g., Product Viewed, Added to Cart) tied to an anonymous profile.
• At identity moment: SDK sends an identify call with your stable customer identifier (email and/or customer ID depending on your identity strategy).
• After identity: New events attach to the known profile, and the earlier anonymous events can be stitched so automations can trigger based on the complete behavior.
• Why retention cares: This is the difference between “we sent a generic welcome” and “we sent a cart recovery that includes the exact SKU they added 12 minutes ago—before they logged in.”

Step-by-Step Setup

The goal here is simple: make sure your SDK is consistently tracking anonymous events, and that you only call identify when you have a stable identifier you’ll reuse forever. Most breakage comes from calling identify too early (bad IDs) or too often (identity churn).

1. Install the Customer.io SDK (mobile/web) and verify basic connectivity.
   Confirm events are arriving in Customer.io from a dev build or staging environment before you touch identity logic.
2. Initialize the SDK on app start.
   Do this as early as possible in the app lifecycle so you don’t miss the first session’s product discovery events.
3. Start tracking key commerce events even when the user is anonymous.
   At minimum for D2C retention: Product Viewed, Collection Viewed, Added to Cart, Checkout Started, and Order Completed (the last one will usually be identified by then, but keep it consistent).
4. Pass clean, consistent properties on each event.
   Include stable identifiers like product_id, variant_id, price, currency, quantity, and cart_id. This is what makes segmentation and dynamic content reliable.
5. Call identify exactly when the user becomes known.
   Common identity moments: account creation, login, or email capture (e.g., “send me my cart” form). Use the same identifier strategy everywhere (don’t mix random emails, temp IDs, and phone numbers unless you’ve designed for it).
6. Confirm the anonymous history stitched onto the known profile.
   Pick a test device, browse anonymously, add to cart, then log in. In Customer.io, validate the identified profile shows the earlier events in the activity feed.
7. Only then: build triggers/segments that rely on pre-login intent.
   If you build automations first, you’ll end up debugging “missing carts” that are actually identity issues.

When Should You Use This Feature

You use anonymous activity when you care about intent that happens before you can message someone. For most D2C brands, that’s basically all high-intent shopping behavior on mobile apps and a big chunk of web sessions.

• Cart recovery that starts pre-login: Shopper adds a product to cart in your app, then bounces. Later they create an account—your flow can still reference that cart and send a tailored recovery sequence.
• Product discovery → repeat purchase: Existing customer opens the app while logged out, browses a new category, then logs in. You can retarget with browse-based recommendations instead of generic “new arrivals.”
• Reactivation with real signals: A lapsed buyer returns anonymously, views 3 SKUs, but doesn’t purchase. Once they identify, you can trigger a “back in stock / still thinking about…” path based on what they actually looked at.
• Reducing wasted sends: If you can stitch anonymous browsing, you can suppress broad promos for people already deep in checkout and instead push the right nudge.

Operational Considerations

Anonymous activity is easy to “turn on” and surprisingly easy to get wrong at scale. The operational work is making sure your identity graph and event stream stay clean enough that segments don’t rot over time.

• Segmentation depends on event hygiene: If product_id is sometimes a SKU and sometimes a Shopify variant ID, your browse/cart segments will fracture and personalization will misfire.
• Identity stitching is a one-way door operationally: In most retention programs, we’ve seen the biggest issues come from multiple identifiers per human (email changes, multiple logins, “guest checkout” IDs). Decide what your primary key is and stick to it.
• Data flow timing matters: If identify happens after you fire Checkout Started, your “checkout abandon” trigger may attach to anonymous and never hit your identified-based campaign. Make identity happen at the earliest reliable moment.
• Orchestration reality: Your cart recovery might be in Customer.io, but your cart state might live in Shopify or your backend. Make sure the event properties you send are enough to render the message without needing a fragile real-time lookup.
• Cross-device expectations: Anonymous activity is device-scoped until you identify. Don’t expect “anonymous browse on mobile” to stitch to “anonymous browse on desktop” unless you have a deterministic identifier and you call identify on both.

Implementation Checklist

If you want this to drive revenue (not just create more data), treat it like a tracking project with acceptance criteria. Here’s the checklist we use to validate it’s production-ready.

• SDK installed and sending events from all platforms you support (iOS/Android/web)
• Anonymous events fire before login for: Product Viewed, Added to Cart, Checkout Started
• Event properties standardized: product_id, variant_id, price, currency, quantity, cart_id
• identify fires exactly at login/signup/email capture (no temp IDs)
• Anonymous history successfully appears on the identified profile in Customer.io
• Core segments built and validated (e.g., “Added to Cart in last 4 hours, no Order Completed”)
• Cart/browse-triggered campaigns tested end-to-end with a real device
• Monitoring in place for sudden drops in event volume or identify rate

Expert Implementation Tips

The difference between “working” and “printing money” is usually a handful of operator decisions around identity timing and event design.

• Identify earlier than you think—once it’s reliable. If you capture email for “save my cart,” that’s often your best identity moment for recovery flows. Waiting for full account creation can cost you the recovery window.
• Use a single commerce taxonomy across app and backend. If your backend sends Order Completed but the app sends Purchase, your post-purchase suppression and repeat purchase timing will drift.
• Include a cart snapshot on the event. For example, send an array of line items on Added to Cart or Checkout Started. It makes message rendering and recommendations dramatically more reliable.
• Design for “logged out but known.” Returning customers often have an app installed but aren’t authenticated. If you can safely re-identify from a secure stored token, you’ll stitch more sessions and improve targeting.

Common Mistakes to Avoid

Most teams don’t fail because they missed a step—they fail because identity and events drift over time and nobody notices until performance drops.

• Calling identify with unstable IDs: Using a temporary guest ID, then later switching to email/customer ID creates duplicates and breaks stitching.
• Firing events before SDK initialization: You lose the first-session events—often the highest intent session for new users.
• Inconsistent naming and property types: price as a string sometimes and a number other times will quietly break segmentation and reporting.
• Building campaigns that assume stitching always happens: Always include guardrails (e.g., fallback content) in case product properties are missing or the user never identifies.
• Not validating with real journeys: A QA script that only tests “login then browse” won’t catch the real money path: “browse anonymously → add to cart → bounce → identify later.”

Summary

If you want cart recovery and reactivation to feel personal, you need pre-login intent. Anonymous activity captures it; proper identify calls stitch it; clean event properties make it usable in campaigns.

Implement it when you care about behavior before authentication—which, for most D2C apps, is where the revenue signals live.

Implement Anonymous Activity with Propel

If your team is already on Customer.io, anonymous activity is one of those setups that looks straightforward but tends to break in the seams—identity timing, duplicate profiles, and event payloads that aren’t campaign-ready. In most retention programs, we’ve seen a quick tracking audit and a tight event spec outperform weeks of “we’ll clean it up later.”

If you want to sanity-check your SDK tracking plan and stitching approach before you build automations on top of it, book a strategy call.