Anonymous Activity (SDK) — Capture Pre-Login Behavior and Stitch It After Login

Overview

If you’re using Customer.io with an app (or a web experience that behaves like an app), anonymous activity is how you keep the behavioral trail intact before someone logs in or identifies. If you want help pressure-testing your identity stitching and event taxonomy before it becomes a reporting mess, book a strategy call—this is one of those setups that’s easy to “get working” and hard to get right.

In retention programs, anonymous activity is the difference between “we saw a cart event” and “we can actually recover that cart after login, across devices, without double-counting.”

How It Works

Anonymous activity is Customer.io storing events against an anonymous profile/device until you can confidently tie that behavior to a known person. In practice, you’re relying on the SDK’s device identity (and/or an SDK-managed anonymous identifier) to log events before a user logs in, then merging that history into the identified profile when you call identify.

• Before login: the SDK tracks events (e.g., Viewed Product, Added to Cart, Started Checkout) against an anonymous profile.
• At login / account creation: you call identify(userId) (and typically set key attributes like email/phone if you have them). Customer.io then stitches the anonymous activity into the identified person.
• After identify: all new events land on the known profile, and your campaigns/segments can use the full timeline—including pre-login intent.

Where this matters operationally: cart recovery and product-intent flows often happen after login (or require an email/phone), but the intent signals often happen before login. Anonymous activity is how you avoid losing that intent.

Step-by-Step Setup

The goal is simple: track the right events while the user is anonymous, then stitch them cleanly the moment you have a stable identity. Most issues come from calling identify too late, using unstable IDs, or firing duplicate events on app resume.

1. Install and initialize the Customer.io SDK early in app launch.
   Do this before you render your storefront screens so pre-login browsing is captured consistently.
2. Decide what “identity” means in your app.
   Use a stable internal customer_id (or equivalent) for identify. Avoid emails as the primary ID if they can change or if you support Apple Private Relay-style addresses.
3. Track pre-login events with a retention-first taxonomy.
   At minimum for D2C retention: Viewed Product, Added to Cart, Removed from Cart, Started Checkout, Viewed Collection, Searched. Include properties you’ll segment on (SKU, category, price, quantity).
4. Call identify immediately after login or account creation succeeds.
   Don’t wait for a later screen. The earlier you stitch, the fewer edge cases you create (especially if you send an in-app offer right after login).
5. Attach key attributes at identify time.
   Set attributes you’ll use for orchestration: email, phone, country, marketing_opt_in, push_enabled, sms_consent, first_seen_app_version.
6. Verify the merge behavior in Customer.io.
   Pick a test device, browse anonymously, add to cart, then log in. Confirm the identified profile shows the pre-login events in the activity feed and that segments pick them up.
7. Implement logout handling intentionally.
   On logout, reset the SDK identity (per SDK guidance) so the next user on a shared device doesn’t inherit the previous user’s activity.

When Should You Use This Feature

Anonymous activity is worth the effort anytime meaningful intent happens before you have an email/phone, which is basically every high-performing D2C app and most mobile-first storefronts. The retention lift usually shows up in better cart recovery attribution and more relevant post-login messaging.

• Cart abandonment that starts pre-login.
  Scenario: a shopper adds a supplement bundle to cart while browsing as a guest, then logs in to check shipping. If you stitch correctly, your cart recovery flow can reference the exact items they added—even if the “abandon” message sends later via email/SMS.
• Product discovery → post-login conversion.
  If someone views 5 products in a category and then creates an account, you can route them into a category-specific offer or education series without guessing.
• Reactivation based on pre-login intent.
  If lapsed users reinstall and browse anonymously before logging back in, stitching prevents you from treating them like a brand-new prospect.
• Cross-device reality.
  People browse on mobile, buy on desktop, and log in at different times. Anonymous activity helps preserve the mobile intent so your lifecycle doesn’t go blind right before conversion.

Operational Considerations

Anonymous activity is less about “tracking more” and more about keeping your segmentation and orchestration clean once you start running real volume through campaigns. The biggest operational wins come from consistent IDs, predictable event properties, and clear rules for when a user is considered “known.”

