I’ve implemented Mixpanel in quite a few Next.js applications over the last few years.
Some were simple marketing sites.
Others were SaaS platforms with hundreds of custom events, user identification, feature flags, and session replay.
The actual installation is straightforward.
The mistakes usually happen afterward.
Things like:
- Initializing Mixpanel multiple times
- Missing page views in SPA navigation
- Using email addresses as Distinct IDs
- Relying entirely on Autocapture
- Tracking every click instead of business events
In this guide, I’ll show the setup I typically use when adding Mixpanel to a new Next.js project.
Step 1: Install the Mixpanel SDK
Start by installing the browser SDK.
npm install mixpanel-browser
or
yarn add mixpanel-browser
Nothing fancy here.
Once it’s installed, resist the temptation to immediately initialize it inside a component.
I’ve inherited projects where Mixpanel initialization was duplicated across several files, which resulted in duplicate events and inconsistent behavior.
Instead, create a dedicated utility file.
Step 2: Store Your Token in an Environment Variable
Create:
.env.local
Add your project token:
NEXT_PUBLIC_MIXPANEL_TOKEN=YOUR_PROJECT_TOKEN
One thing worth mentioning:
Mixpanel runs client-side.
If you forget the:
NEXT_PUBLIC_
prefix, Next.js won’t expose the variable to the browser and Mixpanel won’t initialize.
I’ve seen developers spend 20 minutes debugging this before realizing the environment variable wasn’t accessible.
Step 3: Create a Mixpanel Client File
I usually create:
/lib/mixpanelClient.js
and keep all Mixpanel-related logic there.
Something like:
import mixpanel from ‘mixpanel-browser’;
const MIXPANEL_TOKEN = process.env.NEXT_PUBLIC_MIXPANEL_TOKEN;
export const initMixpanel = () => {
if (!MIXPANEL_TOKEN) {
console.warn(‘Mixpanel token missing’);
return;
}
mixpanel.init(MIXPANEL_TOKEN, {
autocapture: true
});
};
This file eventually becomes the home for:
- Track wrappers
- Identify calls
- User profile updates
- Session replay settings
Keeping everything centralized makes future maintenance much easier.
Step 4: Initialize Mixpanel
The implementation differs slightly depending on whether you’re using Pages Router or App Router.
Pages Router
Initialize Mixpanel inside:
pages/_app.js
using:
useEffect(() => {
initMixpanel();
}, []);
The important thing here is that initialization only happens once.
If you accidentally initialize Mixpanel every time a page renders, you’ll eventually run into strange tracking behavior.
App Router
For App Router projects, I usually create a small provider component.
components/MixpanelProvider.js
Inside:
‘use client’;
useEffect(() => {
initMixpanel();
}, []);
Then wrap the application inside:
app/layout.js
This keeps the implementation clean and avoids duplicate initialization.
Step 5: Don’t Forget Page Views
This is where many Next.js implementations fall short.
Next.js is a Single Page Application.
Users navigate between pages without full page reloads.
If you’re expecting traditional page tracking to work automatically, you’ll probably miss page views.
For Pages Router projects, I usually listen for:
router.events.on(‘routeChangeComplete’)
and send a page view event manually.
For App Router projects, I typically use:
usePathname()
to detect route changes.
The exact implementation isn’t complicated.
The important thing is remembering that route changes exist.
I’ve audited projects where Mixpanel showed far fewer page views than GA4 simply because client-side navigation wasn’t being tracked properly.
Step 6: Verify Autocapture Is Working
The official example enables:
autocapture: true
which is fine.
I generally leave it enabled initially.
After deployment:
- Click buttons
- Navigate pages
- Submit forms
Then open Mixpanel Live View.
You should immediately see activity.
This is usually the quickest way to confirm the SDK is working correctly.
Step 7: Add Identify Early
This is probably the biggest recommendation I can make.
As soon as a user logs in:
mixpanel.identify(user.id);
Don’t wait until:
- Payment
- Subscription
- Feature usage
Identify immediately after authentication.
I’ve seen several implementations where Identify only happened after a purchase.
The result was that the entire trial experience remained anonymous.
Mixpanel knew who paid.
It had no idea what happened before they paid.
Step 8: Track Business Events
Once installation is working, start adding custom events.
Not every click.
Not every hover.
Not every button.
Business events.
Examples:
signup_completed
workspace_created
report_exported
subscription_started
purchase_completed
Those events tell you how users are progressing through your product.
That’s usually where the useful insights come from.
How I Validate Every Mixpanel Implementation
Before calling an implementation complete, I check three places.
Browser Console
Make sure there are no SDK errors.
Network Tab
Look for Mixpanel requests.
You should see successful requests being sent.
Mixpanel Live View
This is the source of truth.
If events appear in Live View, the implementation is working.
If they don’t, stop troubleshooting inside GTM, React, or Next.js and focus on why Mixpanel isn’t receiving data.
Final Thoughts
Installing Mixpanel in Next.js is relatively easy.
Getting useful analytics is the harder part.
The teams that get the most value from Mixpanel aren’t the ones tracking hundreds of events.
They’re usually the teams that:
- Identify users correctly
- Track a small set of meaningful events
- Keep their implementation simple
- Validate data regularly
Start with the basics.
Get clean data flowing.
Then expand into things like Session Replay, Feature Flags, Group Analytics, and advanced user profiles later.