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

Overview

Anonymous activity is how you capture real shopping intent before someone logs in—then reliably connect it to the right profile once they identify. In Customer.io programs, this is the difference between “generic abandon browse” and highly specific recovery flows that reference the exact product, category, or cart a shopper touched.

If you want a second set of eyes on your identity stitching (where most teams accidentally lose 20–40% of intent), book a strategy call and we’ll walk through your SDK + event plan like an operator would.

How It Works

Before a shopper logs in, your app/site can still emit events—product views, add-to-cart, checkout started—against an anonymous identifier managed by the SDK. Once the shopper signs up, logs in, or you otherwise know who they are, you “identify” them, and Customer.io can merge that anonymous history onto the known person profile so your segments and campaigns don’t start from zero.

• Anonymous session starts immediately: the SDK generates/uses an anonymous ID so events don’t get dropped just because the user isn’t authenticated yet.
• Track events as usual: send the same commerce events you’d send post-login (e.g., Product Viewed, Added to Cart, Checkout Started) with the properties you’ll need for segmentation and message personalization.
• Identify at the moment of truth: on login/signup (or when you capture email/phone), call identify with your stable customer identifier. That’s the stitching point.
• Merge behavior into the customer profile: Customer.io associates the anonymous activity with the identified person, so campaigns can reference pre-login actions (critical for cart recovery and browse-based retargeting).

In practice, this tends to break when teams track anonymously on web, but identify only in-app (or vice versa). If the same shopper touches multiple devices, you need a consistent identity strategy so you’re not “merging” into three partial profiles.

Step-by-Step Setup

The goal is simple: start tracking immediately, then stitch cleanly when you learn who the shopper is. Treat this like payment instrumentation—small mistakes here quietly ruin your recovery and repeat purchase performance.

1. Install the Customer.io SDK(s) on every surface that matters.
   Implement on iOS/Android (and web if applicable). Don’t assume “web later”—anonymous browse and cart intent often happens on mobile Safari/Chrome before app install.
2. Decide your canonical customer identifier.
   Pick one stable ID (e.g., internal customer_id). Use email/phone as secondary identifiers, not the primary key, unless your system truly guarantees immutability.
3. Start tracking events before login.
   On PDP view, collection view, add-to-cart, initiate checkout—track immediately, even if the user is anonymous. Include properties you’ll need later (SKU, product_id, variant_id, price, quantity, category, cart_id).
4. Call identify immediately after login/signup.
   The moment you have a known user, call identify with the canonical ID and set core attributes (email, phone, first_order_date if known, marketing opt-in flags). This is the handoff point where anonymous activity becomes useful.
5. Verify the merge actually happened.
   In Customer.io, confirm that the identified profile shows the pre-login events in activity history. If you don’t see them, fix it now—don’t “ship and hope.”
6. Gate your campaigns on stitched signals, not just pageviews.
   Once verified, build segments and triggers that rely on those events (e.g., “Added to Cart in last 2 hours AND no Purchase”) so recovery starts even when the cart was built anonymously.

When Should You Use This Feature

Anonymous activity matters any time meaningful intent happens before authentication—which is most D2C funnels. If you’re only tracking post-login, you’re basically optimizing for your most committed customers and ignoring the highest-leverage recovery moments.

• Cart abandonment where the cart is built pre-login: a shopper adds a bundle, hits checkout, then creates an account. Without anonymous activity, your “abandon cart” flow starts too late or misses them entirely.
• Browse abandonment and product discovery: capture category/PDP views before email capture so your first identified message can reference what they actually looked at.
• App install → later signup: many shoppers install, browse for days, then finally create an account. Stitching prevents your lifecycle from treating them like a brand-new, cold user.
• Reactivation based on pre-login intent: if someone browsed high-AOV items before identifying, you can prioritize offers/creative once they become reachable.

Real scenario: A shopper on mobile web adds two items to cart, starts checkout, then decides to create an account to “save their info.” If your SDK tracks Added to Cart anonymously and you identify on signup, your cart recovery can fire with the exact items—even if the cart was created before the email existed in your system.

Operational Considerations

