Mixpanel Product Analytics Certification key terms

A single recorded action a user performs, such as a signup or purchase, stored with a name, timestamp, and associated properties. Events are the raw units that every Mixpanel report aggregates and filters.

A named attribute attached to an event that describes its context, such as plan type, button label, or revenue amount. Properties enable breakdowns, filtering, and segmentation in reports.

A persistent record of attributes about an individual user, such as signup date or plan, stored separately from events. Profiles support cohort building and user-level reporting without re-sending data on each event.

A key-value attribute stored on a user profile rather than on an event, describing durable traits like country, plan tier, or lifetime value. User properties update over time and drive segmentation in user-based reports.

A property registered once on the client so it is automatically attached to every subsequent event, useful for values like app version or account ID. It reduces repetitive code and keeps contexts consistent across events.

The client or server SDK method that sends an event and its properties to Mixpanel. Correct naming, property typing, and batching in track calls determine data quality in every downstream report.

The process of linking anonymous pre-login activity to a known user ID so one person is counted once. It typically uses an identify call plus alias logic to stitch device-level identifiers to an account.

The primary identifier Mixpanel uses to attribute events to a user. It must be stable and consistent across devices and sessions, otherwise users fragment into duplicate profiles and reports overcount.

A call that maps a second identifier, such as an email or CRM ID, onto a user's existing Distinct ID. Aliasing consolidates activity from multiple sources under one profile.

The SDK method that writes or updates user profile properties, such as setting a plan or incrementing a counter. It affects user-level data, not event streams, and supports operations like set, set_once, and increment.

A saved group of users who share a defining behavior or trait, such as completing onboarding in week one or being on a paid plan. Cohorts can be reused to filter any report.

A report measuring how many users complete an ordered sequence of events within a conversion window. It exposes step-by-step drop-off and supports breakdowns, segment comparison, and time-to-convert analysis.

The time limit within which a user must complete all steps of a funnel to count as converted. It prevents counting conversions that occur too late to be attributable to the initial step.

A report showing how many users return to perform an event after an initial action, tracked over day, week, or month intervals. It distinguishes new-user retention from returning-user behavior.

A report measuring how frequently users perform an action within a period, such as how many days per week someone uses a feature. It reveals habit strength rather than simple return behavior.

Splitting a report's results by a property value, cohort, or event so segments can be compared side by side. Breakdowns reveal which plans, platforms, or channels behave differently within an aggregate metric.

A report mode that combines multiple metrics with arithmetic, such as dividing signups by visits or subtracting one event count from another. Formulas create derived rates that no single event provides.

The flexible reporting interface for counting events over time with filters, breakdowns, and formulas. It is the default starting point for exploring trends before moving to specialized reports.

A report that visualizes the paths users take after or before a chosen event, showing which actions most often follow. It surfaces unexpected navigation patterns and dead ends.

A bounded period of user activity, typically ending after a period of inactivity. Session definitions affect session-based metrics and replay grouping, so teams must agree on the timeout.

Recorded playback of a user's on-screen interactions, including taps, scrolls, and navigation, linked to their event timeline. It helps diagnose friction that aggregate metrics cannot explain.

A burst of rapid repeated taps or clicks on the same element, usually signaling that the interface failed to respond. Detecting rage clicks highlights broken controls and frustrating flows.

A click on an element that produces no visible response, such as a non-interactive label or a broken link. Dead clicks reveal misleading affordances in the interface.

A visualization of where users click, tap, or scroll on a page, with intensity indicating frequency. Heatmaps complement replay by summarizing attention across many sessions at once.

A measure of how far down a page users scroll, often expressed as the percentage of visitors reaching a given point. It indicates whether content below the fold is actually seen.

A recorded visit to a web page, usually captured automatically by a web SDK or snippet. Page views are foundational for web traffic, acquisition, and content engagement reporting.

A set of query-string tags, such as source, medium, and campaign, appended to a URL to identify where traffic came from. Consistent UTM conventions are required for reliable acquisition reporting.

The practice of assigning credit for a conversion to the marketing touchpoint that preceded it, using a chosen model such as first touch or last touch. It depends on correctly captured acquisition properties.

A software development kit installed in a web, iOS, Android, or server codebase to send events and profiles to Mixpanel. SDK choice and initialization timing affect data completeness and identity handling.

A property identifying which release of a mobile app generated an event. Segmenting by app version isolates bugs and behavior changes introduced in specific builds.

A message delivered to a mobile device outside the app, often used to re-engage users. Measuring opens and downstream actions reveals whether notifications drive meaningful activity or just noise.

A controlled experiment that randomly assigns users to variants and compares an outcome metric to determine which performs better. Validity depends on randomization, adequate sample size, and a pre-declared success metric.

The baseline variant in an experiment that receives no change or the current experience. Comparing treatment against control isolates the effect of the change from seasonality and other noise.

An event recorded when a user actually enters an experiment variant, proving they were eligible and saw the treatment. Analyzing outcomes by exposure avoids dilution from users who never encountered the change.

The probability that an observed difference between variants is unlikely to arise from chance alone, usually expressed as a p-value against a threshold. It does not by itself prove practical importance.

The number of users or observations included in an experiment or analysis. Too small a sample produces unreliable conclusions, so teams calculate a required size before launching.

A secondary metric monitored during an experiment to ensure the change does not cause harm, such as crash rate or churn. It can override a positive primary result.

The rate at which users stop using a product or cancel a subscription over a period. It is often the inverse of retention and is a common guardrail in experiments and lifecycle reporting.