New to Mixpanel?
This documentation covers the technical details that makeup Mixpanel. View the Getting Started section of our Help Center if you are new to Mixpanel and want to learn more about the product's features and uses.
Mixpanel was built to give you answers about your product's usage. At our core, we maintain a custom datastore that queries your data in a fast, scalable, and reliable manner. On top of that datastore is our user-friendly web application which lets you visualize the data you have sent us
First, you need to get data into your project. This is most commonly done through our hosted SDKs. You can use our Data Collection APIs if there is not an SDK for the environment you want to connect.
It is important to build a tracking plan before implementing Mixpanel. A tracking plan connects a Mixpanel implementation to goals and performance indicators, optimizing your Mixpanel use case.
Your tracking plan serves as a map for implementing Mixpanel and a reference ensuring that meaningful events and properties are being collected. It also guides the development process.
Mixpanel offers an array of both client-side and server-side libraries. The client refers to the browser or app that your end-users interact with. The server hosts the information that the end user’s browser or app displays. This article will explain the differences between server-side and client-side SDKs so that you can decide how to track each event. For a more in-depth look, see Client-Side vs Server-Side Tracking .
Some events need to be tracked directly from the end user’s device, like when they perform an action that has no associated server call. Other events are better tracked from your server, like a transaction.
For example, you may have a hybrid server-side and client-side implementation where users sign up on a website. The user clicks
Sign up and fills out a form, triggering a client-side event. The information the user fills out is sent to your server. You can send an event from your server to Mixpanel to confirm that the sign up is complete.
It’s better to track some events on the client-side SDK, such as actions taken in web pages and mobile applications. The following list outlines some of the advantages of client-side SDK tracking:
- You can use super properties to send properties with every event without having to add them to each event manually.
- The client-side SDKs automatically assign a distinct ID to any user that performs an event on your site or app.
- A Default Properties are pieces of meta information that mixpanel automatically includes with every event. You can find a list of the default properties and more information in the Help Center Guide.
distinct_idcreation helps you with identity management for anonymous users. Library methods allow you to convert a visitor into a known user.
You can use the following client-side SDKs with Mixpanel:
Some actions are easier to track from your service's backend. Server-side tracking lets you send data that you want to associate with your users to Mixpanel from your database.
You can use the following server-side SDKs with Mixpanel:
Don't see an SDK listed here? Post to our Community Ideas page to request support for a new platform.
Mixpanel's Ingestion API collects events, user information, and group information. If you send data using the proper JSON format, Mixpanel ingests and displays that data. Mixpanel's ingestion capability allows you to track events on any device that is connected to a network.
Examples include IoT devices, hardware with a network connection (such as a drone with network capabilities), server-side implementations that do not have an SDK, or server-side implementations that you want more granular control over.
View the Ingestion API Reference to learn more.
Mixpanel's EU Data Residency Program enables the storage of user data on Europe Servers. This allows you to protect from where your information is held and processed.
After signing up for Data Residency you will use a different subdomain during all APIs calls.
EU Residency Server
You will need to set the server location when initializing the library. Below you can find a link to the necessary config setting for each SDK:
In order to make the project accessible on eu.mixpanel.com for querying reports, the project’s cluster must be set to
mixpanel-prod-eu on Mixpanel's side. Reach out to your RM, CSM, or AE and they can coordinate this change.
Once the setup is complete, the customer can log into their account at
eu.mixpanel.com. At this point, all core functionality of Mixpanel will be present.
eu. to the beginning of your postback URL if you want the IDP initiated flow to direct to the
eu.mixpanel.com site (e.g.
mixpanel.com/security/login/1 would become
If you need users to be able to choose their IDP initiated flow, create a version with
eu. and a version without
eu. and assign the correct one to the correct user (e.g. in Okta you could create a “Mixpanel” and “Mixpanel (EU)” app).
Do Not Track Browser Settings
Updated about a month ago