Frequently Asked Questions

Mixpanel enables you to answer questions about your users and build better products. Mixpanel provide tools to help you track your users and visualize this data using interactive reports. You can import data from your existing database or track data in real time inside your product with our SDKs. You can export your Mixpanel data to your data warehouse or to other destinations.

We provide demo datasets that enables you to explore our product using sample data. To access the demo dataset, register for a free Mixpanel account (opens in a new tab) and then click the top right of the UI and scroll down to the bottom to access the Sample Dataset (or by clicking here (opens in a new tab)).

You can compare between our subscription plans and get an estimate using the plan builder here (opens in a new tab).

There are many factors that can lead to data not appearing in your Mixpanel project. Please consider the following troubleshooting steps:

1. Make sure the token in your init snippet is the same as the project token in your project settings.
2. Make sure that the API request URL matches the Data Residency of your project. Learn more about Data Residency here.
3. Make sure the Mixpanel SDK requests are being triggered. You can confirm this by enabling debug mode. See more troubleshooting tips here.

We support multiple methods for importing historical data and real-time tracking.

1. Sync data from your database using our Warehouse Connector.
2. Use one of our SDKs in your product or server.
3. Leverage our APIs directly to import your data.
4. Upload user profiles using a CSV.

Learn about your options for importing data in the "Data In" section of our docs

Ad-blockers and DNT settings can prevent Mixpanel cookies from loading properly. As a best practice, we recommend server-side tracking since you have control over your server. A proxy is helpful for reducing the likelihood of ad-blockers impacting your client-side tracking.

Mixpanel’s Javascript SDK automatically blocks common web crawlers listed here (opens in a new tab). Bots outside of this list are not blocked by default and will send data like any other users.

If you identify patterns in your bot users, you can implement conditional logic in your codes to detect these bots, and register $ignore: true as a super property. When Mixpanel detects $ignore: true in an event payload, it will drop the event from ingestion.

Learn more about bot traffic management here.

By default, user profile location is updated every time a user is identified or a profile property is set. The location is parsed using the IP address of the request. If you send user updates from a server, it can have the unintended effect of setting your user locations to the location of the server.

You can prevent geolocation updates by setting the IP value of the request payload to 0. Learn more about geolocation in Mixpanel here.

You can override the default geolocation set by Mixpanel by manually defining the geolocation properties, defining the latitude and longitude, or passing your own IP address.

Learn more about geolocation in Mixpanel here.

Mobile attribution is more complex than web tracking due to the way attribution data is stored in mobile devices. For Android, you can use the Play Install Referrer Library (opens in a new tab) to retrieve the referrer. For iOS, you will need to use a mobile attribution partner (opens in a new tab).

Learn more about traffic attribution here.

By default, the Mixpanel Javascript SDK automatically tracks UTM tags from landing page URLs in a first-touch manner. The first UTM tags detected for the user will be set as a profile property and a super property.

Learn more about UTM tracking here.

While Mixpanel’s Javascript SDK automatically tracks UTM tag on a first-touch basis, it does not track UTM tags on a last-touch basis out-of-box. You can copy the codes outlined here to start tracking last-touch UTM tags.

Learn more about UTM tracking here.

Sessions events are virtual events that are dynamically calculated in the front end using existing event data in your project. These virtual events are not a part of your raw data, meaning you do not have to implement any codes to see them and will not count toward your data allowance.

Super properties are event properties that you automatically add to all events that are sent. Once you register a super property, it will be stored in the cookie/local storage and appended to all events tracked by the user moving forward.

This is helpful for adding certain properties that describes the user tracking the event without having to manually define it in each track call. Once the super property is ingested in Mixpanel, it is indistinguishable from a regular event property.

Learn more about super properties here.

Event data are immutable, meaning that they cannot be altered once it is ingested into your project.

You can follow these instructions here to delete unwanted data or use a Lookup Table to enrich your existing data.

You can use our Warehouse Connectors (/docs/tracking-methods/data-warehouse) to sync data from Big Query, Databricks, Redshift, and Snowflake into your Mixpanel project without writing additional codes.

Alternatively, you can export the data from your data warehouse and import them into your Mixpanel project using the Import API (opens in a new tab).

You can leverage our Import API (opens in a new tab) to import historic events in bulk. You can also sync data from your warehouse into Mixpanel using a Warehouse Connector.

CORS errors can occur when the CORS configuration is not setup correctly in your environment, causing Mixpanel requests to be blocked. Mixpanel requires you to send cross-origin HTTP requests (requests sent to a different server than the one hosting your web application), so you need to setup your environment to allow this.