Anonymous activity is easy to “turn on” and surprisingly easy to operationally sabotage. The teams that win treat identity and event semantics as a shared contract between engineering and retention.

• Segmentation depends on event consistency: if product_id is sometimes a SKU and sometimes a database ID, your “viewed but not purchased” segments will be noisy and your recommendations will look random.
• Data flow timing matters: if identify happens minutes after signup (batch job, delayed callback), your recovery triggers can fire while the user is still anonymous—leading to missed sends or duplicate journeys.
• Cross-device stitching is not automatic magic: anonymous IDs are device/browser-scoped. If a shopper browses on laptop then signs up in-app, you only stitch if you have a bridge (login on the same surface, or you capture an identifier on both and reconcile).
• Orchestration realities: in most retention programs, cart recovery, browse recovery, and price-drop flows all want the same events. Define one source-of-truth event schema so you’re not maintaining three competing versions of “Added to Cart.”
• Consent and suppression: make sure you only message once you have permission (email/SMS opt-in). Anonymous activity is for targeting logic; deliverability and compliance still depend on consented identifiers.

Implementation Checklist

If you want this to drive revenue (not just generate more events), validate the full loop: anonymous track → identify → merge → segment → send → attribute.

• SDK installed on all required platforms (iOS/Android/web) and initialized early in app/site load
• Canonical customer identifier defined and used consistently in identify
• Pre-login events implemented for PDP view, add-to-cart, checkout started (minimum)
• Event properties standardized (product_id, variant_id, price, quantity, category, cart_id)
• identify fires immediately on login/signup and sets core attributes
• Verified in Customer.io that anonymous events appear on the identified profile after merge
• Segments built off stitched events (e.g., “Added to Cart AND no Purchase”)
• Campaign frequency rules prevent double-sends when identity changes mid-session

Expert Implementation Tips

Most of the lift comes from doing a few unsexy things extremely well: identity hygiene, event naming discipline, and property completeness.

• Identify earlier than you think: if you capture email on a popup or checkout step before account creation, consider identifying then (or storing the email and immediately identifying once verified). This is often the difference between recovering the cart in 30 minutes vs. missing the window.
• Use a single “commerce event contract” across platforms: your iOS event payload should match Android and web. Otherwise, your segments fragment and you end up building platform-specific journeys.
• Send cart state, not just actions: include cart_id and ideally an items array snapshot on cart-related events. It makes message personalization and troubleshooting dramatically easier.
• Plan for identity changes: shoppers log out, switch accounts, or use “Sign in with Apple.” Decide what happens to the device/user mapping and test it intentionally.
• QA with real devices and real flows: simulator-only testing misses cookie/storage edge cases, especially on mobile web and in-app browsers.

Common Mistakes to Avoid

Anonymous activity fails quietly. You’ll still see events in logs, but revenue impact won’t move because the stitching and orchestration are broken.

• Tracking anonymously but never calling identify: this is the #1 issue—great intent data that never becomes addressable.
• Identifying with an unstable ID: using email as the primary ID when emails change creates duplicates and “lost history,” especially for SMS-first brands.
• Firing identify too late: if identify happens after you trigger cart recovery, the user enters the wrong journey state or gets excluded from the segment.
• Inconsistent event names/properties: add_to_cart vs Added to Cart across platforms leads to partial segments and confusing reporting.
• Assuming cross-device merge will happen: anonymous activity is per device/session unless you explicitly connect identities through login or another deterministic link.
• No guardrails for duplicates: when anonymous merges into known, some teams accidentally re-trigger “welcome” or “browse abandon” twice unless they add frequency/exit rules.

Summary

If you care about cart recovery, browse recovery, and accelerating second purchase, anonymous activity is table stakes—because most intent happens before authentication.

Implement it like an identity system: track early, identify immediately, and verify the merge so your campaigns operate on complete shopper context.

Implement Anonymous Activity with Propel

If you’re already running Customer.io, anonymous activity is one of the highest-leverage “plumbing” upgrades you can make—especially when cart and browse behavior happens pre-login across web + app.

When you’re ready, book a strategy call and we’ll map your SDK identify points, event schema, and stitching rules to the retention outcomes you actually care about (recovery rate, repeat purchase, and clean audience building).