Mixpanel maintains SDKs for easy implementation across many different platforms. Use the Ingestion API if there is not an SDK that supports your use case.

Follow the integration pages to programmatically implement Mixpanel with an SDK. In addition to event tracking, the integration pages cover Mixpanel dependencies such as identity management, group implementation, etc.

Use the HTTP specification for implementations that do not use an SDK. This includes server-side implementations that do not have a library, and can accommodate implementing on any device with a network connection, such as an “internet of things” device.

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.

View sample tracking plans in the Help Center to get more detail.

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 is going to explain the differences between server-side and client-side SDKs so that you can decide how to track each event.

Some events are better tracked directly from the end user’s device, like selecting Sign Up. 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.

Client-Side SDKs

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 manually add them to each event.
• The client-side SDKs automatically assign a distinct ID to any user that performs an event on your site or app.
• You can find a list of the default properties in this article. Default properties help you track important properties with every event, without having to manually add them. For example, if you want to analyze how your premium users behave compared to your free users, you can register a “User Type” super property. With “User Type” as a super property, you can segment and filter all of your client-side events by the “User Type” property.
• You can use the distinct_id that Mixpanel assigns each user help track anonymous users.

You can use the following client-side SDKs with Mixpanel:

• Javascript
• iOS - Objective-C
• iOS - Swift
• Android

Server-Side SDKs

It’s better to track some events using a server-side SDK. The following list outlines some of the advantages of server-side SDK tracking:

• Server-side tracking lets you send data that you want to associate with your users to Mixpanel from your database, including revenue data. To ensure accuracy of revenue data, many Mixpanel users choose to send this data using one of the server-side libraries.

You can use the following server-side SDKs with Mixpanel:

• Python
• Java
• PHP
• Ruby
• Unity
• NodeJS

The api.mixpanel.com/, or Ingestion API, endpoint will ingest 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 a server-side implementations that you want more granular control over.

View the HTTP Spec documentation to learn more.

Mixpanel supports a collection of APIs that can use Mixpanel functionality outside of the web application.

View this page to see an overview of Mixpanel APIs.

Android SDK

Specify different endpoints by using specific meta-data tags. On the app AndroidManifest.xml file, you need to add the following tags under your <application> tag. This will override our track, engage and groups endpoints:

<meta-data android:name="com.mixpanel.android.MPConfig.EventsEndpoint"
           android:value="https://api-eu.mixpanel.com/track" />
<meta-data android:name="com.mixpanel.android.MPConfig.PeopleEndpoint"
           android:value="https://api-eu.mixpanel.com/engage" />
<meta-data android:name="com.mixpanel.android.MPConfig.GroupsEndpoint"
           android:value="https://api-eu.mixpanel.com/groups" />

iOS SDK

Follow normal documentation, set the different endpoint by using serverURL property after initializing the client.

Objective C

self.mixpanel = [Mixpanel sharedInstanceWithToken:@"MIXPANEL_TOKEN" launchOptions:launchOptions];
self.mixpanel.serverURL = @"api-eu.mixpanel.com";

Swift

mixpanel = Mixpanel.initialize(token: "MIXPANEL_TOKEN")
mixpanel.serverURL = "api-eu.mixpanel.com"

JavaScript SDK

Follow normal documentation, except for when initializing the client. Instead of mixpanel.init("YOUR_TOKEN"); use

mixpanel.init("YOUR_TOKEN", { "api_host": "api-eu.mixpanel.com" }, "");

Query Capability

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 side. Reach out to your RM/CSM/AE/ and they can work with Mixpanel Engineering or Support to make this happen.

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.

Login via SSO

Prepend 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 eu.mixpanel.com/security/login/1).

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).