Frequently Asked Questions

Mixpanel is a product analytics platform that helps businesses track user interactions with digital products such as websites and mobile apps. It provides detailed insights into user behavior, allowing teams to analyze usage patterns, measure engagement, and optimize the user experience. With features like event tracking, funnel analysis, cohort reports, and A/B testing, Mixpanel enables data-driven decision-making to improve product performance and growth.

Mixpanel offers a variety of ingestion SDKs and import/export integrations to make it easy to collect and use product analytics data across platforms.

Learn more about Mixpanel and send your first event.

Mixpanel offers sample datasets representing a range of use cases (including B2B, AI, and e-commerce) to help you learn the platform’s features effectively. To access these datasets, create a Mixpanel account, log in, then select Mixpanel Demo Sample Datasets from the project menu dropdown.

You may also book a demo with our team.

Mixpanel offers flexible pricing through the Free, Growth, and Enterprise plans. You can explore the features available in each plan on our pricing page. The page includes a Plan Builder tool that helps you estimate your cost based on projected data usage.

There are several common reasons why you might not see any data in your Mixpanel project:

1. Incorrect Project Token - Using the wrong project token in your initialization code will lead to your tracked data not arriving to your project. Always verify that the token matches the token shown in your project settings.
2. Mismatched Data Residency - If your Mixpanel project data residency setting does not match the API endpoint you are sending data to, your data will not be ingested. If your project data residency is set to EU or India, make sure to route your data to the correct API server URL in your initialization code. Learn more about EU Residency and India Residency.
3. Implementation Issues - Implementation errors can prevent Mixpanel SDK methods from triggering as expected. To help identify and resolve these issues during development, enable debug mode in your SDK. This will provide logs of the Mixpanel requests being triggered, along with the associated payloads.

Learn more about debugging your implementation.

You can use any Mixpanel SDKs to track and send events directly from your applications, both on the client and server side.

Mixpanel supports direct imports from data warehouses such as Snowflake, BigQuery, Redshift, and Databricks through Warehouse Connectors. You can set up recurring syncs to keep Mixpanel in sync with your warehouse data.

If you use a CDP like Segment or Rudderstack, you can add Mixpanel as a downstream destination to receive your data. Learn more about data ingestion integrations.

Ad-blockers can significantly affect Mixpanel tracking, particularly when using the client-side JavaScript SDK. These blockers and privacy extensions often target known analytics endpoints (such as Mixpanel’s), preventing events from being sent and recorded. As a result, users with ad blockers enabled may not be tracked in Mixpanel, leading to discrepancies between backend data and Mixpanel reports. Depending on your audience and the types of blockers in use, an estimated 30% or more of client-side events may be impacted.

To reduce the impact of ad-blockers, use server-side tracking for critical events (server-side requests are not subject to ad blocking) and implement a proxy server to route client-side requests through your own domain (making them less likely to be blocked).

Read more about the differences between client-side and server-side tracking.

By default, Mixpanel’s JavaScript SDK automatically blocks traffic from known web crawlers, as listed here. All other traffic is processed normally and ingested into your project.

To further control bot traffic, you can implement custom filtering in your code. This involves identifying common patterns among your bots and setting the super property $ignore: true to exclude those events at ingestion.

Learn more about managing bot traffic.

If all user profiles in Mixpanel display the same location, it is likely because you are sending data through a server-side implementation or a CDP (like Segment or Rudderstack). In these cases, Mixpanel uses the server’s IP address for geolocation instead of the end user’s, resulting in all users being assigned the same location (such as Boardman, Oregon for Segment or Ashburn, Virginia for Rudderstack).

By default, Mixpanel updates a user’s geolocation each time a user property is created or modified. If you don’t explicitly include the user’s real IP address in your payload, Mixpanel defaults to the server’s IP.

To resolve this, you can:

• Pass the actual client IP using the $ip in your payload,
• Manually set geolocation properties like $city, $region, and $country_code, or
• Set $ip to 0 to prevent Mixpanel from updating the geolocation entirely.

Learn more about geolocation and other server-side implementation best practices.

