Loading tutorials…
Loading tutorials…
Cohorts are how Mixpanel goes from 'analytics tool' to 'user-targeting engine'. The team that learns to build, sync, and curate cohorts well runs marketing 2-3x more efficiently than the team that doesn't.
Who this is forPMs, growth marketers, and lifecycle marketers who need to segment users for analysis, email targeting, in-app messaging, or paid-ad audience sync. If you keep asking engineering for 'a list of users who did X' via SQL, this is the upgrade.
What you'll need
Step 1
Before building, list the cohorts that map to real business decisions. Most companies need 5-10 well-defined cohorts, not 80 ad-hoc ones.
Write the cohort name + business purpose in a doc. Examples for SaaS: Power Users (top 20% of weekly active), New Users (signed up in last 14 days), Activated Users (completed key action within 7 days), Trial Users (in trial, not yet paying), Paying Users (active subscription), At-Risk (haven't logged in for 14 days), Churned (cancelled in last 30 days), Free-Forever (signed up 60+ days ago, never upgraded), Expansion Targets (using >80% of plan limits), Internal (your team — for exclusion).
For each cohort, define the use cases: analysis (slice funnels), targeting (email, in-app), exclusion (filter from other reports).
Decide static vs dynamic. Static = snapshot at a point in time, never updates. Dynamic = membership recalculates continuously. Default to dynamic; use static only for time-bound experiments.
Decide refresh frequency for dynamic cohorts. Real-time (subscriptions, paid users) costs more processing. Daily (lifecycle stages) is usually enough.
Get sign-off from PM + marketing before building. Once cohorts ship to lifecycle email tools, changing the definition retroactively confuses downstream systems.
Step 2
Users → Cohorts → +New Cohort. Define inclusion rules using events, People properties, or other cohorts. Save with a descriptive name.
In Mixpanel left sidebar, click Users → Cohorts (or Data Management → Cohorts in newer UI). Click +New Cohort.
Define inclusion. Three rule types: (1) Event Performed — fired event X at least N times in the last Y days. (2) Property — has a People Profile property matching a value. (3) In/Not In Another Cohort — combine cohorts.
Example: Power Users = Event Performed (any event) at least 10 times in last 7 days AND Property (plan_tier = 'pro').
Example: At-Risk = Event Performed (any event) 0 times in last 14 days AND Property (subscription_status = 'active').
Add multiple conditions with AND/OR logic. Mixpanel renders the rules visually so non-technical users can review.
Click Save. Name it descriptively: 'Power Users (10+ events/week, Pro plan)'. The name should make the definition obvious without opening the cohort.
Step 3
Lifecycle stages (Trial, Paying, At-Risk, Churned) are best defined by People Profile properties you maintain server-side.
On your backend, after every subscription event (signup, upgrade, cancellation), push a `lifecycle_stage` property to Mixpanel People Profile: `mixpanel.people.set(user.id, { lifecycle_stage: 'trial' })` (server-side).
Now you can build cohorts as: Property lifecycle_stage = 'trial' instead of complex event-based rules.
Why this matters: property-based cohorts are instant to evaluate (no rolling window calculation) and stay in sync with your billing system. Event-based 'definition of a paying user' drifts over time as you change which events represent payment.
Maintain ONE source of truth for lifecycle stage — usually your billing/auth system. Don't have Mixpanel infer it from events; have your backend push the canonical value.
Other valuable People Profile lifecycle properties: account_age_days, plan_tier, mrr_amount, last_seen_date, total_logins, signup_source, company_size.
Step 4
Cohorts can reference other cohorts. Use this to build hierarchies — e.g., "Power Users in Enterprise plan" = In Power Users AND In Enterprise.
When building a new cohort, the In/Not In Cohort rule lets you reference existing cohorts. Pick from the dropdown.
Example: Expansion Targets = In Power Users AND Property (plan_tier != 'enterprise') AND Property (usage_percent > 80).
Example: At-Risk Power Users = In Power Users LAST WEEK AND NOT In Power Users THIS WEEK. (Uses Mixpanel's time-windowed inclusion).
Hierarchical cohorts make it easy to slice: 'show me the funnel for Power Users in Trial' is now one click in the Funnel report's audience filter.
Avoid deeply-nested cohorts (Cohort A includes Cohort B which includes Cohort C). Performance degrades and changing the base cohort silently breaks everything downstream.
Step 5
Mixpanel cohorts sync to email tools (Customer.io, Braze, Iterable, Mailchimp), ad platforms (Meta, Google Ads), and CRM (Salesforce, HubSpot) via native integrations.
Open the cohort. Click the Sync Cohort button (usually top-right, varies by UI version).
Pick the destination: Customer.io, Braze, Iterable, Meta Ads, Google Ads, HubSpot, Salesforce, S3 bucket, etc.
Configure the sync: real-time or daily, full sync or incremental, which user properties to include alongside the cohort membership.
First sync usually requires connecting the destination as an integration (Data Management → Integrations). One-time setup.
After sync, the cohort appears as an Audience in the destination tool. You can now send email to 'At-Risk Power Users' from Customer.io, run a Meta Ads retargeting campaign to 'Trial Users Who Didn't Convert', etc.
Step 6
Cohort sprawl kills Mixpanel projects. Set a quarterly calendar reminder to review all cohorts and archive anything unused.
Go to Users → Cohorts. Sort by Last Used or Last Updated.
For each cohort, ask: is this still in use? Does the definition still match the original intent? Has the event taxonomy it depends on changed?
Archive any cohort not used in 90+ days. Mixpanel keeps archived cohorts recoverable for 30 days in case you change your mind.
Rename cohorts that have drifted from their original intent. 'Power Users' built in 2023 with definition '5+ events/week' is not the same as the 2026 definition '10+ events/week'.
Document each surviving cohort in a shared doc with: definition, owner, downstream tools it syncs to, last review date. Future PMs will thank you.
Step 7
Apply a single cohort (e.g., "External Users — exclude internal") as a default filter on every funnel, retention chart, and dashboard.
Build a cohort: Internal Users = Property (email contains '@yourcompany.com') OR Property (is_internal = true).
When building reports, apply the inverse: filter to 'Not In Internal Users' as a default. This excludes your team from every funnel/retention calculation.
Save reports with this filter pre-applied. Templates for new reports should start with the filter already in place.
Same pattern for: paying users only (filter for retention charts), specific geography (regional dashboards), specific plan tier (plan-tier-specific funnels).
Mixpanel doesn't have a true 'project-wide always-on filter' — you have to apply it per report. But by saving filtered templates as the starting point for new reports, you achieve the same effect.
Common mistakes
Cohort sprawl — 100+ cohorts nobody can keep track of
What goes wrong: Each PM builds 'their' cohorts ad-hoc. Over 18 months you accumulate 150 cohorts with overlapping definitions ('Power Users', 'Active Users', 'Engaged Users', 'High-Value Users' — all subtly different). New team members can't tell which to use. Reports cite different cohorts for the same concept and contradict each other.
How to avoid: Maintain a documented cohort library — 10-15 canonical cohorts that everyone uses. Quarterly archive unused cohorts. Anyone building a new cohort must justify why an existing one doesn't fit.
Building cohorts on event-based lifecycle when properties would be cleaner
What goes wrong: You define 'Paying Users' as 'fired purchase_completed event in last 30 days'. Annual subscribers who paid 9 months ago don't qualify. Your 'Paying Users' cohort excludes 60% of actual paying customers. Email campaigns to 'paying customers' miss most of them.
How to avoid: Push lifecycle stage as a People Profile property from your billing/auth system. Cohort = Property `lifecycle_stage = paying`. Property reflects current state; events reflect transitions.
Using "any event" in cohort definitions
What goes wrong: Power Users = 'any event 10+ times in 7 days'. Page Viewed alone gets many users to 10+ events. Your Power Users cohort is just 'people who load pages a lot' — not actual engaged users. Retargeting ad spend to this cohort wastes 40% on low-intent users.
How to avoid: Define cohorts using specific high-value events. Power Users = `feature_used` OR `workspace_action` OR `report_generated` 10+ times. Avoid `Page Viewed`, `session_start` as cohort signals.
Cohorts that include test/internal users
What goes wrong: Your 'Active Users' cohort includes 80 internal team members who fire events constantly. Daily Active Users (DAU) reports overstate by 20-40% for small/early-stage products. Investor metrics are wrong. Fundraising decks cite inflated numbers.
How to avoid: Always exclude internal users from cohort definitions. Maintain an `is_internal = true` People Profile property on your team. Add `NOT In Internal Users` to every cohort that drives reporting or external claims.
Static cohort used as if dynamic
What goes wrong: You build a static cohort 'Q4 Signups' to analyze a specific group. Six months later you reference 'Q4 Signups' in a retention chart and assume it includes recent users. It doesn't — static means frozen. You report flat retention when reality is growing.
How to avoid: Default to dynamic cohorts. Use static only for one-time analyses (cohort retention for a specific signup month). Name static cohorts with the date in the name: "Static — Q4 2025 Signups".
Syncing cohorts to email tools without testing the sync
What goes wrong: You sync 'At-Risk Users' to Customer.io and trigger a re-engagement email. The sync ran with an outdated cohort definition. 2,000 currently-active paying customers received a 'we miss you' email. CS team has 50 angry replies.
How to avoid: Always test syncs with a small subset first. Use Customer.io / Braze segment views to confirm membership matches your expectation before activating any email campaign on a synced cohort.
Recap
Done — what's next
How to set up Mixpanel funnels the right way
Read the next tutorial
Hand it off
Cohorts are where Mixpanel becomes a marketing engine instead of just a reporting tool. A vetted product analytics specialist can design + ship your lifecycle cohort library, set up syncs to your email and ad tools, and document the whole system for $800-1,800 total at $14-16/hr — and your lifecycle email open rates typically lift 30-50% on properly-defined cohorts.
See specialist rates
For analysis: 100+ users. For lifecycle email targeting: 50+ users (smaller is fine for high-stakes 1:1 emails). For paid-ads audience sync: 1000+ users (Meta and Google have minimum audience sizes around 1000 for retargeting).
Cohort is the canonical term in Mixpanel — a saved group of users defined by rules. 'Segment' is sometimes used interchangeably or to mean an ad-hoc filter applied to a single report. Cohorts are reusable across reports and syncable to external tools; ad-hoc segments aren't.
Yes — cohorts are not mutually exclusive. A single user can be in 'Power Users' AND 'Trial Users' AND 'New Signups' simultaneously. This is the right model; lifecycle stages overlap (someone is both 'new' and 'trial').
Most cohorts update within a few minutes of new event data arriving. Property-based cohorts update instantly when the property changes. Event-based cohorts with rolling windows (e.g., '10 events in last 7 days') update with the next data refresh cycle, typically every 5-15 minutes.
Mixpanel has native integrations for Meta Ads, Google Ads, TikTok Ads, and others under Data Management → Integrations. Connect your ad account once, then in any cohort click Sync → pick the destination. Audience appears in the ad platform within 6-24 hours. Mixpanel matches users by email or phone hash.
Mixpanel
Funnels are the most-used Mixpanel report and the most-misread. The conversion-window setting alone changes 'we have a 12% signup-to-paid funnel' to '34%' — and most teams never touch it. Here's the build that actually answers the question.
Mixpanel
Retention is the single most predictive metric for product-led growth — and the most misread. 'Day-7 retention is 35%' means nothing without knowing the cohort and the return event. Here's the build that makes retention actually decision-grade.
Amplitude
Cohorts and Personas are where Amplitude beats GA4 by a mile. But most teams build sloppy cohorts and end up with overlapping segments that conflict. Here's the discipline that keeps them clean.
Mixpanel
Product analytics is a job, not a tool. The teams that pretend it's a tool spend 18 months building a Mixpanel project that doesn't answer their questions. The teams that hire someone get clean answers in a quarter. Here's how to know which path you're on.