Organizations on a paid event-based plan receive Warehouse Connector as a free add-on when they update or renew their plan. Learn more on our pricing page.
To set up Warehouse Connectors, you must have an admin or owner project role. Learn more about Roles and Permissions.
Connect BigQuery
Navigate to Project Settings → Warehouse Sources. Select BigQuery and follow the instructions to connect it. Note: you only need to do this once.- Your GCP Project ID, which you can find in the URL of Google Cloud Console (
https://console.cloud.google.com/bigquery?project=YOUR_GCP_PROJECT). - Your unique Mixpanel service account ID, which is generated the first time you create a BigQuery connection in the Mixpanel UI (e.g.
project-?????@mixpanel-warehouse-1.iam.gserviceaccount.com). - A new, empty
mixpaneldataset in your BigQuery instance (if you are using Mirror).
-
roles/bigquery.jobUser- Allows Mixpanel to run BigQuery jobs to unload data. -
roles/bigquery.dataVieweron the datasets and/or tables to sync. Gives Mixpanel read-only access to the datasets. -
roles/bigquery.dataOwneron themixpaneldataset. Gives Mixpanel read-write access to themixpaneldataset.
VPC Service Controls
IP allowlists are not supported for BigQuery because Mixpanel’s infrastructure runs on GCP, and inter-project communication in Google Cloud routes through internal Google IPs rather than public IPs. Instead, configure an ingress rule to allow access based on other attributes such as the project or service account. The service account isproject-<your-project-id>@mixpanel-warehouse-1.iam.gserviceaccount.com. The Mixpanel project is 745258754925 for US, 848893383328 for EU, and 1054291822741 for IN. In addition, you may need to configure an egress rule to write data to mixpanel-warehouse-1 project 435324298685.
Mirror Mode
Mirror syncs work by having BigQuery compute which rows have been inserted, modified, or deleted and sending this list of changes to Mixpanel. Mirror takes BigQuery table snapshots and runs queries to compute the change stream between two snapshots. Snapshots are stored in themixpanel dataset created during Connect BigQuery.
Considerations when using Mirror with BigQuery:
- Mirror is not supported on views in BigQuery.
- If two rows in BigQuery are identical across all columns, the checksums Mirror computes for each row will be the same, and Mixpanel will consider them the same row, causing only one copy to appear in Mixpanel. We recommend ensuring that one of your columns is a unique row ID to avoid this.
- The table snapshots managed by Mixpanel are always created to expire after 21 days. This ensures that the snapshots are deleted even if Mixpanel loses access to them unexpectedly. Make sure that the sync does not go longer than 21 days without running, as each sync run needs access to the previous sync run’s snapshot (under normal conditions, Mirror maintains only one snapshot per sync and removes the older run’s snapshot as soon as it has been used by the subsequent sync run).
Trailing NULL values are excluded from the checksum to ensure that adding new columns does not change the checksum of existing rows. For example, if a new column is added to the example table:
Until values are written to the new column:
Handling schema changes when using Mirror with BigQuery:
Adding new, default-NULL columns to Mirror-tracked tables/views is fully supported, as described in the previous section.
JSON Properties in the import setup, as the whole JSON object for that column is used to calculate the checksum for the row, any changes to the JSON object will result in a change to the checksum, even if the change is to add new keys with null values. As such, consider conditional formatting when building the JSON object to only update it when a new non-null value is available for a row.
We recommend avoiding other types of schema changes on large tables. Other schema changes may cause the checksum of every row to change, effectively re-sending the entire table to Mixpanel. For example, if we were to remove the Genre column in the example above, the checksum of every row would be different:
Handling partitioned tables:
When syncing time partitioned or ingestion-time partitioned tables, Mirror will use partition metadata to skip processing partitions that have not changed between sync runs. This will make the computation of the change stream much more efficient on large partitioned tables where only a small percentage of partitions are updated between runs. For example, in a day-partitioned table with two years of data, where only the last five days of data are normally updated, only five partitions’ worth of data will be scanned each time the sync runs.