fix(analytics): identify every user in PostHog by Supabase user id

[felipesalinasr]

Problem

PostHog identifies the device (install_id), not the user, so events can't be joined to Supabase and one human across devices/reinstalls counts as multiple people. Verified against the live DB: signed-in users' PostHog distinct_ids do not match their auth.users.id (e.g. juanframartzz@gmail.com → PostHog 13aa0e33… vs Supabase 73c26eb8…).

Root cause

1. analytics.init() calls posthog.identify(install_id) on every launch → locks distinct_id to the device.
2. The sign-in path called analytics.alias(userId) → posthog.identify(userId), but PostHog silently ignores re-identifying an already-identified person, so the Supabase id never landed anywhere queryable. Only email got $set, which masked the gap.

Fix

Keep install_id as the distinct_id — the website /welcome UTM bridge and the sequential onboarding funnel both depend on it — and attach the Supabase identity as person properties at sign-in. Every authenticated person now carries a reliable, queryable join key to Supabase, with pre-login attribution untouched.

• analytics.ts: replace the misleading alias() with identifyUser(), which sets supabase_user_id + email ($set) and signup_date ($set_once) via posthog.setPersonProperties, and flips auth_status to authenticated.
• App.tsx: call analytics.identifyUser(userId, { email, signupDate }) on sign-in (signup date from session.user.created_at).
• Removed the now-unused alias(), personProps, and related types.

Also: activation definition

is_activated now flips on the user's first chat_message_sent (agreed definition: activation = the user sends a message) instead of chat_message_received (agent reply).

Why person property, not re-identify

Re-pointing the distinct_id to the user id would require dropping the install_id identify in init(), which would strand the website's UTM attribution (the /welcome bridge merges the anonymous website person into install_id). The person-property approach achieves a reliable Supabase join without that risk.

Analysis note: join user-level metrics on supabase_user_id, not distinct_id, so a user on two devices (two install_ids, one supabase_user_id) dedupes correctly.

Scope / follow-ups (not in this PR)

• Enrich the person with signup_country (from the geo-ip work) and profile_complete — needs the profiles row at sign-in.
• Reliable internal/test-user exclusion (is_internal) — needs the team email list.
• Optional: native cross-device person merge (would require a coordinated website + identify change).
• Event dedup/definitions (app_error_shown vs error_shown, session_*, app_active/app_launched/user_returned).

Test plan

• pnpm/bun typecheck + lint pass.
• Local with empty POSTHOG_KEY → no-ops, no throws.
• Staging: fresh install → onboarding → sign in → PostHog person shows supabase_user_id = the Supabase auth.users.id, email, signup_date, auth_status = authenticated; pre-login funnel still connects.
• Sign out → reset() to anonymous.
• Spot-check 10 recent signed-in emails: PostHog supabase_user_id matches Supabase id.

Full context: posthog-identity-unification.md / product-metrics-definitions.md (product specs).

🤖 Generated with Claude Code