Mixpanel to BigQuery: How to Move Your Data

Moving Mixpanel into BigQuery lets you join product behaviour to everything Mixpanel cannot see: revenue, support cost, contract value, the commercial data that turns an engagement chart into a business question. Mixpanel answers what users did and never what it was worth.

This guide covers the managed path with Airbyte. Two things shape the build, and neither is about BigQuery: Mixpanel's rate limits are low enough to be the defining constraint, and incremental syncs return duplicates by design.

Mixpanel to BigQuery at a glance:

Why move data from Mixpanel to BigQuery?

Two situations account for most of these pipelines.

The first is joining. Mixpanel is excellent at product analytics and knows nothing about revenue, support load or contract value. Questions about which behaviours predict renewal, or what a feature is worth, need event data sitting next to commercial data, and a warehouse is where that happens.

The second is modelling beyond the tool. Custom attribution, cohort definitions your team argues about, anything needing SQL rather than a reporting interface. If your questions are funnels and retention curves, Mixpanel already answers them well and this pipeline earns you little.

What do you need before you start?

Several small settings here have larger consequences than their labels suggest:

A Mixpanel service account and project identifier. Along with your project region, which is either US or EU. Getting the region wrong produces a connection that cannot find your data. The Mixpanel source documentation lists every field.

Your project timezone. Found in your Mixpanel project settings, and the connector defaults to US/Pacific. If your project is set to anything else and you leave the default, events land on the wrong day and your daily figures will not match the Mixpanel interface.

An attribution window you intend to keep. The default is five days. Treat this as a decision rather than something to adjust later, because changing it moves the start date backwards and triggers a re-sync from that earlier point, which on this source is expensive.

A deliberate start date. Left blank the connector replicates from up to one year ago. There is also an optional end date if you want a bounded extract rather than an ongoing feed.

On the BigQuery side you need a project, a dataset and a service account with the BigQuery User and BigQuery Data Editor roles. Set the dataset location to match your revenue and CRM datasets, since joining them is the point.

How do you build a Mixpanel to BigQuery pipeline in Airbyte?

Step 1: Settle timezone and attribution window

Look up your project timezone in Mixpanel and agree an attribution window with whoever analyses this data. Both are cheap to set correctly now and expensive to change later, the timezone because it silently shifts every daily figure and the attribution window because altering it forces a re-sync across a low rate limit.

Step 2: Configure the Mixpanel source

Click Sources in the left navigation, then New Source, and select Mixpanel, following adding a source. Supply the service account secret, project identifier, region, timezone, attribution window and start date. Leave select properties by default enabled so new properties on events and profiles are captured automatically, unless you specifically want to ignore them.

Step 3: Configure the BigQuery destination

Click Destinations, then New Destination, and select BigQuery, following adding a destination. Supply the project, dataset and service account key. Event volumes can be substantial here, so consider Cloud Storage staging rather than the default if your first sync is large.

Step 4: Use a deduplicating sync mode

Click Connections, then New connection, select your streams and choose a deduplicating incremental sync mode. That is not a preference on this connector, because incremental syncs return duplicated records for the state date, and deduplication is what stops those accumulating.

Choose your primary key deliberately too. Mixpanel recommends a combination of insert identifier, event time, event name and distinct identifier, while noting that some rows may lack an insert identifier for certain users. Check your own data before relying on it.

Why are the rate limits the defining constraint?

Because sixty queries per hour is genuinely low, and it applies to both of Mixpanel's API families. The Query API, behind cohorts, engage, funnels, annotations and cohort members, allows five concurrent queries and sixty per hour. The Raw Data Export API behind the export stream allows more concurrency and three per second, and is still capped at sixty per hour.

So a backfill across a long period takes as long as that ceiling allows, whatever else you tune. The date slicing window, which defaults to thirty days per request, is the lever that matters most: a smaller window means more requests against a fixed hourly budget, a larger one means fewer requests each doing more work, at the cost of memory.

The practical advice is to be conservative with your start date, spread heavy streams across separate connections on different schedules rather than syncing everything at once, and treat a slow first sync as arithmetic rather than a fault. The one thing not to do is change the attribution window casually, since that quietly moves the start date back and makes you pay the backfill again.

Why does an incremental sync return duplicates?

Because Mixpanel's API filter is granular to whole days only. The connector stores the date it reached, and on the next run it can only ask for data from that day onwards rather than from the exact moment it stopped. Everything already collected for that day therefore comes back again.

That is a limitation of the API rather than a fault in the pipeline, and it is why the sync mode choice matters. With deduplication the overlap collapses on the way in. Without it your event tables grow a repeated slice every single sync, which is the kind of thing nobody notices until a count is badly wrong.

There is a related setting worth knowing: an export lookback window measured in seconds, which looks back from the last synced timestamp during incremental syncs of the export stream. It exists to avoid missing data when event recording is delayed, and like the attribution window it trades a little more re-reading for a little more completeness.

Frequently asked questions

Why are there duplicate events in my tables?

Mixpanel's API filter is granular to whole days, so an incremental sync re-returns records for the state date. Use a deduplicating sync mode and the overlap collapses.

Why is my sync so slow?

Mixpanel allows sixty queries per hour on both its API families. Large date windows simply take time, so narrow the start date and avoid syncing all streams simultaneously.

Why do my daily numbers not match Mixpanel?

Most likely the project timezone. The connector defaults to US/Pacific, so set it to whatever your Mixpanel project uses or events land on the wrong day.

Can I change the attribution window later?

You can, and it moves the start date backwards and re-syncs from that point. Given the rate limits, treat it as a decision to make once rather than a dial to adjust.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven. You will want BigQuery views joining events to your revenue data, which is where the questions Mixpanel cannot answer get answered.

Get your Mixpanel data into BigQuery

Set the project timezone and attribution window correctly the first time, use a deduplicating sync mode because duplicates are expected rather than exceptional, be conservative with the start date given sixty queries an hour, and spread heavy streams across separate connections rather than running everything together.

Airbyte's connector catalog includes 600+ pre-built connectors, so product events can sit beside the revenue and support data that explain them. For the same source in a columnar engine, see Mixpanel to ClickHouse, and for another product analytics source in the same warehouse, PostHog to BigQuery.

Start syncing now →