Mixpanel Insights export to dashboard

Pre-aggregated Mixpanel rows, counted once each.

Export an Insights report from Mixpanel and drop the CSV here. That file is already aggregated: one row per day, per event, per breakdown combination. Total Events adds up cleanly across rows, and Users does not, because the same person appears in several rows and summing them counts them repeatedly. The dashboard makes that distinction on every panel instead of hoping you remember.

Prefer the full explorer? Open the app, or start from the generic dashboard builder.

Events summed, users not

Total Events aggregates freely; Users is shown per row and flagged wherever a total would mislead.

Breakdowns become filters

Platform, Country, Plan and App Version turn into cross-filtering chips rather than string columns.

Placeholder values recognized

Rows written as undefined or a Mixpanel overall marker are labeled rather than treated as real categories.

Local only

Your product's event volumes stay in the tab. No workspace access is granted to anything.

Every row is already a group by

A Mixpanel Insights export is not a list of events. It is the result of a query, flattened. Each row is a combination of Date, Event and whatever properties you put in the breakdown, and the two metric columns are counts for that combination. That makes the file small and fast, and it makes almost every instinct you have about summing columns wrong.

Total Events is the well behaved one. It is a count of occurrences, so adding it across any set of rows gives you a correct total. Users is the trap. It is a distinct count of people who did that event on that day with those property values, and one person using both the iOS app and the web in the same day appears in two rows. Sum them and you have invented a user. Add a second breakdown property and the overcounting multiplies again.

How to export from Mixpanel

Open the Insights report in Mixpanel Sign in at mixpanel.com and pick the project from the selector at the top left. Project matters more than usual here, because development and production projects often carry the same event names with wildly different volumes.
Build the report you want exported Choose your events and metrics, then set the breakdown properties. Each breakdown you add multiplies the row count, so three properties across a quarter can produce a file far larger than you expected.
Set the date range and the time bucket Pick Day rather than Week or Month if you want a daily trend, because a weekly bucket cannot be split back apart afterwards. The date range control sits at the top of the report.
Export as CSV The download icon at the top right of the chart offers CSV. Take the table export rather than a chart image, and note that the export reflects the current chart exactly, including any segment filter applied to it.
Drop the file here Event becomes the primary breakdown, the property columns become filter chips, and the two metric columns are treated according to whether they can be added.

The raw event export from the Mixpanel API is a completely different thing: one JSON line per event, no aggregation, and enormous. This page is written for the Insights CSV, which is what the interface gives you.

Try with sample Mixpanel data (the same columns, 105 rows, no upload needed).

What the dashboard shows

Every panel below is built from a column that is actually in the export, named the way Mixpanel names it.

Event volume over time. Date as the axis with Total Events summed, split by Event, which is the view most product teams actually want and rarely have on one screen.
Platform split. Platform as a breakdown across events, so you can see whether a feature is being used on mobile at all before you invest in the mobile version of it.
Plan tier behavior. Plan against event mix, which is where you find out that the feature you built for enterprise is being used mostly by the free tier.
Country distribution. Country mapped, with event counts rather than user counts, since counts are the additive metric here.
App version adoption. App Version over time as a stacked area, which shows how quickly a release rolls out and how long the long tail of old builds lasts.
Events per user. Total Events over Users within a single row's grain, which is safe, and explicitly not computed across rows, which is not.

Sample header row

Date,Event,Users,Total Events,Platform,Country,Plan,App Version

Reading a pre-aggregated Mixpanel file

Users cannot be summed across rows. Each row is a distinct count for that day, event and property combination. A person active on two platforms is in two rows, and adding them invents people who do not exist.
Adding breakdowns multiplies rows. Four properties with five values each is up to six hundred and twenty five rows per event per day. The file grows fast and the per-row user counts get smaller and less meaningful.
Total Events is the additive one. It counts occurrences, so it sums correctly at every level. When in doubt about a metric in this file, ask whether it counts things or counts people.
Placeholder property values appear. Rows show undefined, empty strings or a Mixpanel overall marker where a property was never set on the event. That is a tracking gap, not a user segment.
Dates use the project timezone. Set once in project settings, and it is not your browser's timezone or UTC unless somebody chose that. A daily boundary in the wrong zone shifts every release-day comparison.
The export mirrors the chart exactly. Segment filters, sampling settings and the time bucket you chose are all baked in. There is nothing in the CSV recording what was applied, so label your downloads.

One question answers most of what you need here: does this column count events or people? Events add up, people do not. Hold that distinction and a Mixpanel export is a compact, fast way to look at product usage without waiting for a chart to load.

Frequently asked questions

Why can I not add up the Users column?

Because each row holds a distinct count for one combination of day, event and property values. Someone who triggers the same event on iOS in the morning and on web in the afternoon is counted once in each row, so summing counts them twice. To get unique users for a wider period, remove the breakdown and widen the date bucket in Mixpanel so it does the deduplication.

What is the difference between Users and Total Events?

Users counts distinct people, Total Events counts occurrences. One power user who runs a report forty times contributes one to Users and forty to Total Events. Dividing the second by the first within a single row gives events per user for that slice, which is often the most revealing number in a product analytics file and the one nobody puts on a dashboard.

Why are some property values blank or undefined?

Because the event was fired without that property attached. That happens when instrumentation on one platform lags behind another, or when a property was added to the tracking plan after some events had already been recorded. It is a signal about your tracking rather than a segment of your users, and it is worth chasing down before you draw conclusions from the rest of the breakdown.

Should I use the Insights export or the raw event export?

Insights for almost everything. It is small, it is already grouped the way you asked, and it loads instantly. The raw event export from the API gives one JSON record per event with every property, which is the right choice for building your own funnel logic or joining against another system, but it can run to gigabytes for a busy product.

Why does my export not match the chart I was looking at?

Check three things. The export honors the current segment filter, which is easy to forget about. It uses the time bucket set on the chart, so a weekly bucket gives you weekly rows regardless of the date range. And the project timezone decides where each day starts, which shifts counts near midnight relative to any other tool you are comparing against.

Does this page connect to my Mixpanel project?

No. There is no integration, no API key and no permission grant. You export the CSV yourself and drop it here, and it is parsed by JavaScript running in your browser tab. Event volumes and plan-tier usage are commercially sensitive, so keeping the file local is the right default, and it also means the page works on a file a colleague sent you.