How to set up event tracking in Mixpanel correctly

by

TL;DR

You can have Mixpanel tracking real user behavior in under two hours if you do the planning upfront. The process covers creating a project, defining an event taxonomy, installing the SDK, and validating the data stream before anything ships. You need a free Mixpanel account, access to your codebase or a tag manager, and a simple spreadsheet to map out events before you touch any tracking code.

What You Need Before You Start

  • A Mixpanel Free tier account (supports up to 20 million monthly events as of 2026, no credit card required at signup)
  • Access to your product’s frontend or backend codebase, OR admin rights to Google Tag Manager if you prefer a no-code path
  • Node.js 18+ for server-side tracking, or a modern browser environment for client-side JavaScript
  • A spreadsheet or Notion doc to document your event plan before implementation (non-negotiable)
  • Optional: a staging or development environment to test events without polluting production data
  • Optional: Segment if you plan to route events to multiple analytics destinations from a single SDK call

Step 1: Create Your Mixpanel Project and Grab Your Token

Go to mixpanel.com and sign in or create a free account. Once you are in, click the organization name in the top-left corner, then select Create project. Name it something that maps clearly to your product and environment, like my-app-production or my-app-staging. Keep production and staging as separate projects from day one. Mixing them together is one of the most common early mistakes, and undoing it is painful.

After creating the project, navigate to Settings > Project Settings. Your Project Token appears at the top of the page. Copy it and store it in a .env file. Every SDK call authenticates with this token, so treat it like a private key even though it is technically a public-facing value.

You should now see your empty project dashboard with a Project Token string that looks like a1b2c3d4e5f6789012345678. No event data will appear yet.

MIXPANEL_TOKEN=a1b2c3d4e5f6789012345678abcdef01

Step 2: Define Your Event Taxonomy in a Spreadsheet First

This step happens entirely outside Mixpanel, but skipping it causes more long-term pain than any technical mistake. Open a spreadsheet and create four columns: Event Name, Trigger, Properties, and Owner.

Event names should follow one consistent pattern across your entire product. The most widely used convention is Object Action in title case: Button Clicked, Form Submitted, Video Played, Subscription Cancelled. Avoid vague names like Click or Event 1. They become meaningless the moment you have more than a handful of them.

For each event, list the properties you want to capture and their data types. A Button Clicked event might carry button_name (string), page_url (string), user_plan (string), and experiment_variant (string).

Here is a minimal example for a SaaS onboarding flow:

Event Name Trigger Properties Owner
Page Viewed Every page load page_name, referrer Frontend
Sign Up Started Click on “Get started” plan_type Frontend
Sign Up Completed Successful account creation plan_type, signup_method Backend
Dashboard Viewed First load of /dashboard user_age_days Frontend

You should now have a reference doc that engineers can implement against without guessing at naming or structure.

Step 3: Install the Mixpanel JavaScript SDK

For a web product, the fastest path is the npm package. Run this in your project root:

npm install mixpanel-browser

Then initialize it once at the root of your app, typically in index.js, App.tsx, or your equivalent entry point:

import mixpanel from 'mixpanel-browser';

mixpanel.init(process.env.MIXPANEL_TOKEN, {
  debug: process.env.NODE_ENV !== 'production',
  track_pageview: false,
  persistence: 'localStorage'
});

Setting debug: true in development prints every event to the browser console so you can verify calls without opening Mixpanel every time. Setting track_pageview: false gives you control over when page view events fire, which matters a lot in single-page apps where the URL changes without a full page reload.

You should now see a console log on page load confirming the SDK initialized, something like [Mixpanel] Initialized.

Step 4: Identify Your Users Correctly

Anonymous tracking is useful, but Mixpanel’s real value comes from tying events to known users. The identification step is where many implementations break quietly. If you get this wrong, you end up with duplicate user profiles and funnels that show 90% drop-off where none exists.

Call mixpanel.identify() immediately after a user logs in. Pass your backend’s unique user ID, not an email address.

// After successful login
function onLoginSuccess(user) {
  mixpanel.identify(user.id); // e.g. "usr_abc123"
}