Learn more about CORS errors here (opens in a new tab).

Distinct ID is Mixpanel's identifier used to uniquely track a user in the system. Every event data and profile update sent to Mixpanel should have a distinct_id property associated with it. The Distinct ID value tells Mixpanel which user to attach your events and profile property updates.

If the Distinct ID on two events are two different values, they will be considered as coming from two separate users.

Mixpanel's client-side SDKs automatically generates a UUID upon initialization to represent the user while they are anonymous. Once they are identified with a .identify(<USER_ID>) call, their distinct_id is set to your chosen user ID.

In a server-side environment, your server is responsible for generating the distinct_ids for your users.

Learn more about distinct_ids and identifying users.

In the client-side (web or mobile), Mixpanel's SDK will generate a cookie/local storage upon initialization and store the distinct_id for the user there. If the cookie/local storage is cleared, a new distinct_id will be generated.

In the server-side, your server is responsible for generating and maintaining the distinct_id.

Learn more about ID management and identifying your users in your implementation.

When implementing Mixpanel using a client-side SDK (web or mobile), we recommend calling .identify(<USER_ID>) at registration and login, and .reset() at logout.

Learn more about client-side ID management here.

When implementing Mixpanel using a server-side method, your server is responsible for identity management meaning you will need to generate your own IDs.

Learn more about server-side ID management here.

Mixpanel does not natively support cross-domain tracking. This is because the Distinct ID is stored in the Mixpanel cookie and cookies do not transfer across domains.

Some users have found the workaround outlined here (opens in a new tab) helpful for connecting behavior across multiple domains.

Here is a high-level overview of this process:

1. User lands on website A, and generates a cookie containing a Mixpanel-created distinct_id
2. Use mixpanel.get_distinct_id() (learn more here (opens in a new tab)) to retrieve the distinct_id and save it as a variable
3. Pass this variable as a URL parameter in the URL to website B
4. Your user navigates to the website B, and generates a new cookie containing another Mixpanel-created distinct_id
5. In website B, insert code to extract the website A distinct_id from the landing page URL of website B
6. In website B, call the .identify() method, passing in the Website A distinct_id

The Mixpanel Javascript SDK supports cross-subdomain tracking out-of-box, meaning that your super properties and distinct_id will persist across your subdomains.

Learn more about cross-subdomain cookie persistence here.

Mixpanel's client-side SDKs will generate a different ID for each instance of the an initialized library, meaning that your users will have a separate $distinct_id in the website and mobile app without any identification. To ensure that the same user’s events in both platforms are resolved back to the same user profile in Mixpanel, call .identify(<user_id>) using the same user_id in both platforms.

See an example cross-platform ID management flow [here](Learn more about ID management here (/docs/tracking-methods/id-management/identifying-users-simplified#example-user-flows).

If you are using the Original ID Merge API (check your project API here (opens in a new tab)), our API chooses one of the IDs inside the identity cluster to serve as the canonical distinct_id for the user, meaning that it can be set to your chosen user ID or one of the Mixpanel-generated anonymous ID. This is programmatically selected by Mixpanel and not user-configurable.

You can use any of the distinct_ids inside of the identity cluster for ingestion, but only the canonical distinct_id is used in queries and exports. As a best practice, we recommend setting your chosen user ID as a super property and profile property to make querying easier.

This can occur for projects using the Original ID Merge API when multiple users are sharing one device and .reset() was not called upon logout. Since the previous user’s distinct_id was not cleared from local storage via .reset(), the subsequent user’s user ID is merged into the previous user’s identity cluster when once they sign in and .identify() is called.

To prevent this, follow our best practice for identity management and call identify at registration/login, and reset at logout.

This is not possible under the Simplified ID Merge API since 2 different $user_ids cannot be merged under 1 identity cluster.

This is usually caused by multiple different user IDs being passed for the same user during identification. For example, if you identify the same user using the ID ABC in the web and 123 in the mobile app, they will be considered 2 different users by Mixpanel since we would have no way of knowing they are the same users.

As a best practice, only 1 consistent unique identifier for each user across all platforms during the identification process.

Mixpanel has 4 core reports; Insights, Funnels, Retention, and Flows.

Use an Insights report to visualize your data and explore trends in your events, user profiles, user cohorts, and more using a wide variety of charts.

Use a Funnels report to measure your user’s conversion from a starting event to a goal event.

Use a Retention report to measure the stickiness of your user engagement over time.

Use a Flows report to explore top paths leading up to an event and immediately after events.