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

Overview

If you’re using Customer.io with a mobile or web SDK, anonymous activity is how you capture the behaviors that happen before a shopper logs in or gives you an email—then reliably attach that history to the right customer profile later. If you want a second set of eyes on your identity stitching (this is where most retention programs quietly leak revenue), book a strategy call and we’ll pressure-test your tracking plan.

In D2C, this matters because the highest-intent actions often happen while someone is still anonymous: browsing a category, viewing a PDP, starting checkout, or even building a cart in-app. If that data never gets stitched, your cart recovery and browse abandonment programs end up under-triggering, misfiring, or attributing to the wrong person.

How It Works

At the SDK layer, Customer.io treats a device/session as an anonymous user until you explicitly identify them. During that anonymous window, you can still send events (and in many setups, set attributes) tied to an anonymous identifier managed by the SDK.

• Anonymous event capture: Your app fires events like Product Viewed, Added to Cart, or Checkout Started before the shopper authenticates. These events are stored against an anonymous profile.
• Identify call = stitching moment: When the shopper logs in, creates an account, or submits email/phone, your app calls identify with your stable customer ID (or another canonical identifier). Customer.io then merges the anonymous activity into the known person profile.
• Post-merge continuity: After identify, new events should flow to the known profile. Your campaigns can now reference both pre-login and post-login behavior to trigger recovery and repeat purchase journeys accurately.

In practice, this tends to break when teams fire identify too early (before they actually have a stable ID), too late (after key events already happened in a different session), or inconsistently across platforms (web vs iOS vs Android). The goal is one clean identity graph: anonymous → known, once, predictably.

Step-by-Step Setup

Before you build campaigns, get the SDK tracking right. If the app-side identity flow is messy, you’ll spend months “optimizing” messaging that’s actually triggered off incomplete data.

1. Install the Customer.io SDK on each app surface you care about (iOS/Android/Web).
   Make sure you’re using the same workspace and correct site/workspace identifiers across environments. Keep dev/stage/prod separated so QA doesn’t pollute production segments.
2. Decide what your canonical customer identifier is.
   Pick something stable and unique (e.g., your internal customer_id). Avoid identifiers that can change or collide (like email alone) if your system supports account merges or email edits.
3. Start tracking anonymous events immediately on app open/session start.
   Instrument high-intent retention events first: Product Viewed, Collection Viewed, Added to Cart, Checkout Started, Order Completed. Include useful properties like sku, product_id, category, price, currency, quantity, and cart_value.
4. Call identify exactly when you truly know who the person is.
   Typical moments: successful login, account creation completion, or verified email/phone capture. Pass your canonical ID and set core attributes (email, phone, first_name, acquisition_source if you have it).
5. Confirm the anonymous-to-known merge in Customer.io.
   Use Activity Logs to validate that pre-login events appear on the known profile after identify. If you see duplicate profiles or missing history, fix the identity flow before shipping campaigns.
6. Standardize event naming and payloads across platforms.
   Your iOS event should match your Android and web event—same name, same key properties—so segmentation doesn’t fragment and orchestration stays sane.

When Should You Use This Feature

Anonymous activity is worth the effort when meaningful intent happens before authentication—which is most D2C apps and a lot of mobile web. You’re basically buying back signal that would otherwise disappear.

• Cart recovery when checkout starts before login: If users can build a cart or start checkout as guests, anonymous events let you trigger recovery the moment they become known (or as soon as you capture email/phone).
• Browse abandonment for product discovery: Track anonymous Product Viewed and Collection Viewed so you can later personalize “Still thinking about…” messaging after signup.
• Reactivation based on pre-login affinity: If someone browsed “vitamin D” or “running socks” before creating an account, you can use that affinity later to tailor winback offers and content.
• Repeat purchase setup: Even for returning customers, anonymous activity matters when the app logs them out, they reinstall, or they bounce between web and app—stitching prevents your repeat purchase program from losing context.

Real D2C scenario: A shopper downloads your skincare app, views three moisturizers, adds one to cart, then quits at shipping. Two days later they create an account to get a first-order offer. If you stitched anonymous activity correctly, your first message can reference the exact moisturizer and cart value—rather than sending a generic welcome that ignores the highest-intent behavior you already saw.