For brand new users who sign up in the current session, call mixpanel.alias() once to link the pre-signup anonymous events to the new user ID. You call alias exactly once per user, at the moment of account creation.

// At the moment a new account is created
mixpanel.alias(newUser.id);
mixpanel.identify(newUser.id);

You should now see that events fired before login and after login both appear under the same user profile in Mixpanel’s Users view.

Step 5: Track Your First Event With Properties

With identification in place, you can fire real events. Use mixpanel.track() and pass the event name from your taxonomy doc along with a properties object.

function onStartTrialClick(planType) {
  mixpanel.track('Button Clicked', {
    button_name: 'Start Free Trial',
    plan_type: planType,
    page_url: window.location.pathname
  });
}

Keep property names in snake_case and be consistent. Mixpanel is case-sensitive, so plan_type and Plan Type are treated as two separate properties in every report. Enforce your convention early by creating a shared constants file or a TypeScript enum that all engineers import from.

// constants/events.ts
export const EVENTS = {
  BUTTON_CLICKED: 'Button Clicked',
  SIGN_UP_COMPLETED: 'Sign Up Completed',
} as const;

You should now see the event appear in Reports > Events within a few seconds of firing it in your app.

Step 6: Attach Context to Every Event Using Super Properties

Super properties are values you register once, and Mixpanel attaches them automatically to every subsequent event in that session. This saves you from manually adding the same fields to dozens of track() calls.

// Register after identifying the user
mixpanel.register({
  app_version: '3.4.1',
  user_plan: currentUser.plan,   // e.g. "pro", "free"
  environment: process.env.NODE_ENV
});

Use super properties for values that are stable within a session: app version, subscription tier, locale, or A/B test variant. If a value changes mid-session, call mixpanel.register() again with the updated value and it will overwrite the previous one.

You should now see every event in Mixpanel’s event stream carrying app_version, user_plan, and environment automatically, without you passing them in each individual track() call.

Step 7: Build Out User Profiles With $set

Events tell you what users do. User profiles tell you who they are. Populate profiles with mixpanel.people.set() right after identification.

mixpanel.people.set({
  $name: user.name,
  $email: user.email,
  $created: user.createdAt,
  plan: user.plan,
  company_size: user.companySize
});

Mixpanel has reserved property names prefixed with $. Use $name, $email, and $created for standard fields so they render correctly in the UI. For custom attributes like plan or company_size, use plain names without the dollar sign.

For properties that grow over time, use mixpanel.people.increment() instead of set() to avoid race conditions when multiple events fire in quick succession.

mixpanel.people.increment('reports_generated', 1);

You should now see a user profile in the Users section with name, email, plan, and your custom properties all filled in.

Step 8: Validate Your Tracking With the Live Events Stream

Before declaring the implementation done, open Reports > Events in Mixpanel and watch the live stream while you walk through your own app flows. Fire each event from your taxonomy doc and confirm it appears with the correct name and properties.

Check three things for each event:

  1. The event name exactly matches your taxonomy doc, character for character
  2. All expected properties are present with real values, not undefined or null
  3. The event is attributed to the correct user ID, not an anonymous ID

If you spot undefined property values, add null guards in your code before the track() call.

if (user && user.plan) {
  mixpanel.track('Dashboard Viewed', {
    user_plan: user.plan
  });
}

You should now see a clean, fully attributed event stream in Mixpanel with zero undefined values across your core event set.

Step 9: Build a Funnel Report to Confirm the Full Flow

With individual events validated, wire them together into a funnel to confirm end-to-end tracking cohesion. Go to Reports > Funnels and build a three-step funnel: Sign Up Started → Sign Up Completed → Dashboard Viewed.

If the drop-off between steps looks unrealistically high, like 90% of users who started sign-up never completed it, your identification is probably broken somewhere. Events are being attributed to separate anonymous IDs instead of a single user.

Use the User breakdown in the funnel view to spot duplicate or orphaned profiles. The fix almost always comes down to calling mixpanel.identify() at the right point, or ensuring alias() was called at signup and not on every subsequent login.

