How to Test Mixpanel Events with Playwright: Complete 2026 Guide

1. Why Testing Mixpanel Events Is Harder Than It Looks

Mixpanel's JavaScript SDK does not fire HTTP requests the moment you call mixpanel.track(). Instead, it enqueues events into an internal buffer and flushes them in batches, typically every 50 milliseconds or when the queue reaches a size threshold. This batching behavior means a naive test that checks network requests immediately after a user action will find nothing. The event is sitting in memory, waiting for the next flush cycle.

The complexity extends beyond batching. Mixpanel uses adistinct_id to link events to users, and this identity changes at critical moments. Before login, the SDK generates an anonymous UUID. After you callmixpanel.identify(userId), the SDK merges the anonymous profile with the authenticated one. If your test does not validate that merge, you will not catch the scenario where pre-login events get orphaned on the anonymous profile, creating ghost users in your funnel reports.

Super properties add another layer. These are key/value pairs registered once viamixpanel.register() that get automatically attached to every subsequent track call. They persist in localStorage across page loads. If your SPA clears localStorage during logout but does not re-register super properties after login, every event after the second login will be missing critical context like plan_tier orcompany_name. These bugs only surface weeks later when analysts notice gaps in their breakdown reports.

Group analytics compounds the problem for B2B SaaS applications. Mixpanel lets you associate events with a group (a company, a workspace, a team) by callingmixpanel.set_group(). If the group key is not set before the first tracked event after login, those events cannot be retroactively grouped. The data is lost from group-level reports permanently. Finally, Mixpanel's debug flag (debug: true in init) changes the API endpoint from /track to/track?verbose=1, which returns detailed error messages instead of a bare1. Tests written against debug mode will not catch production payload issues where the response format differs.

A thorough Mixpanel test suite must intercept queued network requests, decode base64 payloads, validate property schemas, and verify identity resolution across the anonymous-to-authenticated transition. The sections below walk through each scenario with runnable Playwright TypeScript.

2. Setting Up a Reliable Test Environment

The goal is to intercept all Mixpanel requests without actually sending data to the Mixpanel API. You want your tests to be hermetic: no dependency on Mixpanel's servers, no risk of polluting production data, and no flakiness from network latency. The approach is to use Playwright's route interception to capture every request to api-js.mixpanel.com andapi.mixpanel.com, decode the payload, and store it for assertions.

Environment Variables

Mixpanel Route Interceptor Utility

This helper intercepts all Mixpanel API calls, decodes the base64 payloads, and collects them into an array your tests can query. It handles both the /track and/engage endpoints.

Playwright Configuration

Mixpanel's SDK initializes early in the page lifecycle. Set up route interception before navigating to the page under test, so you capture initialization events like$mp_web_page_view if autotrack is enabled.

9. Common Pitfalls That Silently Corrupt Your Analytics

Mixpanel tracking bugs are uniquely insidious because they do not crash your application or fail visibly. The UI works perfectly while the underlying analytics data drifts further from reality. These are the most common failures reported in Mixpanel's community forums and GitHub issues.

Pitfall Deep Dive: The Identify Before Track Problem

This is the number one cause of duplicate user profiles in Mixpanel. The SDK's identity merge depends on having anonymous events to link. If your application's initialization code callsmixpanel.identify(userId)in a useEffect that runs before any page view or interaction events are tracked, the$identify event has no$anon_distinct_id to merge. The result: a clean authenticated profile with zero pre-login funnel data, and an orphaned anonymous profile that inflates your unique user count.

Pitfall Deep Dive: Super Property Amnesia After Logout

Many applications call localStorage.clear()or mixpanel.reset() during logout to clean up user state. Both of these operations destroy the super properties stored by the Mixpanel SDK. Thereset() call is particularly aggressive: it generates a new anonymousdistinct_id, clears all super properties, and removes the Mixpanel cookie. If your application logs back in and does not callregister() again, every event in the new session will be missingplan_tier,company_name, and any other super properties your analysts depend on.

10. Writing These Scenarios in Plain English with Assrt

The Playwright tests above are thorough but verbose. Each scenario requires importing the interceptor, attaching it, managing timeouts, and writing multiple assertions against decoded payloads. With Assrt, you describe the same scenario in plain English and let the engine handle the Mixpanel request interception, payload decoding, and property validation automatically.

Here is the identity merge scenario from Section 4 expressed as an Assrt test file. Notice how the intent is immediately clear to anyone on the team, including product managers and analysts who need to verify that tracking matches their event taxonomy.

The Assrt file is 24 lines compared to 40+ lines of TypeScript for the equivalent Playwright test. More importantly, it reads like a specification document. When your product team updates the event taxonomy (renaming "Project Created" to "Project Initialized", for example), anyone can update the Assrt file without needing to understand route interception or base64 decoding.

Assrt handles the hard parts automatically: attaching the route interceptor before page load, waiting for batch flushes, decoding base64 payloads, and matching properties with flexible assertions. You focus on what to verify, not how to verify it.

import { test, expect } from '@playwright/test';
import { MixpanelInterceptor } from '../helpers/mixpanel-interceptor';

test('identify merges anonymous events', async ({ page }) => {
  const mp = new MixpanelInterceptor();
  await mp.attach(page);
  await page.goto('/');
  await page.getByRole('link', { name: 'Features' }).click();
  await page.waitForTimeout(200);
  const anonEvents = mp.findEvents('$mp_web_page_view');
  const anonId = anonEvents[0].properties.distinct_id;
  await page.goto('/login');
  await page.getByLabel('Email').fill('e2e-test@yourapp.com');
  await page.getByLabel('Password').fill('SuperSecret123!');
  await page.getByRole('button', { name: 'Sign In' }).click();
  await page.waitForURL('/dashboard');
  await page.waitForTimeout(500);
  const identifyEvents = mp.findEvents('$identify');
  expect(identifyEvents[0].properties.$anon_distinct_id).toBe(anonId);
  expect(identifyEvents[0].properties.$identified_id).toBe('user_12345');
  await page.getByRole('button', { name: 'Create Project' }).click();
  await page.waitForTimeout(200);
  const events = mp.findEvents('Project Created');
  expect(events[0].properties.distinct_id).toBe('user_12345');
  expect(events[0].properties.plan_tier).toBe('pro');
});