Operational Considerations

Once tracking is live, the operator work is making sure segments and journeys behave consistently as identities resolve. Most issues show up as “why didn’t this person enter the flow?” and the answer is almost always data flow timing.

• Segmentation timing: If your segment depends on Added to Cart but the identify happens hours later, decide whether you’ll enroll people on identify (e.g., “has anonymous cart activity in last 24h”) or on the event itself (only works if they’re already known).
• Event/property governance: Lock your event taxonomy early. If half the team tracks add_to_cart and the other half tracks Added to Cart, you’ll ship duplicate campaigns or miss audiences.
• Cross-device reality: Anonymous activity is device-scoped. If someone browses on mobile web and later logs in on iOS, you won’t magically stitch that without a shared identifier capture (email/phone) and consistent identify calls across surfaces.
• Orchestration after merge: When anonymous activity merges into a known profile, you can accidentally trigger multiple flows at once (welcome + cart + browse). Use priorities, exit conditions, and frequency controls so the customer gets one coherent message sequence.
• Data latency and retries: Mobile SDKs deal with offline mode and retries. Plan for events arriving late and build segments with reasonable windows (e.g., 1–3 days) rather than minute-level precision.

Implementation Checklist

If you want anonymous activity to actually lift revenue, treat this like instrumentation, not “marketing setup.” The checklist below is what we run through before we trust the data enough to automate recovery and repeat purchase.

• SDK installed and initialized correctly on iOS/Android/web (prod environment validated)
• Canonical customer_id chosen and used consistently in identify
• Identify moment defined (login/signup/verified capture) and implemented once per user lifecycle
• Key retention events tracked anonymously with consistent names and properties
• Post-identify events confirmed to land on the known profile (no split histories)
• Segments built to account for merge timing (e.g., “did X in last 24h” after identify)
• Journey controls set (dedupe, frequency caps, exit on purchase) to prevent message pileups

Expert Implementation Tips

The difference between “we track anonymous activity” and “it drives retention” is usually a handful of operator decisions around identity and payloads.

• Track the cart as a state, not just an event. Fire Added to Cart, but also keep an updated cart snapshot property (items count, cart value, top SKU) so messages can render even if the cart changed slightly.
• Use a single source of truth for product identifiers. Pick sku or product_id and stick to it across events so you can join behavior to catalog data cleanly.
• Identify only when you’re confident. If you identify on “email entered” but the user mistypes, you’ll stitch high-intent behavior to a dead profile and lose the real person later.
• Design your flows around merge moments. In many apps, the best cart recovery trigger is not the cart event—it’s the identify event with a condition that they have cart activity in the last X hours.
• QA with real devices and bad networks. Simulator-only QA misses offline queues and retry behavior, which is where event ordering issues come from.

Common Mistakes to Avoid

Most teams don’t fail because they didn’t instrument events—they fail because identity stitching is inconsistent and campaigns are built on assumptions the data can’t support.

• Firing identify with an unstable identifier: Using email before verification, or using a temporary guest ID that later changes, leads to fragmented profiles.
• Tracking events with inconsistent naming across platforms: Your segmentation becomes platform-specific and you silently under-message large chunks of users.
• Assuming cross-device stitching “just happens”: Anonymous activity doesn’t follow a person across devices unless you give Customer.io a way to connect them.
• Triggering too many journeys at once post-merge: Welcome + browse + cart all fire after identify and the customer gets spammed. Prioritize and suppress aggressively.
• Not validating merges in Activity Logs: If you don’t confirm that anonymous events land on the known profile, you’re building retention automation on vibes.

Summary

Anonymous activity is how you keep pre-login intent from disappearing, then stitch it onto the right customer profile once they identify. If cart and browse signals happen before login in your app, this is foundational for accurate recovery and better repeat purchase personalization.

Implement Anonymous Activity with Propel

If you’re already running Customer.io, the fastest path is usually: validate identity stitching first, then build the recovery/reactivation orchestration that depends on it. If you want us to review your SDK identify moments, event taxonomy, and merge-driven journey triggers, book a strategy call and we’ll map the fixes that typically unlock the biggest retention lift.