Product Analytics
Product Analytics
Product Analytics is the core Mixpanel domain. The exam tests whether you can design and interpret an event-based model: events, properties, user profiles, cohorts, groups, and the reports built on them (Insights, Funnels, Retention, Flows, Impact).
Core rules
- An event is a named action at a time, tied to a
distinct_id; properties describe that event. Keep names stable and descriptive, such asCheckout Completed. - User profiles are separate from events. Write durable profile properties with
$setand$set_once; do not bury user traits only in event properties. - Identity is the join key.
identifylinks anonymous activity to a known user; duplicate or changingdistinct_idvalues split users and break funnels. - Group analytics attaches events to accounts or teams via group keys, so B2B metrics are not distorted by counting individuals.
- A tracking plan and Lexicon governance keep event and property definitions consistent; renaming is possible, but schema drift is the real risk.
- Funnels need ordered steps and a conversion window; retention needs a cohort definition and return event; Flows shows paths, not causation.
Worked example
You want signup-to-paid conversion. Track Signup Started, Signup Completed, and Purchase Completed, with plan on purchase and signup_source on start. Build a funnel in that order, break down by signup_source, and set a 7-day conversion window. If Signup Completed fires before identify, anonymous and known IDs may split; fix by identifying at account creation and using alias only for genuine pre/post-login merges.
Traps
Putting user traits only on events; high-cardinality properties such as email or timestamp in breakdowns; changing event names without a migration plan; using pageviews as a proxy for product actions; and treating correlation in Flows as causation.