Loading tutorials…
Loading tutorials…
Spinning up a Mixpanel project takes 20 minutes. Spinning it up so the data is still trustworthy in 18 months — that's the work most teams skip and pay for later in event-renaming sprints and broken dashboards.
Who this is forSaaS founders, product managers, and engineering leads installing Mixpanel for the first time. If you're paying $50K+/year in engineering salary against a product no one is measuring properly, every month without clean analytics is decisions made on vibes.
What you'll need
Step 1
Sign up at mixpanel.com, create an organization, and pick US or EU data residency. The residency choice cannot be changed later without a full project rebuild.
Go to mixpanel.com and click Sign Up. Use your business email — Mixpanel ties Single Sign-On (SSO) and SCIM provisioning to your verified domain later, so a consumer Gmail will lock you out of those features.
Pick your data residency: US or EU. Choose EU only if you have GDPR-driven contractual reasons to keep data in-region (a customer DPA requires it, or you're a German/French B2B company selling into regulated industries). Otherwise pick US — it's the default and most integrations assume it.
Important: residency is set at the organization level on first sign-up and CANNOT be moved. If you pick EU and later need US (or vice versa), you create a new org and re-import — Mixpanel doesn't migrate cross-residency.
Name the organization after your legal entity, not the product (e.g., 'Acme Inc' not 'Acme Web App'). One org can hold many projects.
After creating the org, Mixpanel drops you into a default project. Don't use this default project for anything — go straight to Settings → Project Settings and rename it to 'Production' or delete it and create explicit projects in the next step.
Step 2
Settings → Project Settings → +Create Project. Make at least two: 'Acme — Production' and 'Acme — Development'. Never let test data into production.
In the Mixpanel UI, click the project picker (top-left) → +Create Project. Name it 'Acme — Production'. Pick the same data residency as the org (it's enforced — no cross-region projects).
Create a second project: 'Acme — Development'. This is where your engineers fire test events, validate event taxonomy, and break things without polluting the production data lake.
Each project has its own Project Token (find it under Settings → Project Settings → Access Keys). The token is what your SDK uses to route events to the right project. Copy both tokens somewhere safe.
Set up a third project later if you also need 'Acme — Staging' (events from your staging environment that mirror prod but are still pre-release). Most teams don't need this — dev + prod is fine.
Why this matters: a single Mixpanel project with mixed dev + prod events makes funnel/retention/cohort analysis worthless. You can't trust 'percent of users who completed onboarding' when 30% of that data is your own engineering team clicking through QA flows.
Step 3
Pick your SDK (JavaScript for web, Swift/Kotlin for native, Server SDK for backend) and call mixpanel.init() with your project token. Most teams start with JavaScript.
JavaScript (web app): in Settings → Project Settings, click Set Up Mixpanel → JavaScript. Copy the snippet. Paste it into the <head> of your app, replacing YOUR_TOKEN with the production project token (or dev token if you're testing).
Modern installs use npm: `npm install mixpanel-browser`, then in your app entry point: `import mixpanel from 'mixpanel-browser'; mixpanel.init('YOUR_TOKEN', { debug: false, track_pageview: true, persistence: 'localStorage' });`
Native iOS: `pod 'Mixpanel-swift'`, then `Mixpanel.initialize(token: 'YOUR_TOKEN', trackAutomaticEvents: false)` in your AppDelegate. Set trackAutomaticEvents to false — Mixpanel deprecated auto-events and the new SDK fires far fewer by default, but explicit is still better.
Server-side (Node.js, Python, Ruby): use a Server SDK for events that should never run on the client (purchase confirmations from your payment webhook, plan changes from your billing system). Server SDKs require the project token + a Service Account for some operations.
After install, deploy to your dev environment first. Open the app, click around, and watch events appear in Mixpanel → Events (left sidebar) → Live View. Events show up within 60 seconds.
Step 4
Mixpanel has two real-time tools: Live View (streaming event feed) and Events (left sidebar → Data Management → Events). Use both before declaring victory.
Live View: in the left sidebar, click Events → Live View (top-right tab). It shows every event hitting the project in real time, with all properties. Filter by distinct_id (your own user ID) to see only your test session.
Open your dev app in a browser tab. Fire a test event (sign up with a test email, click a CTA, complete an onboarding step). Within 30-60 seconds it should appear in Live View with the right event name and properties.
Click the event row in Live View to expand it. Verify every property is there: event name, distinct_id, time, user_id (if you've identified the user), and any custom properties you sent (plan_tier, signup_source, etc.).
If an event doesn't appear: open browser DevTools → Network tab, filter for 'api.mixpanel.com' or 'api-eu.mixpanel.com' (depending on residency). You should see POST requests on every event. If you see 0 requests, the SDK isn't loaded or is misconfigured. If you see requests but they return 401/403, the project token is wrong.
Once Live View confirms events flow, go to Data Management → Events (left sidebar) and verify each event appears in the catalog with the correct property schema. This is the canonical list Mixpanel uses to build all reports.
Step 5
Settings → Project Settings → Data Retention. Defaults vary by plan but the controls live in the same place. Also: lock down PII before any user data flows.
Data retention: on the Growth plan, retention is 5 years for events and lifetime for user profiles. On Enterprise plans you can extend. Verify your retention by going to Settings → Project Settings → Data Retention. If you need longer, this is the negotiation lever with your AE.
PII governance: in Settings → Project Settings → People → Data Privacy, configure which user properties are considered PII. Email, phone, full name should be flagged. Mixpanel honors these for GDPR/CCPA deletion requests via the People → Manage tab.
Set up an organization-level audit log if you're on Enterprise (Org Settings → Audit Log). This is your record of who changed event definitions, deleted dashboards, or rotated tokens.
Configure SSO at the org level (Org Settings → Single Sign-On) — SAML for Okta, Google Workspace SSO, or Microsoft Entra. Don't let people log in with passwords once you have more than 3 admins.
If you're on EU residency, double-check that your SDK is calling api-eu.mixpanel.com (set api_host in the JS init: `mixpanel.init('TOKEN', { api_host: 'https://api-eu.mixpanel.com' })`). The default is US — if you set up an EU project but never updated the SDK, your data is being routed wrong.
Step 6
Add at least one backup admin and review who has access. Mixpanel has no recovery path if you lose your only owner account.
Project access: Settings → Project Settings → Team. Click + Add Team Members. Add at least one other person with the Owner or Admin role.
Role guidance: Owner = full control including billing. Admin = full project control without billing. Analyst = read + create reports. Consumer = read-only dashboards (good for execs and external stakeholders who shouldn't be editing).
Organization access: separate setting at Org Settings → Members. Org owners can create new projects and manage billing. Project admins cannot.
Document admin access in your team wiki. The most common Mixpanel emergency is 'the only admin left the company and we can't recover the project'. Avoid it.
Remove anyone who left the company. Mixpanel does not auto-deprovision unless you've configured SCIM.
Step 7
Before your team fires 50 events, agree on naming conventions. Mixpanel has no built-in renaming — fixing event names later is a multi-week migration.
Pick a single naming convention. The two common patterns: 'Object Action' (e.g., 'Account Created', 'Subscription Upgraded') or 'verb_object_snake_case' (e.g., 'signup_completed', 'plan_upgraded'). Mixpanel has historically favored the former; modern teams often pick the latter for consistency with backend logs.
Pick consistent property naming: snake_case (plan_tier, signup_source) or camelCase (planTier, signupSource). Mix-and-match is the dominant pain in 6-month-old projects.
Reserve event names for actions, not page views. 'Pricing Page Viewed' is fine, but 'Pricing' as an event name is too vague. Page views in general are usually better tracked as a single 'Page Viewed' event with a `page` property.
Define the 5-10 events that matter most BEFORE shipping the SDK install. Examples for SaaS: Account Created, Email Verified, Workspace Created, First Action Completed, Invite Sent, Subscription Started, Subscription Cancelled.
Document the taxonomy in a shared doc (Notion, Confluence, Google Doc). Every new event added must reference this doc. Mixpanel's Lexicon feature (Data Management → Lexicon) lets you describe and lock event definitions inside Mixpanel — use it.
Common mistakes
Using a single Mixpanel project for dev and prod
What goes wrong: Your engineers fire test events from staging into the same project as real customers. 'Percent of users who completed onboarding' includes 47 QA accounts. The funnel chart in your weekly product review is wrong by 10-20%, but you don't know that — so decisions get made on it.
How to avoid: Create two projects (production + development) on day one. Each gets its own Project Token. Wire dev/staging environments to the dev token via env var; production wires to the prod token. Cost is $0 — both projects share the Growth plan.
Picking the wrong data residency
What goes wrong: You pick EU residency because a salesperson said 'it's safer'. Six months later your Snowflake warehouse is in us-east-1 and every Mixpanel → warehouse sync runs cross-region — egress costs $400-800/month extra. Or vice versa: you pick US and then your German enterprise prospect blocks the deal because data sits outside the EU.
How to avoid: Confirm residency requirements with your security/legal contact BEFORE creating the org. If you guessed wrong and have <30 days of data, kill the org and create a new one. Past 30 days, you live with it or pay the rebuild cost.
Mixing event naming conventions ("Sign Up" vs "signup" vs "Signup Completed")
What goes wrong: Three engineers ship three variants of the signup event over six months. Your funnel from 'visited pricing' → 'signed up' silently drops 30% of users who fired the 'wrong' event. Conversion rate looks like 1.2% when the real number is 1.8%. Every CAC/LTV calculation is wrong.
How to avoid: Pick one convention (verb_snake_case is most common in modern stacks). Document it. Use Mixpanel's Lexicon to lock event definitions. When you find variant events, run a single 'CREATE EVENT FROM EVENT' transformation in Data Management to merge them, then delete the source.
Skipping the SDK install verification
What goes wrong: Engineering ships the install on Friday. Marketing builds a dashboard on Monday. Nobody validates events end-to-end. Two weeks later you realize purchase events never fired because the SDK was initialized AFTER the page's checkout-complete event. You've lost the data — Mixpanel doesn't backfill from anything except a one-shot import from server logs.
How to avoid: Before declaring the install done, fire every Tier 1 event (signup, activation, purchase) from a real test session and verify each in Live View with all properties populated. Treat this as a deployment checklist item, not a "we'll get to it" task.
Letting Mixpanel auto-track everything via track_pageview: true alone
What goes wrong: You turn on auto-pageview tracking but never identify users. Mixpanel sees thousands of anonymous distinct_ids that never merge with logged-in users. Your 'Day-7 retention' chart shows 8% because anonymous sessions can't be retained. Real retention is closer to 40%.
How to avoid: Pair pageview tracking with explicit mixpanel.identify(userId) the moment a user authenticates. Use mixpanel.alias() on first signup to bridge the anonymous → identified id. See the user-identification tutorial for the full pattern.
No backup admin / single point of failure
What goes wrong: The one engineer with admin access leaves the company. Their work email is deprovisioned. Mixpanel support cannot transfer ownership without verification from the now-locked email. You either rebuild the project from scratch (losing all dashboards, cohorts, and funnels) or pay Mixpanel for legal-process recovery.
How to avoid: Always have 2+ Owner or Admin users. One should be a corporate account tied to a shared inbox (analytics@acme.com), one a backup tied to a current employee. Document admin access in your team wiki. Use SCIM if you have it.
Recap
Done — what's next
How to set up Mixpanel event tracking the right way
Read the next tutorial
Hand it off
Setting up Mixpanel cleanly once is a 1-week project. Maintaining clean taxonomy, fresh cohorts, and an evolving event catalog is a job. If you want the install done right plus a quarterly governance audit, a vetted product analytics specialist on EverestX typically runs $300-700/mo at $14-16/hr — and the initial setup is usually a 1-2 week sprint at $600-1,200 total.
See specialist rates
Mixpanel has a free Starter plan that includes up to 1M events/month and most core features (Funnels, Cohorts, Retention, Insights). The paid Growth plan starts around $20/month per 10K MTUs (monthly tracked users) and unlocks Experiments, group analytics, and unlimited saved reports. Enterprise pricing is negotiated and unlocks SSO, data governance, and 100% data retention guarantees.
GA4 is built around web sessions and marketing attribution. Mixpanel is built around users and product events. If you want to know which ad drove a conversion, GA4 is better. If you want to know whether users who use Feature X retain 2x better than users who don't, Mixpanel is better. Most product-led SaaS companies run both.
They're functionally equivalent for 80% of use cases. Mixpanel is generally cheaper at lower MTU tiers and has a cleaner UX for funnels and cohorts. Amplitude is stronger on behavioral cohorts and Pathfinder. We have a dedicated comparison tutorial — see the related tutorials below. If you're under 100K MTU, Mixpanel is usually the better starter.
Yes. Mixpanel has server SDKs for Node, Python, Ruby, Java, PHP, Go, and .NET. Server-side is the right choice for events that should never run on the client (purchase confirmations from a payment webhook, subscription changes from your billing system). Most teams run a hybrid: client-side for UI events, server-side for revenue and entitlement events.
Mixpanel has a 30-day soft-delete window for projects. Within 30 days, contact support and they can restore. After 30 days, deletion is permanent and there is no recovery path. Be careful — and use SCIM + audit logs on Enterprise to track who has destructive access.
Mixpanel
Mixpanel doesn't fail because events break — it fails because event names drift. Three engineers, three opinions, three versions of 'signup' over a year. Here's how to ship instrumentation that holds up.
Mixpanel
User identification is the single most-broken part of Mixpanel in DIY installs. Anonymous users never merge with logged-in users, retention curves look like 8% when reality is 40%, and every cohort is wrong. Here's the pattern that actually works.
Amplitude
Most Amplitude projects break in month three because of decisions made in the first hour. This walks through workspace setup, identity resolution, and the early taxonomy choices that determine whether your data is trustworthy six months from now.
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.