• Segmentation depends on event consistency.
  If Added to Cart sometimes includes sku and sometimes includes product_id, your cart recovery segments will quietly undercount. Standardize properties and types.
• Data flow timing matters.
  Mobile apps often queue events offline and flush later. If the user logs in while offline, you can end up with pre-login events arriving after identify (or vice versa). Test offline/poor network paths so your “abandoned cart within X hours” logic doesn’t misfire.
• Identity stitching can create duplicates if you’re sloppy.
  Calling identify with different IDs for the same person (e.g., email one day, internal ID the next) is how you end up with split profiles and broken suppression logic.
• Orchestration: decide what qualifies as abandonment.
  In most retention programs, the cleanest approach is: cart abandonment = Added to Cart with no Order Completed within a time window, and optionally no Started Checkout if you want a softer nudge path.
• Respect consent and channel readiness.
  Anonymous activity is behavioral data; sending requires identity + consent. Make sure your orchestration checks marketing_opt_in / sms_consent / push permission before firing messages.

Implementation Checklist

If you want anonymous activity to drive revenue (not just create more data), treat this like a mini data product: clear identity rules, stable events, and a repeatable QA plan.

• SDK initializes on app start (before storefront screens render).
• Stable primary identifier chosen for identify (not an unstable or user-editable value).
• Pre-login events implemented: view, add/remove cart, checkout start, purchase.
• Event properties standardized (SKU/product_id, category, price, quantity, currency).
• identify called immediately on login/account creation success.
• Key attributes set at identify (email/phone/consent flags/device permissions).
• Logout resets identity to prevent shared-device contamination.
• QA: anonymous browse → add to cart → login → verify merged timeline in Customer.io.
• QA: offline mode and delayed flush tested.

Expert Implementation Tips

The teams that get the most out of anonymous activity treat it as the backbone of cart recovery and post-login personalization—not a nice-to-have analytics layer.

• Track “cart state” as an event payload, not just single adds.
  Single-item add events are noisy. For recovery flows, it’s often better to send a Cart Updated event with the full cart contents so your message can render the right items and totals even after multiple edits.
• Fire identify once, then update attributes separately.
  Repeated identify calls with inconsistent IDs is a common source of profile fragmentation. Identify with the stable ID, then update attributes as they become available.
• Use a “known_user” flag in your own logic.
  Don’t guess based on UI state. Set a boolean once you have a confirmed account session, and gate certain events (like Order Completed) to avoid duplicate purchase events from receipt screens.
• Build segments that explicitly include anonymous-then-identified paths.
  For example: “Added to Cart in last 4 hours” should work regardless of whether the add happened pre- or post-login—as long as stitching is correct. Validate with real device tests, not just event logs.

Common Mistakes to Avoid

Most anonymous activity failures look fine in a demo and break under real user behavior: app backgrounding, flaky networks, guest checkout, and identity changes.

• Calling identify too late.
  If you wait until a “profile” screen, you’ll lose the moment where pre-login intent should drive the first post-login message.
• Using email as the primary identifier.
  Emails change, get aliased, and can be missing at login (phone-based auth). Use a stable internal ID and store email as an attribute.
• Not resetting identity on logout.
  Shared devices (or even just QA devices) will pollute profiles and ruin suppression logic for cart recovery.
• Duplicate event firing on app resume.
  If Viewed Product fires every time the app returns to foreground, you’ll inflate intent signals and over-trigger browse abandon flows.
• Assuming merge worked without checking the Customer.io profile timeline.
  Always confirm anonymous events appear on the identified profile after login. If they don’t, your campaigns will quietly underperform.

Summary

If your shoppers browse and build intent before login, anonymous activity is how you keep that intent usable for cart recovery and repeat purchase flows. Implement it with stable IDs, consistent event properties, and a real QA path that includes offline and logout edge cases.

Implement Anonymous Activity with Propel

If you’re already running Customer.io, anonymous activity is one of those foundations that pays back every time you try to improve cart recovery or post-login personalization. When teams want a second set of eyes on identity stitching, event design, and the “does this segment actually catch the right people?” layer, the fastest path is to book a strategy call and walk through your current SDK instrumentation and campaign triggers.