By default, Mixpanel determines the geolocation of users and events based on the IP address of the request. When using client-side tracking, this reflects the end user’s location. With server-side tracking, it reflects the server’s location.

To override the default geolocation set by Mixpanel, you can:

• Pass the actual client IP using the $ip in your payload
• Manually set geolocation properties such as $city, $region, and $country_code
• Specify the exact coordinates by setting the $latitude and $longitude properties in your payload

Learn more about geolocation.

Tracking downloads and installs from the Apple App Store and Google Play Store in Mixpanel cannot be done directly, as neither app store provides this data to Mixpanel out-of-the-box.

For Google Play Store (Android): You can use the Play Install Referrer Library to retrieve the referrer URL when the app is first opened. This allows you to capture some attribution data (such as campaign source) and send it to Mixpanel as event properties. However, this only works for a subset of attribution data and does not provide the total number of downloads—only installs where the app is opened and the referrer is available

For Apple App Store (iOS): The App Store strips attribution data before the user downloads the app, so you cannot directly track the source or count of installs via Mixpanel. To track channel attribution on iOS, you need to use a mobile attribution partner (such as Adjust, AppsFlyer, or Branch). These partners can capture install and attribution data and send it to Mixpanel for analysis.

Learn more about Traffic Attribution and our attribution integration partners.

To track first-touch UTM tags in Mixpanel, you can rely on the default behavior of the Mixpanel JavaScript SDK. When a user visits your site for the first time with UTM parameters in the URL, the SDK will:

• Automatically capture the UTM parameters from the landing page URL (such as utm_source, utm_medium, utm_campaign, etc.) and add them to events fired from that page load.
• Store these first-seen UTM parameters as user profile properties prefixed with initial_ (e.g., initial_utm_source, initial_utm_campaign). These properties represent the first-touch attribution and will persist on the user profile for future reference.

No extra configuration is needed for first-touch tracking if you are using the default SDK settings and identifying users normally. The UTM parameters will be persisted as super properties in a last-touch manner and the initial values will be set on the user profile automatically in a first-touch manner.

If you are using a server-side implementation or a third-party integration, you must manually set these UTM properties.

We recommend disabling UTM persistence for compatibility with the Attribution feature. To disable UTM persistence, set stop_utm_persistence: true when initializing the SDK.

Learn more about UTM tracking.

By default, UTM parameters are persisted as super properties in all events and is updated when a new UTM parameter is detected in subsequent page loads (which aligns with last-touch attribution).

We recommend disabling UTM persistence for compatibility with the Attribution feature. To disable UTM persistence, set stop_utm_persistence: true when initializing the SDK.

Learn more about UTM tracking here.

Session Start and Session End events are automatically computed based on the events already in your project. These are virtual events; they are not sent from your application but are generated by Mixpanel at query time within the UI and reports. These virtual events do not count toward your data allowance.

The definition of a session, when it starts and ends, depends on your project’s session settings, which may be timeout-based, event-based, or property-based. You can use these virtual events in reports such as Insights, Funnels, and Flows. However, they do not appear in your raw events list and cannot be exported via the API, as they are not stored as actual events in your data store.

Learn more about Sessions.

Super properties in Mixpanel are event properties that you define once and are automatically included with every event tracked from the client-side SDKs. They are stored in the user’s local storage or cookie, so you don’t need to manually add them to each event. This is useful for properties that provide important context across multiple events, such as user type, app version, or campaign source.

You can register super properties with the JavaScript SDK, Android SDK, Swift SDK, iOS SDK, and the React SDK.