You should now see a funnel with plausible conversion rates, with users flowing through as named individuals rather than a mix of anonymous and identified IDs.

Common Mistakes To Avoid

  • Tracking events before identifying users. Events fired before mixpanel.identify() are anonymous. If you never call identify afterward, those events cannot be joined to a user profile retroactively.
  • Using email as the distinct ID. Emails change. Use your internal user ID (UUID or database primary key) as the Mixpanel distinct ID. Store email as a user profile property instead.
  • Inconsistent event naming across teams. A team of four engineers will naturally drift toward four different conventions without a shared constants file. button_clicked, Button Clicked, and ButtonClicked are three separate events in every Mixpanel report.
  • Calling alias() on every login. Call it exactly once, at the moment of account creation. Calling it on every login merges unrelated profiles and creates data corruption that is very hard to reverse.
  • Skipping the staging project. Running tests in production fills your real data with QA events. Set up a separate Mixpanel project for non-production environments from the start.
  • Not documenting property enumerations. If plan_type can only be "free", "pro", or "enterprise", write that down in your taxonomy doc. Otherwise someone will eventually send "Free" or "ENTERPRISE" and you will end up with fragmented segments.

When To Level Up

The approach above works well for a single product team of one to ten engineers tracking up to 50 or 60 distinct events. You will start feeling real friction at three inflection points.

First, when your event count grows past 60, maintaining accuracy without a formal data governance layer becomes genuinely difficult. Property values drift, naming conventions erode, and you start questioning whether the numbers in Mixpanel actually reflect reality.

Second, when you need to send event data to multiple downstream tools simultaneously, implementing the same events in separate SDKs for Mixpanel, your CRM, and your data warehouse is unsustainable. That is when a customer data platform like RudderStack earns its setup cost.

Third, when your product analytics queries need to join Mixpanel data with your SQL data warehouse for deeper cohort analysis or revenue attribution, you will want tools that sit closer to that layer.

If any of those describe where you are now, browse the data analysis tools category for comparisons of the next tier of solutions. There is also a detailed breakdown at /segment-vs-rudderstack-cdp-comparison/ if the customer data platform path is where you are headed next.

Frequently Asked Questions

Does Mixpanel’s free tier have enough for an early-stage product?
Yes. The Free tier supports 20 million events per month as of 2026, which covers most products below Series A revenue. You get access to funnels, retention analysis, cohorts, and user profiles without any payment.

Should I track events on the frontend or backend?
Both, ideally. Client-side tracking is easier to implement but can be blocked by browser extensions. Backend tracking is more reliable for critical business events like subscription activations or completed purchases. Track high-stakes conversions from the server and use the client side for UI interactions.

What is the difference between an event property and a user profile property?
Event properties describe the specific action: what button was clicked, what page it happened on, what plan was selected. User profile properties describe the person: their subscription tier, their signup date, their total feature usage. Both are useful for different types of analysis.

How do I handle Mixpanel tracking in a mobile app?
Mixpanel provides native SDKs for iOS (Swift and Objective-C) and Android (Kotlin and Java), plus a React Native SDK. The same identification strategy and event naming principles apply directly. The main mobile-specific concern is offline event queuing, which the SDKs handle automatically before syncing when connectivity returns.

Can I fix bad event data retroactively?
No. Once events are sent to Mixpanel, they are immutable. You cannot rename events, change property values, or re-attribute them to a different user after the fact. This is the core reason your taxonomy document matters more than any line of code.

Bottom Line

Getting Mixpanel event tracking right is mostly a planning problem, not a technical one. The SDK installs in minutes. The track() calls are straightforward. What determines whether your data is trustworthy six months from now is the taxonomy doc you write before implementation, the naming convention you enforce across your team, and the identification strategy you set up correctly at signup and login. Follow the nine steps above in order, validate every event in the live stream before shipping, and you will have a data foundation solid enough to build funnels, retention curves, and cohort analyses on with confidence. For a broader look at how Mixpanel stacks up against alternatives for your specific use case, visit the data analysis tools category.