If there’s one thing that determines whether your experiment results are trustworthy, it’s exposure tracking.
Not statistical significance.
Not confidence intervals.
Not sample size.
Exposure tracking.
I’ve reviewed experiments that looked perfectly configured inside Mixpanel but produced completely misleading results because the exposure events were implemented incorrectly.
The experiment wasn’t broken.
The tracking was.
And once exposure tracking is wrong, everything built on top of it becomes unreliable.
Conversion rates.
Lift calculations.
Experiment winners.
All of it.
That’s why I consider exposure events the foundation of any successful experimentation program.
In this guide, we’ll cover what exposure events are, why they’re important, how to implement them correctly, and the most common mistakes that can quietly ruin experiment data.
What Is an Exposure Event?
An exposure event tells Mixpanel:
This user actually saw a specific experiment variant.
That’s it.
It sounds simple.
But it’s one of the most misunderstood concepts in experimentation.
Many teams assume that assigning a user to a variant automatically means they participated in the experiment.
That’s not true.
Consider this example.
A user logs into your application.
Your feature flag platform assigns them to Variant B.
The user immediately closes the browser tab.
Did they actually experience the experiment?
No.
They were assigned.
They were never exposed.
And that’s the difference that matters.
Assignment vs Exposure
Let’s visualize the difference.
Assignment
User Logs In
↓
Feature Flag Assigns Variant
↓
User Leaves
Exposure
User Logs In
↓
Visits Checkout Page
↓
Variant Displayed
↓
Exposure Event Sent
Only the second user should be counted in the experiment.
Why?
Because only the second user actually experienced the variation you’re trying to measure.
This distinction seems small.
In practice, it’s one of the biggest causes of misleading experiment results.
Why Exposure Events Matter
Imagine you’re testing a new checkout flow.
Your experiment is assigned when users sign in.
However:
- 40% never reach checkout
- 20% abandon before seeing the new flow
- 10% bounce immediately
If exposure is tracked at assignment instead of visibility, Mixpanel will include users who never saw the experiment.
Now your analysis includes people who couldn’t possibly be influenced by the change.
Your sample becomes polluted.
And your results become less accurate.
The larger the experiment, the bigger this problem becomes.
How Mixpanel Uses Exposure Events
Mixpanel relies on exposure events to determine:
Who saw the experiment?
and
Which variant did they see?
Without that information, Mixpanel cannot correctly compare user groups.
The workflow typically looks like this:
User Sees Variant
↓
Exposure Event Sent
↓
User Performs Actions
↓
Mixpanel Measures Outcome
Everything starts with exposure.
The Recommended Exposure Event
Mixpanel typically uses the following structure:
mixpanel.track(‘$experiment_started’, {
‘Experiment name’: ‘Checkout Redesign’,
‘Variant name’: ‘Variant A’
});
Variant B:
mixpanel.track(‘$experiment_started’, {
‘Experiment name’: ‘Checkout Redesign’,
‘Variant name’: ‘Variant B’
});
This event tells Mixpanel:
- Which experiment
- Which variant
- Which user
The platform can then compare outcomes between groups.
When Should the Exposure Event Fire?
This is where most implementations go wrong.
The answer is simple:
Fire the exposure event when the user actually sees the experiment.
Not when:
- They sign in
- They are assigned
- The feature flag evaluates
- The page loads in the background
The event should fire when the variation becomes visible.
Example: Checkout Experiment
Correct implementation:
User Opens Checkout
↓
Variant Rendered
↓
Exposure Event Fires
Incorrect implementation:
User Logs In
↓
Variant Assigned
↓
Exposure Event Fires
↓
User Never Opens Checkout
Only the first approach measures real exposure.
Example Using Feature Flags
Let’s assume you’re using a feature flag platform such as:
- LaunchDarkly
- Statsig
- GrowthBook
- Unleash
A simple implementation might look like:
const variant = getExperimentVariant(‘checkout-redesign’);
if (variant === ‘A’) {
mixpanel.track(‘$experiment_started’, {
‘Experiment name’: ‘Checkout Redesign’,
‘Variant name’: ‘Variant A’
});
renderCheckoutA();
}
if (variant === ‘B’) {
mixpanel.track(‘$experiment_started’, {
‘Experiment name’: ‘Checkout Redesign’,
‘Variant name’: ‘Variant B’
});
renderCheckoutB();
}
Notice something important.
The exposure event fires immediately before rendering the experience.
That’s usually the safest pattern.
The user is genuinely about to see the experiment.
Avoid Duplicate Exposure Events
Another common issue is sending exposure events multiple times.
Imagine:
User Opens Page
↓
Exposure Event Fires
↓
Refreshes Page
↓
Exposure Event Fires Again
Now Mixpanel receives multiple exposures for the same user.
Depending on implementation, this can create confusion during analysis.
A better approach is to ensure exposure only fires once per experiment participation.
Example:
if (!hasSeenExperiment()) {
mixpanel.track(‘$experiment_started’, {
‘Experiment name’: ‘Checkout Redesign’,
‘Variant name’: ‘Variant A’
});
markExperimentSeen();
}
This prevents accidental duplication.
Client-Side vs Server-Side Exposure Tracking
Exposure events can be sent from either:
Client Side
Browser
↓
Mixpanel
Server Side
Application Server
↓
Mixpanel
In most cases, I prefer client-side exposure tracking.
Why?
Because the browser knows exactly when the user sees the experience.
The server often doesn’t.
A server may assign variants long before a user ever views the page.
That’s why client-side exposure events tend to be more accurate.
What About Single Page Applications?
Modern applications often use:
- React
- Next.js
- Vue
- Angular
In these environments, page loads don’t always occur.
Experiments may appear after:
Route Change
or
Component Render
Instead of firing exposure events on page load, track them when the experiment component becomes visible.
Example:
useEffect(() => {
mixpanel.track(‘$experiment_started’, {
‘Experiment name’: ‘Pricing Page Test’,
‘Variant name’: ‘Variant A’
});
}, []);
This ensures the event is tied to actual visibility.
Identity Management Matters Too
Exposure tracking becomes much more valuable when users are identified correctly.
Before running experiments, make sure:
mixpanel.identify(user.id);
is already implemented.
Without identification, you may end up with:
Anonymous Exposure
and later:
Authenticated User
which makes long-term analysis more difficult.
This becomes especially important when measuring:
- Revenue
- Retention
- Subscription conversions
- Feature adoption
over time.
Common Exposure Tracking Mistakes
Tracking Assignment Instead of Exposure
Most common mistake.
Track:
User Saw Variant
Not:
User Assigned Variant
Firing Too Early
The experiment isn’t visible yet.
The user hasn’t been exposed.
Don’t fire the event.
Firing Multiple Times
Repeated exposures create noisy data.
Use deduplication logic whenever possible.
Forgetting Variant Information
Bad:
mixpanel.track(‘$experiment_started’);
Good:
mixpanel.track(‘$experiment_started’, {
‘Experiment name’: ‘Checkout Redesign’,
‘Variant name’: ‘Variant A’
});
Mixpanel needs variant information to compare groups.
Inconsistent Naming
Bad:
Checkout Test
checkout-test
Checkout Experiment
Good:
Checkout Redesign
Consistency makes reporting easier later.
How I Validate Exposure Tracking
Before launching any experiment, I run through a simple checklist.
Verify Variant Assignment
Make sure users receive the correct variation.
Verify Exposure Timing
Confirm the event fires only after the experience is visible.
Verify Event Properties
Check:
Experiment name
Variant name
are populated correctly.
Verify Mixpanel Receives Data
Use:
Live View
to confirm events arrive as expected.
Verify User Counts
Confirm the number of exposed users aligns with expectations.
These checks usually catch implementation issues before they affect experiment results.
Final Thoughts
Exposure events are one of the most important parts of experimentation.
Yet they’re often treated as a technical detail.
They shouldn’t be.
Everything in an experiment depends on accurately identifying who actually experienced the change.
If exposure tracking is wrong:
- Conversion analysis becomes unreliable
- Lift calculations become misleading
- Statistical significance loses meaning
Get exposure tracking right, and every experiment becomes more trustworthy.
Get it wrong, and even the most sophisticated analysis won’t save you.
That’s why exposure tracking is always the first thing I review whenever I audit an experimentation setup.