Anonymous to Known

PostHog

Capture a PostHog anonymous distinct_idbefore Auth0 login, then merge the pre-auth browsing journey into the authenticated user profile after callback — retroactive analytics attribution, no API access involved. See also: Auth0 Anonymous Sessions, which solves the other half of this problem — authenticated API access before login.

Architecture & Token Flow

PostHog anonymous-to-known identity stitch flow diagram

More detail and implementation tips here.

1. Browse anonymously

→2. Auth0 login / signup

→3. Identity resolved

Demo Storefront

Click products to fire view_item events, add to cart for add_to_cart

👕

Classic T-Shirt

$29.99

🧥

Demo Hoodie

$59.99

☕

Dev Mug

$14.99

Ready to create an account?

Your anonymous session will be linked to your new Auth0 account.

distinct_id (anonymous)

initialising…

Event stream

No events yet — interact with the storefront above

Use a new @atko.email address on the Auth0 signup screen to create a fresh account.

Security Implications

Strengths

No authentication surface exposed at all — this is purely an analytics-layer identity stitch, so there's nothing here to authenticate or authorise.
The merge only ever runs after a real Auth0 callback completes, using a server-verified sub.

Risks & Considerations

A client-supplied distinct_id could misattribute someone else's anonymous browsing to your account if identify() ever trusted an unauthenticated value — this is why it's carried across the Auth0 redirect via localStorage rather than a URL parameter, which would make it directly attacker-settable (e.g. by sending a victim a crafted login link).
PostHog's own persisted identity (its localStorage/cookie) is a client-controlled value by design — treat it as such, never as an identity proof.

Hardening Checklist

Only ever call posthog.identify() with a sub that came from a verified Auth0 session — never from a client-supplied parameter.
Don't use the PostHog merge as an authorisation signal anywhere; it's attribution only.