Get started with a free trial today
Already have an account? Sign in
Stitch’s Mixpanel integration replicates data using theMixpanel Event Export API and Mixpanel Query API. Refer to theSchema section for a list of objects available for replication.
A high-level look at Stitch's Mixpanel (v1) integration, including release status, useful links, and the features supported in Stitch.
| STITCH | |||
| Release status | Released on June 2, 2020 | Supported by | |
| Stitch plan | Standard | API availability | Available |
| Singer GitHub repository | |||
| REPLICATION SETTINGS | |||
| Anchor Scheduling | Supported | Advanced Scheduling | Supported |
| Table-level reset | Unsupported | Configurable Replication Methods | Unsupported |
| DATA SELECTION | |||
| Table selection | Supported | Column selection | Supported |
| Select all | Supported | ||
| TRANSPARENCY | |||
| Extraction Logs | Supported | Loading Reports | Supported |
To set up Mixpanel in Stitch, you need:
Admin privileges. These are required to retrieve your API secret in your Mixpanel account.
On the Stitch Dashboard page, click theAdd Integration button.
Click theMixpanel icon.
Enter a name for the integration. This is the name that will display on the Stitch Dashboard for the integration; it’ll also be used to create the schema in your destination.
For example, the name “Stitch Mixpanel” would create a schema calledstitch_mixpanel in the destination.Note: Schema names cannot be changed after you save the integration.
In theDate Window Size field, enter the number of days desired for a date looping window for theexports,funnels, andrevenues tables.
Date looping will return records whosefrom_date andto_date fall between the number of days in the defined window size.
Note: If your project has large volumes of events, you may want to set the number of days to14,7, or even to1 or2 days.
Page Viewed, Signed Up.events andengage tables, check theSelect Properties By Default box. Otherwise, new properties will be ignored.The Sync Historical Data setting defines the starting date for your Mixpanel integration. This means that dataequal to or newer than this date will be replicated to your data warehouse.
For a detailed look at historical replication jobs, check out theSyncing Historical SaaS Data guide.
Note: Mixpanel limits the number of days historical data may be accessed, depending on your Mixpanel plan. If you select a Start Date greater than what your Mixpanel account has access to, Stitch may encounter issues with Mixpanel’s API.
For example: If you have a Starter Free Mixpanel plan, you have access to 90 days of historical data (as of 06/5/2020). If you select a Start Date greater than 90 days, Mixpanel’s API may return an error.
Additionally, the Start Date must be less than or equal to365 days. If a Start Date greater than 365 days is selected, Stitch will reset the Start Date to 365 days during Extraction.
Refer toMixpanel’s documentation for more info and to check your Mixpanel account’s historical data access limit.
In theReplication Frequency section, you’ll create the integration’sreplication schedule. An integration’s replication schedule determines how often Stitch runs a replication job, and the time that job begins.
Mixpanel integrations support the following replication scheduling methods:
Advanced Scheduling using Cron (Advanced or Premium plans only)
To keep your row usage low, consider setting the integration to replicate less frequently. See theUnderstanding and Reducing Your Row Usage guide for tips on reducing your usage.
The last step is to select the tables and columns you want to replicate.Learn about the available tables for this integration.
Note: If a replication job is currently in progress, new selections won’t be used until the next job starts.
For Mixpanel integrations, you can select:
Individual tables and columns
All tables and columns
Click the tabs to view instructions for each selection method.
To track a table, click thecheckbox next to the table’s name. A blue checkmark means the table is set to replicate.
To track a column, click thecheckbox next to the column’s name. A blue checkmark means the column is set to replicate.
Click theTables to Replicate tab.
In the menu that displays, clickTrack all Tables and Fields:

After you finish setting up Mixpanel, itsSync Status may show asPending on either the Stitch Dashboard or in the Integration Details page.
For a new integration, aPending status indicates that Stitch is in the process of scheduling the initial replication job for the integration.This may take some time to complete.
Initial replication jobs with Anchor Scheduling
If using Anchor Scheduling, an initial replication job may not kick off immediately. This depends on the selected Replication Frequency and Anchor Time. Refer to theAnchor Scheduling documentation for more information.
The first seven days of replication, beginning when data is first replicated, are free. Rows replicated from the new integration during this time won’t count towards your quota. Stitch offers this as a way of testing new integrations, measuring usage, and ensuring historical data volumes don’t quickly consume your quota.
When Stitch runs a replication job for Mixpanel, it will use the value of theAttribution Window setting to query for and extract data for tables using Key-based Incremental Replication. An attribution window is a period of time for attributing results to ads and the lookback period after those actions occur during which ad results are counted.
For example: If set to5 days, Stitch will replicate the past five days’ worth of data for applicable tables every time a replication job runs. While Stitch replicates data in this way to account for updates to records made during the attribution window, it can have asubstantial impact on your overall row usage.
Note: If the beginning of the attribution window is earlier than the selected Start Date, the replication will start from the Start Date and no data before that date will be fetched. For example, if you set the Start Date to five days ago and the attribution window to ten days, only the past five days’ worth of data will be replicated.
In the sections below are examples of how attribution windows impact how Stitch extracts data during historical and ongoing replication jobs.
For historical and full re-replications of Mixpanel data, Stitch will query for and extract data newer than or equal to the date defined in theStart Date field in the Integration Settings page.
Example
During the initial set up, theStart Date field is defined as07/03/2017, or2017-07-03 00:00:00.
If you were to write a SQL query using this date for therevenue table, it might look like this:
SELECT*FROMmixpanel.revenueWHEREdate>='2017-07-03 00:00:00'/* Start Date */ORDERBYdateFor ongoing replication jobs, Stitch will query for and extract data using the last saved maximum value in the table’s Replication Key column and the Attribution Window for the table.
Note: This applies to every replication job that takes place after the historical replication job.
Example
The last maximum saved Replication Key value for therevenue table is2017-10-01 00:00:00.
To account for the Attribution Window of 5 days, we’d subtract this from the last maximum saved Replication Key value:
2017-10-01 00:00:00 - 5 days = 2017-09-26 00:00:00
In this case, Stitch would query for and extract data that is newer than or equal to2017-09-26 00:00:00 and older than or equal to2017-10-01 00:00:00.
If this were a SQL query, it might look like this:
SELECT*FROMrevenueWHEREdate>='2017-09-26 00:00:00'/* max Replication Key value - Attribution Window */ANDdate<='2017-10-01 00:00:00'/* max Replication Key value from previous job */ORDERBYdateDue to the Attribution Window, a high Replication Frequency may not be necessary. Because Stitch will replicate data from the pastN days during every replication job, recent data will be re-replicated and count towards your row quota.
To reduce your row usage and replicating redundant data, consider setting the integration to replicate less frequently. For example: every 12 or 24 hours.
The Stitch Mixpanel integration is not able to discover fields marked as hidden in your Mixpanel account. To ensure the fields you want replicated will be available in Stitch, double-check that they aren’t hidden in your Mixpanel account.
Mixpanel free plan
Theengage andexport tables are not available if you are using the free Mixpanel plan.
Schemas and versioning
Schemas and naming conventions can change from version to version, so we recommend verifying your integration’s version before continuing.
The schema and info displayed below is forversion 1 of this integration.
This is the latest version of the Mixpanel integration.
Table and column names in your destination
Depending on your destination, table and column names may not appear as they are outlined below.
For example: Object names are lowercased in Redshift (CusTomERs >customers), while case is maintained in PostgreSQL destinations (CusTomERs >CusTomERs). Refer to theLoading Guide for your destination for more info.
Theannotations table contains info about annotations.
Full Table | |
Primary Key | date |
| Useful links |
| Join annotations with | on |
|---|---|
| cohorts | annotations.project_id = cohorts.project_id |
date DATE-TIME |
description STRING |
id INTEGER |
project_id INTEGER |
Thecohort_members table contains info about the cohorts user profiles belong to.
Full Table | |
Primary Keys | cohort_id distinct_id |
| Useful links |
| Join cohort_members with | on |
|---|---|
| cohorts | cohort_members.cohort_id = cohorts.id |
cohort_id INTEGER |
distinct_id STRING |
Thecohorts table contains info about the cohorts in a Mixpanel project.
Full Table | |
Primary Key | id |
| Useful links |
| Join cohorts with | on |
|---|---|
| cohort_members | cohorts.id = cohort_members.cohort_id |
| annotations | cohorts.project_id = annotations.project_id |
count INTEGER |
created DATE-TIME |
description STRING |
id INTEGER |
is_visible INTEGER |
name STRING |
project_id INTEGER |
Theengage table contains info about user profiles.
The schema for this table is dynamic, meaning that the columns Stitch detects are dependent upon the properties provided upon upload in Mixpanel. For every property available in Mixpanel forengage records, Stitch will display a column in the integration’sTables to Replicate tab.
Full Table | |
Primary Key | distinct_id |
| Useful links |
distinct_id STRING |
Theexport table contains “raw data dumps” of tracked events. The API endpoint for EU region servers will return a200 terminated early error code.
The schema for this table is dynamic, meaning that the columns Stitch detects are dependent upon the properties provided upon upload in Mixpanel. For every property available in Mixpanel forexport records, Stitch will display a column in the integration’sTables to Replicate tab.
This table is replicated using theAttribution Window value defined in the integration’s settings page. Refer to theReplication section for more info.
As Stitch doesn’t use a Primary Key for this table, data will be loaded usingAppend-Only loading. This means you may see duplicate records in your destination, which requires a querying strategy that selects the latest version of each record.
Stitch takes this approach because it’s possible to track events without adistinct_id. In Mixpanel,distinct_idis used to identify a unique user:
Mixpanel’s client-side tracking libraries automatically assign a distinct_id to a user when they first visit a website or an application that has Mixpanel installed. Distinct_id should not contain any special characters such as forward slashes, as it will break the URL.Distinct_ids can and often should be sent in server-side implementations as well.
In order for Stitch to replicate records’distinct_id attributes, your server-side Mixpanel implementation must send them with tracked events. If the server-side implementation doesn’t do this, this attribute will benull.
Previous versions of Stitch’s Mixpanel integration useddistinct_id as part of a composite Primary Key for this table. However, due to the possibility of this attribute beingnull, Stitch no longer uses a Primary Key for this table, asnull values in Primary Key columns will prevent successful Extraction.
When working withexports data in your destination, you’ll need to use a querying strategy that accounts for the Append-Only loading used by this table. We recommend using the following columns to de-duplicate records, along with the approach outlined in theQuerying Append-Only tables guide:
distinct_ideventtimeKey-based Incremental | |
Append-Only | |
Replication Key | time |
| Useful links |
dataset STRING |
distinct_id STRING |
event STRING |
labels ARRAY |
sampling_factor INTEGER |
time DATE-TIME |
Thefunnels table contains data about your Mixpanel funnels, segmented by funnel and day.
Note: This table is replicated using theAttribution Window value defined in the integration’s settings page. Refer to theReplication section for more info.
Key-based Incremental | |
Primary Keys | funnel_id date |
Replication Key | date |
| Useful links |
analysis OBJECT
| |||||||||||||||
date DATE | |||||||||||||||
datetime DATE-TIME | |||||||||||||||
funnel_id INTEGER | |||||||||||||||
name STRING | |||||||||||||||
steps ARRAY
|
Therevenue table contains info about revenue, segmented by day. The API endpoint for EU region servers will return a400 bad requests (Timeout Error) code.
Note: This table is replicated using theAttribution Window value defined in the integration’s settings page. Refer to theReplication section for more info.
Key-based Incremental | |
Primary Key | date |
Replication Key | date |
| Useful links |
amount NUMBER |
count INTEGER |
date DATE |
datetime DATE-TIME |
paid_count INTEGER |
| Related | Troubleshooting |
Did this article help? If you have questions or feedback, feel free tosubmit a pull request with your suggestions,open an issue on GitHub, orreach out to us.