You cannot directly edit the raw event data that has already been ingested into your Mixpanel project; events are immutable once received (unless imported via a mirror sync warehouse connector. However, you can hide unwanted events from appearing in your reports and delete unwanted data.

Learn more about the Lexicon, Data Deletion, and Warehouse Connectors.

You can send data from your data warehouse to Mixpanel using Warehouse Connectors, which offer native integrations with Redshift, Snowflake, BigQuery, and Databricks. This codeless setup allows you to configure recurring syncs, ensuring Mixpanel stays up to date with your warehouse data.

To do an initial import of data into Mixpanel, there are several methods available:

1. SDKs (Software Development Kits): You can use Mixpanel’s SDKs to send data directly from your application. This is a common approach for ongoing event tracking, but it can also be used for initial imports if you replay historical events through the SDKs.

2. Import API: Mixpanel provides an Import API that allows you to send data directly to Mixpanel. This method is managed by your team, and you can automate API calls to send data as needed.

3. Data Warehouse Connector(Add-on): Mixpanel offers a data warehouse connector as an add-on for organizations on the Enterprise plan, which allows you to point Mixpanel to your data warehouse table, and Mixpanel manages the sync and cadence of data import. This is a managed solution and is easier for teams that want Mixpanel to handle the process. Contact your account manager to learn more about the pricing.

Learn more about the pricing for historical events on the Billing & Pricing doc](/docs/pricing#is-old-event-data-billed-when-imported-to-mixpanel).

CORS (Cross-Origin Resource Sharing) errors appear in your console when Mixpanel requests from your website are blocked by the browser’s security policy. This typically happens because the Mixpanel server response does not include the necessary CORS headers (like Access-Control-Allow-Origin) to allow your domain to access the resource.

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. Use browser developer tools to inspect the failed request and see which headers are missing or mismatched.

Learn more about CORS errors.

You can use Mixpanel’s SDKs to track and send events directly from your applications, both on the client and server side.

Mixpanel supports direct imports from data warehouses such as Snowflake, BigQuery, Redshift, and Databricks through Warehouse Connectors. You can set up recurring syncs to keep Mixpanel in sync with your warehouse data.

If you use a CDP like Segment or Rudderstack, you can add Mixpanel as a downstream destination to receive your data.

Learn more about Tracking Methods.

Mixpanel is flexible and can integrate with most data models or databases, either directly or through data transformation and import methods.

If your data is stored in a data warehouse (such as BigQuery, Redshift, Snowflake, or Databricks), Mixpanel’s Warehouse Connectors allow you to sync tables or views from your warehouse into Mixpanel. This integration is codeless and can keep your Mixpanel data in sync with your backend systems

If you are using a CDP such as Segment or Rudderstack, you can set Mixpanel as a downstream destination to stream data from your existing sources.

Learn more about Tracking Methods.

Mixpanel does not store personally identifiable information (PII) unless you explicitly choose to track it. You have full control over the data you send and should avoid including raw PII (such as names, email addresses, or phone numbers) unless absolutely necessary.

Mixpanel also provides tools to help you honor user privacy, including options to support opt-out requests and manage data responsibly. Learn more about how to protect user data.

With Data Views, you can create filtered views of your project data and assign access to specific teams or users.

Additionally, Data Classification lets you mark certain properties as classified, restricting visibility to only authorized users within your project.

The best practice for sending both client-side and server-side events in Mixpanel is to use a hybrid approach:

• **Track critical business events (**such as purchases, sign-ups, and revenue events) on the server side. This ensures greater accuracy and reliability, as server-side events are not impacted by ad blockers, network interruptions, or client-side manipulation. Use Mixpanel’s server-side SDKs or direct API ingestion for this purpose.
• **Track user interactions and UI events (**such as button clicks and page views) on the client side. These events reflect real-time user behavior that only occurs in the browser or app and are best captured using Mixpanel’s client-side SDKs.

Learn more about choosing the right tracking method.

To ensure your Mixpanel data is accurate and your implementation is correct, follow these best practices:

1. Use Separate Development and Production Projects: Always set up at least two Mixpanel projects, one for development and one for production. Implement and test all tracking in the development project first. This prevents test or incorrect data from polluting your production analytics. Learn more about setting up developer environments.
2. Validate Events and Properties: Use Mixpanel’s Events view to confirm that events are arriving as expected. Manually trigger events and search for them using user-level identifiers (like distinct_id). Inspect event properties for correctness, data type, and naming conventions (Mixpanel is case sensitive). Learn more about debugging your implementation.
3. Iterate and Update Tracking Plan: After each product update or when adding new events, update your tracking plan, get sign-off from a data governance owner, and repeat the QA process in the development project before deploying to production. Learn more about creating a tracking plan and establishing data standards.

Mixpanel does not require any identifying information about users. You can generate a hash of a unique user ID (such as your internal user ID) and use that hash as the user’s ID when calling the .identify() method in the SDKs. This way, the user cannot be traced back to their real identity, but you can still analyze their behavior in aggregate. The hash should only be reversible by you, not by Mixpanel or anyone else.

To anonymize a user who has already been tracked, first export all data associated with that user. Then, delete the user’s data using Mixpanel’s GDPR-compliant deletion methods. After reviewing the exported data, remove any personally identifiable information (PII), and reimport the sanitized data as needed once the deletion has been fully processed.

Learn more about anonymizing users and submitting GDPR requests.

A distinct_id in Mixpanel is the unique identifier used to track a user across events and profile updates. This ID allows Mixpanel to attribute actions and properties to the correct user, ensuring accurate analytics and reporting.

When two events have the same distinct_id, they are considered to be performed by the same unique user. If two events have different distinct_ids, they are treated as coming from different users.

Learn more about identity management.

On the client side, the Mixpanel SDK automatically generates a random, unique distinct_id for anonymous users. When a user registers or logs in, you can assign a known user ID (such as a database ID) by calling the identify method in the SDK. The ID is then stored in the cookie or local storage for persistence.

On the server side, you are responsible for generating both anonymous and known user IDs, as well as ensuring their consistency and persistence across events.

Learn more about identifying users.

On the client side, the distinct_id is stored in the end user’s device using cookies or local storage. If the user clears this data (or you call reset()), the SDK generates a new distinct_id.

On the server side, your server is responsible for generating, maintaining, and persisting the distinct_id across events to ensure consistent user tracking.

Learn more about identifying users.

As a best practice for client-side identity management:

1. Call identify() during both registration and login, using a consistent user ID in each case to ensure proper user identification.
2. Call reset() on logout to clear cookies or local storage and generate a new ID. This prevents unintended merging of data from multiple users sharing the same device.
3. Include your user ID as both a super property and a user property. Doing so makes it easier to query and export data.

Learn more about identifying users.

In a server-side implementation, you must generate and manage user IDs yourself. When a user is anonymous, generate a unique Anonymous ID (such as a UUID) and store it.

If your project is using the Simplified API: For anonymous events, set the $device_id event property to this Anonymous ID. When the user is authenticated and you know their User ID, include both $user_id (your internal user ID) and $device_id (the original Anonymous ID) in all events sent from the server. Mixpanel will merge a pair of $user_id and $device_id the first time they are received together on an event.

If your project is using the Original API: For anonymous events, set the distinct_id event property to this Anonymous ID. When the user is authenticated and you know their User ID, send a $identify event containing both the anonymous ID and the user ID to merge them together.

Learn more about the difference between the two identity management APIs.

To set up cross-domain tracking with Mixpanel for projects using the Original ID Merge API, you need to ensure that the same user is recognized across different domains. The recommended approach is to pass the Mixpanel distinct_id from one domain to the next domain, typically via URL parameters. Then call identify() on the next domain using the distinct_id from the previous domain. For example:

On the First Domain:

• Retrieve the current user’s distinct_id using the Mixpanel SDK.
• When redirecting or linking to the second domain, append the distinct_id as a URL parameter.

// On the first domain*
var distinctId = mixpanel.get_distinct_id();
var destinationUrl = "https://second-domain.com";
var urlWithDistinctId = destinationUrl + (destinationUrl.indexOf('?') !== -1 ? '&' : '?') + "distinct_id=" + encodeURIComponent(distinctId);
window.location.href = urlWithDistinctId;

On the Second Domain:

• Extract the distinct_id from the URL parameters.
• Use mixpanel.identify(distinctId) before sending any events.

// On the second domain
var urlParams = new URLSearchParams(window.location.search);
var distinctId = urlParams.get('distinct_id');
if (distinctId) {
  mixpanel.identify(distinctId);
}

To set up cross-subdomain tracking with Mixpanel, you should configure the Mixpanel JavaScript SDK to use cookies for persistence and enable the cross-subdomain cookie option. This ensures that the same Mixpanel distinct_id and super properties are shared as users move between subdomains.

// enable cross-subdomain cookie tracking
mixpanel.init('YOUR_PROJECT_TOKEN', {
  cross_subdomain_cookie: true,
  persistence: 'cookie'
});

To ensure consistent user tracking across multiple platforms, apply identity management best practices:

1. Call identify(<user_id>) during user registration and sign-in to associate activity with the correct user.
2. Call reset() upon user logout to clear the current session and prevent data from carrying over.
3. Use the same user_id for each individual user across all platforms to maintain a unified profile.

Learn more about identifying users.

If you are using the Original ID Merge API (check your project API here), 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.

Seeing data from two different users under a single Mixpanel profile is most commonly caused by improper identity management - specifically, not calling reset() when users log out on shared devices.

If multiple users use the same device and you do not call reset() when a user logs out, the next user who logs in will inherit the previous user’s distinct_id. When you then call identify() with the new user’s ID, Mixpanel merges the previous and new IDs into a single identity cluster. This causes events from both users to appear under the same profile.

Learn more about identifying users.

If your backend or frontend sends events for different users but uses the same distinct_id, Mixpanel will attribute all those events to a single user profile.

Mixpanel identifies users based on the distinct_id value. If the same user receives two different IDs, Mixpanel treats them as separate users, even if they share other properties.

For instance, when you send data from multiple sources—such as web, mobile, or third-party tools like Segment or Shopify—and each source assigns a different identifier (e.g., email, user ID, or device ID), Mixpanel generates distinct user profiles for each ID, regardless of matching properties like email.

To resolve this issue, review all data sources and ensure that each user is consistently assigned a single unifying user ID during identification across every platform.

The development effort required to migrate from Legacy ID Management to Original or Simplified ID Merge in Mixpanel depends on which version you are moving to:

Migrating to Original ID Merge typically involves minimal effort if your implementation already follows best practices (calling alias at user registration and identify at login using supported SDKs). In this case, Mixpanel can enable the migration for you, and no additional development work is required on your end. To proceed, contact the Support team for assistance with transitioning from the legacy API to the Original ID Merge API.

Migrating to Simplified ID Merge requires significantly more effort. This path involves setting up a new project, updating your codebase, migrating data, and releasing app updates. The process is manual, and your engineering team will need to manage each step directly.

Both ID Merge APIs offer substantial improvements over the legacy implementation, and we recommend that most projects migrate to one of these updated options.

You can view a comparison of the two ID Merge APIs. For further guidance, please reach out to the support team.

Please see a summary of the pros and cons when choosing between the 2 ID Merge API versions here.

When you use Mixpanel’s client-side SDKs (e.g., JavaScript, iOS Swift, Android), clearing cookies, localStorage, or uninstalling the app removes the distinct_id, $device_id, and super properties from the user’s device. If the user returns to your website or reinstalls the app, the SDK will generate a new random distinct_id and $device_id.

Once you call identify with the user’s known identifier, Mixpanel will reconcile the data and attribute it to the correct user profile in the Mixpanel UI.

Projects using the Original ID Merge API can merge up to 500 IDs within a single identity cluster.

Projects using the Simplified ID Merge API can merge an unlimited number of $device_id under one identity cluster; however, each cluster can contain only one $user_id.

You can view a comparison of the two ID Merge APIs.

Mixpanel handles merging IDs through a process called ID Merge, which groups different identifiers (such as anonymous device IDs and authenticated user IDs) into a single “identity cluster.” This ensures all events from the same user (across devices, platforms, and sessions) are linked to one user profile.

As a best practice for client-side implementation, call identify() at registration and sign in using a consistent $user_id, and call reset() at logout.

For server-side implementation, your server is responsible for generating IDs for your users and maintaining ID persistence across events.

Learn more about identifying users.

Mixpanel neither require nor collects any personally identifying information about users, such as email addresses or phone numbers (unless you specifically provide the information to us). It only needs to associate a sequence of events with a specific user ID. You determine the user ID and decide how to transmit it to Mixpanel.

If you prefer to analyze aggregate user behavior without the ability to identify individual users, we recommend creating a hash of a unique user identifier and using that hash as the user ID when invoking the .identify() method in our SDKs.

Learn more about protecting user data.

WIP

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.