Mixpanel FAQs

MTU Pricing Transition

Mixpanel is transitioning to a Monthly Tracked Users (MTU) billing system. The plans described in this article are legacy plans. Read this blog post to learn more about the switch to billing for Monthly Trackers Users.

Create custom combinations of events by making a custom event within Mixpanel.

Custom events allow you to define a group of users based on existing events and properties, and then integrate that group into Mixpanel reports.

Once a custom event is created it is available to all users in the project and can be accessed across all reports.

Limits by Plan Type

Free: 1 Custom Event

Startup: 15 Custom Events

Enterprise: Unlimited Custom Events

MTU: Unlimited Custom Events

Visit our pricing page to learn more about differences between plan types

Create a Custom Event

Expand the Event dropdown in either an Insights, Funnels, Retention, or Formulas report.

Lexicon

Select Create custom event.

Select the events and properties you’d like to include.

Name your custom event, and click Save.

When naming your custom event, note that the UI will break when the URL passes 2,083 characters. Each event and selector adds to the URL length (selectors more so than events). The easiest way to break a custom event is with an "equals" operation that selects a lot of values.

Edit and Delete Custom Events

To view your complete list of custom events to manage, edit, or delete them, you must navigate to the .

In Lexicon, click on theCustom Events tab.

Here you can see a list of all the custom events in the project. Click on thename of the event to edit its details.

To delete a custom event, check thebox beside the title of all the custom events you want to delete, then click the delete buttonat the top of the list.

Example Use Case

Imagine your business has two ways for users to spend money: they can purchase an item from your store or subscribe to a service that you offer.

You represent each of these actions with Mixpanel events named "Item purchased" and "Subscription created," respectively. Later, you decide that you want to setup a funnel to track how many users are logging in and then spending any money at all. So what do you do?

You can create a custom event containing "Item purchased" and "Subscription created," and then save it as "Spent money.” Now you can use the "Spent money" custom event as a funnel step just like a regular event. Then, any time a user performs an "Item purchased" or "Subscription created" action, they'll be included in that step. You can also use this new custom event in your other reports, such as Retention.

It is important to adhere to best practices when managing personal information (PI). PI can include identifiers such as name, address, email, and even IP address. While certain data privacy and security regulations (such as GDPR ) explicitly require PI management protocols, it is always important to prudently manage PI.

Mixpanel has safeguards to protect the security of data sent to our APIs (see our security whitepaper for more details), however there is always some inherent risk when handling PI. For this reason, Mixpanel gives full control to its customers to specify which data to send (or not send) to the Mixpanel platform. It is therefore necessary to consider which data includes PI when implementing Mixpanel tracking.

There are several precautions that can be taken that will maximize the security and privacy of the personal information of end users. The following list offers several suggestions and practices for managing PI while using Mixpanel.

Secure Tracking Plans

Mixpanel provides the ability to customize and adjust the information that is collected by Mixpanel. While this flexibility facilitates meaningful tracking and analytics, it also necessitates extra focus on managing end users’ PI.

It is important to create a tracking plan before implementing Mixpanel. Incorporating security and privacy concerns into this plan will decrease the possibility of unknowingly collecting sensitive information. In general, we recommend collecting only the data that will help with answering your specific business questions.

Additionally, having a competent tracking plan will make it easier to manage PI and quickly respond to end user inquiries about that information.

Use Randomly Generated Identifiers

Mixpanel’s client-side libraries automatically assign a unique random hash for the user’s unique identifier called a distinct_id. The distinct_id represents a unique user in Mixpanel and it is necessary for Mixpanel report calculations. It is possible for Customers to either use the default Mixpanel distinct_id to identify users, or to create a custom identifier to use as the distinct_id. It is also possible to alias the distinct_id to a custom value to assist with keeping your users’ distinct_ids consistent across platforms.

It is possible to assign custom values as the user’s distinct_id or alias that include PI. If you wish to track users truly anonymously, however, then your tracking implementation should not use user-specific information, such as the user’s email address. Instead use a value that is not directly tied to a user’s PI, whether it be a unique anonymous hash, or a non-PI internal user identifier.

Disable Geolocation Tracking

Mixpanel automatically assigns location properties (City, Region, Country) to incoming data. This is done through the collection and parsing of the end user’s IP address. Mixpanel does not store IP addresses, but rather, only uses IPs to assign geolocation properties to data upon ingestion.

It is possible to prevent default location properties from being assigned to data sent to Mixpanel. Follow the instructions in this article to disable IP address collection. Reference this article when handling IP address collection on server-side Mixpanel implementations.

Opt-Out Users

Mixpanel respects "Do Not Track" settings in web browsers. Follow the instructions in this guide to prevent your browser from sending data to Mixpanel.

Mixpanel supports individuals' right to control their personal information. Every tracking implementation should incorporate an ability to opt an end-user out of tracking if the end-user does not give permission to be tracked.

If using one of Mixpanel's client-side tracking libraries, it is possible to halt tracking of end-users from a particular browser or device by changing their opt-out state. No data will be sent for users with a local opt-out state of “true.”

Mixpanel opt-out methods control data that is sent out from a particular tracking implementation located on the end-user’s device. In order to prevent data from a particular user being sent to Mixpanel, that user must be opted out of tracking on each platform from which data is sent.

For example, data sent to Mixpanel server-side or in response to a user opening an email will still be sent if the user is opted-out on a website or application. To prevent message analytics from being sent to Mixpanel when a user is targeted in a message, it is best practice to delete the user’s profile in addition to opting them out of tracking.

Refer to our developer documentation to learn more about managing opt-out state of end users.

Use a Server-Side Implementation

Mixpanel's tracking libraries are open-source and can be viewed in the Mixpanel Github repository. These libraries are built as a convenience, but it is possible to forego the use of them.

Data must be collected, formatted, and sent directly from a private server for absolute control over the data sent to Mixpanel. See the Mixpanel HTTP spec for a full breakdown of the expected format of data sent to Mixpanel.

Additional Information

To learn more about Mixpanel’s approach to PI and privacy, refer to our Privacy Statement.

Prerequisite: Guide to Mixpanel Basics

This guide assumes that you already have a foundational understanding of the Mixpanel data model. If you haven't already done so, please take time to review the Guide toMixpanel Basics before proceeding with this guide.

Mixpanel offers an array of analysis tools that provide actionable insight into both a product and its users. In this guide, we'll explore a few of Mixpanel's most popular analysis features and discuss important best practices to consider when analyzing your data.

Understand Your Data

Before you try to run any sort of analysis, it's important to familiarize yourself with the data that is being collected within your Mixpanel project. The easiest way to do this is by navigating over to Lexicon which contains a complete list of every event and property that is sent to your project. Here, you can also find additional bits of information on each event and property to help you better understand the data in your project.

Mixpanel Messages

Missing Descriptions

If you come across an event or property with a missing description in Lexicon, it simply means that no one at your company has set a description for that event or property yet. In such cases, try to track down the individual(s) responsible for setting up your Mixpanel tracking and ask them to add the appropriate descriptions.Only user accounts with either an Owner or Admin project role will have the necessary permission level for adding descriptions within Lexicon.

This same information about events and properties can also be accessed directly within any of the Mixpanel reports. Hovering over an event or property within any dropdown in Mixpanel will cause a panel to appear with the Lexicon details about the corresponding event or property.

Lexicon Overview

Adding descriptions and displaying volume and query counts are just a few of the features offered by Lexicon. Check out this article for a complete overview of Lexicon's functionality.

Common Metrics

In this section, we'll identify some common product metrics and see how easy it is to analyze them with Mixpanel. Through this process, you'll be introduced to a few of the most popular analysis reports and features within Mixpanel.

Music Finder

We'll be using a hypothetical music streaming app called Music Finder as the context for all upcoming examples in this guide. While the data shown in these reports will be specific to Music Finder, all concepts illustrated in these examples are universally applicable, regardless of product or industry.

Number Of Active Users

Measuring the number of active users over time is a common way of analyzing the growth of a product's user base. While this is a fairly universal metric, the definition of an "active user" will vary from company to company let's look at a couple examples.

Simple Example

The most basic way to define an active user is by identifying a single event that the user must perform in order to be considered active. For example, let's consider any user that has played a song in Music Finder as an active user. In that case, we can simply use the Insights report to show us the unique number of "Song Play" events as a line chart over time.

By adjusting the time interval, we can switch between analyzing the number of daily, weekly, or monthly active users.

Alternatively, we can use Insight's built-in DAU, WAU, or MAU function as a shortcut for building our active user report.

Insights Overview

Calculating the number of active users is just one of many types of analysis that can be performed with the Insights report. Check out this article to learn more about what's possible with the Insights report.

Complex Example

Let's say we change our minds about how we want to define an active user now we only want to consider a user as active if they have played at least 3 songs. To calculate this more advanced active user metric, we would first need to use theCohorts feature within Mixpanel to define a group of currently active users.

Next, we can view this cohort within the Insights report to see how the size of our active user cohort has changed over time.

Cohorts Overview

Cohorts is an extremely powerful tool that allows you to define groups of users based off of advanced filtering criteria. Once a cohort is defined, it can be used across the various Mixpanel reports to analyze the behavior of a particular subset of users. Check out this article for a complete overview of Cohorts.

Conversion Rates

Conversion rates are a measure of how many users successfully move their way through a defined user flow. The Funnels report makes it extremely easy to analyze conversion rates let's look at a quick example.

Let's say we want to measure how many users go on to sign up for an account after viewing our signup page. In that case, we can build a simple two-step funnel to measure our signup conversion rate.

Furthermore, we can view the conversion rate as a trend line to see how it has changed over time. This feature is particularly useful when trying to assess the impact of product changes on important conversion rates.

Funnels Overview

The Funnels report supports a variety of different configuration options which will impact the way the analysis is calculated.Check out this article to learn more.

Retention Rates

One of the best indicators of a product's health is its user retention rate, which measures how effective the product is at keeping users coming back over time. The Retention report offers a simple interface for measuring various types of user retention rates let's check out a couple examples.

Recurring Retention

Recurring retention measures how many users repeatedly perform the same action over a period of time. For example, let's say we want to knowhow many users that were playing songs in Music Finder last month are still playing songs in our product this month. We can easily analyze this with a Recurring Retention report.

First-Time Retention

Let's say we want to know how many users are still playing songs one month after signing up. In that case, we can run a First-Time Retention report to get us our answer.

Interpret A Retention Report

Please refer to this article for details about the nuances of how the numbers within a Retention report are calculated.

Properties in Analysis

The value of collecting details about users and their actions in the form of properties is that these properties can be used to perform more granular analyses within Mixpanel. More specifically, there are two primary ways that properties can be utilized within Mixpanel, and we'll explore both in this section.

Property Filter

Property filters allow us to narrow the scope of our analysis to a subset of data that meets particular criteria. For example, let's say we want to know what our signup conversion rate is for users within the United States on the Firefox browser. We can get our answer by running a Funnels report with a couple property filters.

Property Breakdown

Property breakdowns allow us to compare different subsets of data side-by-side. When we select a property breakdown, Mixpanel will first segment our data into groups based on the value of the selected property and then perform the specified analysis across each group separately. For example, if we wanted to know what musical genre has been the most played this month, we can accomplish this with a property breakdown in an Insights report.

Furthermore, most Mixpanel reports support multiple property breakdowns. For example, if we want to know what musical genre is most popular within each country, we could first breakdown by the "Country" property and then breakdown by the "Genre" property.

Event Properties vs. User Profile Properties

Mixpanel allows you to use both event properties and user profile properties within filters and breakdowns. It's important to know the difference between these twoso that you can decide which one is appropriate for your intended analysis.

Event properties provide details about an action at the moment it took place whereas user profile properties describe the current state of a user.Depending on your implementation, you might have instances where an event property shares the same name as a user profile property. For example, in our Music Finder project, all events have a "City" property (i.e. event property) and all user profiles also have a "City" property (i.e. user profile property).

The values for these two properties can differ, even though they refer to the same user and share the same property name. For example, if a user played a song in San Francisco yesterday and then logged in to Music Finder from Los Angeles today, the "Song Play" event from yesterday would have a "City" property equal to "San Francisco" but the user's profile would have a "City" property equal to "Los Angeles."

Wrap Up

In this guide, we only scratched the surface of the various types of analysis that can be performed within Mixpanel. For a more exhaustive list of Mixpanel's analysis capabilities, please explore this collection of articles.

Next Step

Guide to Mixpanel Messages

Learn how to use to send targeted communication to your customers and easily measure the impact of your outreach.

In this video course we explore the fundamentals of how Mixpanel works and highlight some of the key features of this powerful analytics platform. This course is a perfect starting point for new users looking for a quick guide to get up and running in Mixpanel.

Total Duration:~45 minutes

Course Overview

[email protected]

Lesson 1: Data

Additional Resources:

Mixpanel Implementation (Course)

Lesson 2: Analysis

Additional Resources:

Insights Deep Dive (Course)

Insights (Additional Resources)

Funnels (Additional Resources)

Retention Deep Dive (Course)

Retention (Additional Resources)

Cohorts (Additional Resources)

Lesson 3: Action

Additional Resources:

Take Action (Additional Resources)

Conclusion

Course Feedback

Please use the buttons below to let us know whether or not you found this course helpful. If you would like to provide any further feedback on this course, or if you have any suggestions for additional training resources, please reach out to us at .

Liquid templating in messages allows for greater flexibility to create dynamic and powerful messages for your customers.

Mixpanel has two options for templating and personalization in email messages, advanced templating through Liquid, and a Mixpanel custom templating language. SMS messages only use Liquid Templating.

This functionality is currently only available in email messages, SMS messages, and push notifications.

Liquid in Email Messages

Select the checkbox marked Use advanced personalizationat the bottom of the message form to use Liquid formatting.

here

Liquid in SMS Messages

SMS messages use Liquid templating in the message body automatically.

Liquid in Push Messages

Select the checkbox marked Advanced templating (liquid) below the Custom Data box to use Liquid formatting. You can add Liquid templating in the preview phone screen or the Custom Data box.

Templating Language

Liquid is an open source templating language created by Shopify. Liquid templating language is usable in its officially documented form with only a few caveats. The official documentation can be found here.

Liquid code has three elements: objects, tags and filters.

Objects:typically variable names. Liquid objects contain attributes to output dynamic content in your message. For example, you can use variables stored in your user profiles. Objects are always enclosed within double curly braces.

For example:

{{ user['$name'] }}

Tags:create the logic and control flow for templates. Tags are denoted by curly braces and percent signs: {\% and \%}. They produce no visible text.

For example:

{\% if user['$name'] \%}

Hi {{ user['$name'] }}

{\% endif \%}

Filters:change the output of a Liquid object. Filters are used within an output (in curly braces) and are separated by a |. View all Liquid filters here.

For example:

{{ 'mywebsite.com/product/' | append: user['recommended_product_id'] }}

Common Use-Cases

Here are several helpful common use-cases for Liquid syntax.

Conditional Statements

Language localization: Create a single message with different text for each language, rather than creating separate messages for each.

For example:

{\% if user['language'] == 'Spanish' \%}

Hola {{ user['$name'] }}!

{\% elsif user['language'] == 'French' \%}

Bonjour {{ user['$name'] }}!

{\% else \%}

Hi {{ user['$name'] }}!

{\% endif \%}

Product recommendations: Send product recommendations based on other products the customer already has.

For example:

{\%if user['asset_type']=='Bitcoin'

or user['asset_type']=='Ether'\%}

Have you considered our latest Litecoin offering here?

{\%endif\%}

Iteration

Recommendation lists: Send a list of recommendations to a user based on other products they have looked at.

For example:

You may be interested in some of these products

{\% for products in user['products_list'] \%}

{{ products }}

{\% endfor \%}

Formatting

User name capitalization:

Hi {{ user['name']|capitalize }}

Appending custom text:

{\% assign campaign_name = '/index.html' \%}

{{ 'website.com'| append: campaign_name }}

Time formatting: Pass the special object 'now' to get the current time and use that in your messages to automatically update copyrights as the year changes.

For example:

Mixpanel {{ 'now' | date: '\%Y' }}

Caveats

There are several instances in which the format of Mixpanel's templates differs from Liquid. This guide will clarify those differences.

User Profile Property Namespacing

Mixpanel expects all variable substitution for user profile properties to be escaped and placed under the namespace user. For example, if a user had the properties $name and language, you would express it like the following:

{\% if user['language'] == 'Spanish' \%}

Hola {{user['$name']}}!

{\% elsif user['language'] == 'French' \%}

Bonjour {{user['$name']}}!

{\% else \%}

Hi {{user['$name']}}!

{\% endif \%}

Restricted User Profile Property Characters

User profile properties containing the characters " or } will not be properly substituted and may result in a failure to send messages. Note that these characters are still viable in Mixpanel’s custom templating language if properly escaped.

For example, if you had a user profile property called ab}}cde, Mixpanel’s custom templating would allow you to express that as {{${ab\}\}cde}}} but this is not expressible in the Liquid templating format.

Differences Between Mixpanel and Liquid Syntax

The braces to declare variables and conditionals are the same between Mixpanel and Liquid; however, the contents of those braces will differ slightly.

Variable Substitution

In Mixpanel syntax, it isn’t required to escape all variables, although many will need to be anyway. In Liquid, all variables (representing user profile properties) are expected to be escaped and namespaced under user. This means that, while the property $name in Mixpanel would be substituted in the following manner:

{{${$name}}}

it would be represented in Liquid syntax with the following:

{{user['$name']}}

Conditionals/Control Flows

The control flow syntax is identical between both Mixpanel syntax and Liquid syntax. Liquid syntax provides additional functionality in the form of comparisons and elsif expressions. This means that instead of being limited to something like the following, assuming any user with a language is French:

{\% if ${language} \%}

Bonjour!

{\% else \%}

Hi!

{\% endif \%}

In Liquid, a message could have more options:

{\% if user['language'] == 'Spanish' \%}

Hola {{user['$name']}}!

{\% elsif user['language'] == 'French' \%}

Bonjour {{user['$name']}}!

{\% else \%}

Hi {{user['$name']}}!

{\% endif \%}

Filters

Mixpanel currently supports one type of filter: fallback. This filter provides a default value if the user profile property is empty. An example of this would be the following:

Hi {{${$name}|fallback: 'new user' }}!

This functionality also exists in Liquid, however, the keyword is instead default. Given that difference, the same template could be produced with the following in Liquid:

Hi {{user['$name'] | default: 'new user'}}!

Liquid also supports many other filters that are shown .

Codeless mobile tracking enables you to track mobile app activity without using code.

To setup codeless mobile event tracking:

Click theSettings gearin the upper righthand corner of your Mixpanel project and selectCodeless Trackingfrom the dropdown.

Android

2. Choose your platform, and connect your app using either a phone or an emulator. Once you’re connected, you can easily add event tracking to your app from your browser.

Codeless mobile tracking lets you track events, but you won't be able to add custom properties to those events.

Mixpanel recommends you usecodeless mobile tracking in tandem with traditional Mixpanel tracking ( iOS and) to unleash the powerto slice and dice your data by custom properties.

Each Mixpanel account can contain multiple projects. Each project has its own unique routing number, which we call a project token. Whenever you want to send data to a specific project, you'll need to specify the project token so we know where to put the data.

Locate Current Project Token

Click theSettings gearin the upper right hand corner of your Mixpanel project and selectProject settingsto see your project token for only the project you’re currently viewing:

All management options and project access keys are available in the main Overview tab.

Locate Tokens for All Projects in Your Mixpanel Account

To view the project tokens for all your projects, click your initials in the top right of Mixpanel and select Profile & Preferencesunder Personal Settings.

Then select theProjectstab.

Organization settings allows you to manage administrative information, such as team permissions and billing.

All company projects, users, teams, and billing plans roll up to an organization level. A company’s organization has an organization owner, admin, and billing admin to manageadministrative and billing tasks.

Previously, project owners were responsible for all administrative duties. These are now separated across roles in an organization.

To view more information on Mixpanel Organizations, view the Organizations Overview article.

Access Organization Settings

To access the Organizations settings menu:

In the Mixpanel header bar, click the icon with your initials.

Under “ORGANIZATION SETTINGS”, click the organization you want. In the image below, you would click TestCorp. Note that the name you see depends what the organization owner names the organization. For example, if the organization owner from Acme Test Corporation names the organization “TestCorp”, then that is the name that displays on the top right.

request to access or delete

Organization Settings Overview

The following settings are accessible from the Organization Settings menu:

Note

Not every user will see these settings for Organizations.

Users that are assigned member roles won't see these settings.

Only organization owners, admins, and billing admins will be able to see these settings.

Users without a project admin or owner role on a specific project in the current session won't be able to see project settings.

All roles can see personal settings.

Overview

The "Overview" menu shows information that is associated with an organization. You can see an organization's purchase plans, update payment information, downgrade the plan, and cancel your plan.

For Engagement/People plans this will show the following data usage:

For MTU plans this will show the following data usage:

Projects

The "Projects" menu allows you to create and manage Mixpanel projects.

Note

To grant access to all projects, create a team and add all projects and organization members to that team to allow users to have access to all projects.

Users

The "Users" menu is where you invite new users and manage your existing users.

Teams

The "Teams" menu is where you create new teams and manage your existing teams. This includes setting team permissions.

Access Security

The "Access Security" menu is where you can set up single sign-on or two factor authentication for users.

Data and Privacy

The "Data and Privacy" menu is where Mixpanel account holders can their personal usage data.

In Mixpanel Organizations users have roles in an organization and in a project.

An organization links users, projects, and billing plans together in an account. A project contains event and user data.

The types of organization and project roles a user has should be based on the required permissions users need for specific levels.

This article defines project roles and permissions, and specifies those roles and permissions in Mixpanel features.

For more information on specific organization role permissions, see Organization Roles and Permissions.

Projects Roles and Permissions

A project has five roles: owner, admin, messenger, analyst, and consumer.

Your project role will be displayed below the project name in the top left of Mixpanel.

Messages & Experiments

Owner

When users create a project, they own and have complete control over it.

Organization owners and admins have administrative permissions to assume an admin role in a project.

Admin

Project admins have the same set of permissions as project owners. However, they can’t delete or reset the project or manage its security.

Analyst

Project analysts can view and create all Mixpanel reports.

Project analysts can also add and delete bookmarks. However, they can’t create or use messaging features or manage team member roles.

Consumer

Project consumers can view reports. They can save their own reports (and dashboards). Their saved entities will be hidden and consumers cannot change the visibility or edit permissions.

Consumers can add bookmarked reports to their own dashboards, but cannot create public dashboards or edit existing dashboards.

Consumers can also duplicate another user’s dashboard and view it as a private dashboard.

Project consumers can’t create or use messaging features, or manage team member roles.

Messenger

Project messengers can create and use messaging features unlike project analysts.

Project messengers can view and create any Mixpanel report, and they can add and delete bookmarks. They can’t, however, manage team member roles.

Project Settings

Project settings enable you to see an overview of project details, see usage statistics, obtain the project token and API secret, and more.

For more information on how to access and use project settings, see Project Settings.

In this section, you see a list of roles and permissions for tasks in these categories:

Overview

Project Users

Messages

Autotrack

Overview (Project Level)

Permission

Roles

Proj Owner

Proj

Admin

Proj

Analyst

Proj

Consumer

Proj Messenger

Transfer projects

Yes

No

No

No

No

Reset projects

Yes

No

No

No

No

Delete projects

Yes

No

No

No

No

Edit project timezones

Yes

Yes

No

No

No

Edit project name

Yes

Yes

No

No

No

View access keys

Yes

Yes

No

No

No

View usage statistics

Yes

Yes

No

No

No

Access time period settings

Edit

Edit

View Only

View only

No

Users (Project Level)

Permission

Roles

Proj Owner

Proj

Admin

Proj

Analyst

Proj

Consumer

Proj Messenger

Invite project users

Yes

Yes

No

No

No

Change project roles

Yes

Yes

No

No

No

Approve access requests

Yes

Yes

No

No

No

Messages

Permission

Roles

Proj Owner

Proj

Admin

Proj

Analyst

Proj

Consumer

Proj Messenger

Enable and disable sending messages for delay. (Green is enable; Gray is disable)

Yes

Yes

No

No

Yes

Edit the Android FCM Server Key

Yes

No

No

No

No

Edit the Apple Push Certificate

Yes

No

No

No

No

Edit Twilio information: Account SID, Auth Token, Messaging Service SID

Yes

No

No

No

No

Autotrack

Permission

Roles

Proj

Owner

Proj

Admin

Proj

Analyst

Proj

Consumer

Proj Messenger

Enable and disable the automatic collection of common mobile events

Yes

Yes

No

No

No

Disable collection of all actions on your website

Yes

Yes

No

No

No

Disable automatic page view tracking

Yes

Yes

No

No

No

Personal Settings

Personal settings enables you to view account details and make project changes, such as reset project API key and API secret, manage Mixpanel activity, and more.

For more information on how to access and use personal settings, see Personal Settings.

In this section, you see a list of roles and permissions for tasks in these categories:

Overview

Projects

Data & Privacy

Alerts

Overview (Account Level)

Permission

Roles

Proj Owner

Proj

Admin

Proj

Analyst

Proj

Consumer

Proj Messenger

Change account names

Yes

Yes

No

No

No

Change account emails

Yes

Yes

No

No

No

Change account passwords

Yes

Yes

No

No

No

Delete organizations

Yes

Yes

No

No

No

Projects (Account Level)

Permission

Roles

Proj Owner

Proj

Admin

Proj

Analyst

Proj

Consumer

Proj Messenger

View all projects and your projects

Yes

Yes

No

No

No

Reset projects

Yes

Yes

No

No

No

Data & Privacy (Account Level)

All members have access to these features regardless of role.

Enable and disable personalizing your Mixpanel experience

Enable and disable permission for Mixpanel to log your data usage

Request your account usage data

Delete your account usage data

Generate GDPR API OAuth token

Alerts

Permission

Roles

Proj Owner

Proj

Admin

Proj

Analyst

Proj

Consumer

Proj Messenger

Enable or disable subscriptions for custom alerts

Yes

Yes

No

No

No

Enable or disable subscriptions for automatic insights

Yes

Yes

No

No

No

AnalysisReports

Report analysis enables you to understand your event and user data.

For more information on how to access and use Mixpanel analysis reports, see Analysis.

In this section, you see a list of roles and permissions for tasks in these categories:

Insights

Live View

Formulas

Signal

Flows

Funnels

Retention

Predict

Permission

Roles

Proj Owner

Proj

Admin

Proj

Analyst

Proj

Consumer

Proj Messenger

Create and view Insights reports

Yes

Yes

Yes

Yes

Yes

View Live view

Yes

Yes

Yes

Yes

Yes

Create and view Formula reports

Yes

Yes

Yes

Yes

Yes

Create and view Signal reports

Yes

Yes

Yes

Yes

Yes

Create and view Flow reports

Yes

Yes

Yes

Yes

Yes

Create and view Funnels reports

Yes

Yes

Yes

Yes

Yes

View Funnels reports

Yes

Yes

Yes

Yes

Yes

Create and view Retention reports

Yes

Yes

Yes

Yes

Yes

Export Reports from Mixpanel

Yes

Yes

Yes

No

Yes

Create and edit Predict conversion events

Yes

Yes

Yes

Yes

Yes

User Reports

User reports help you to understand your user data.

For more information on how to access and use Mixpanel user reports, see Users.

In this section, you see a list of roles and permissions for tasks in these categories:

Explore

Cohorts

Explore

Permission

Roles

Proj Owner

Proj

Admin

Proj

Analyst

Proj

Consumer

Proj Messenger

ViewExplore reports

Yes

Yes

Yes

Yes

Yes

Create and modify Cohorts reports

Yes

Yes

Yes

Yes

Yes

Deleteuser profiles

Yes

Yes

No

No

No

Messages & Experiments

Messages & Experiments enable you to connect with users through Mixpanel Messages, Campaigns, and A/B Testing.

For more information on how to access and use Messages & Experiments, see .

In this section, you see a list of roles and permissions for tasks in these categories:

Campaigns

Messages

A/B testing

Campaigns

Permission

Roles

Proj Owner

Proj

Admin

Proj

Analyst

Proj

Consumer

Proj Messenger

Create and edit campaigns

Yes

Yes

No

No

Yes

Viewcampaigns

Yes

Yes

Yes

No

Yes

Create and edit messages

Yes

Yes

No

No

Yes

Viewmessages

Yes

Yes

Yes

No

Yes

Create and edit A/B tests

Yes

Yes

No

No

Yes

ViewA/B tests

Yes

Yes

Yes

No

Yes

Other Reports and Report Features

This section lists roles and permissions for:

Revenue

Dashboard

Bookmarks

Custom Events

Lexicon

Permission

Roles

Proj Owner

Proj

Admin

Proj

Analyst

Proj

Consumer

Proj Messenger

Create and view Revenue reports

Yes

Yes

Yes

Yes

Yes

Create and view dashboards reports

Yes

Yes

Yes

Yes

Yes

Create email digests fordashboard reports

Yes

Yes

No

No

No

Create and modify bookmarks

Yes

Yes

Yes

No

Yes

Create and modify custom events

Yes

Yes

Yes

No

Yes

Drop, merge, and hide and unhide events and properties in Lexicon

Yes

No

No

No

No

Edit descriptions in Lexicon

Yes

Yes

No

No

No

Add tags in Lexicon

Yes

Yes

No

No

No

By default, the Mixpanel cookies work across domains and subdomains, but Mixpanel does not automatically track across those domains.

However, if your site is hosted on a domain like Heroku (or similar - see a complete list of affected domains ) with a URL like XYZ.herokuapp.com, cross-subdomain cookies are not allowed for security reasons. With Mixpanel default settings on these sites, users' distinct_ids will be reset to a new $distinct_id on each page load. This will cause issues with Mixpanel reports, namely broken Retention reports and Funnels.

Related Article

Distinct ID In Reports

To resolve the issue on sites that don't allow cross-subdomain cookies:

The default cross_subdomain_cookie config is set to true in your mixpanel.init function, which will allow your subdomain's cookie to be stored and keep the Mixpanel distinct_id and super properties consistent across the sub-domain:

mixpanel.init(PROJECT_TOKEN,{cross_subdomain_cookie:true});

Or, use a CNAME to change from yourdomain.herokuapp.com to yourdomain.com.

Mixpanel’s Journeys allows you to create a scheduled sequence of messages that are sent based on cohorts, filters, or end-user’s actions. You can add entry criteria, message blocks, filter blocks, and time delays to a journey. This article explains how to build a journey. Learn about Journeys basics here.

Access The Journey Table

To view the the journey table, select Journeys under Messages & Experiments. The journey table includes all of your active, inactive, and draft journeys.

article

Create a New Journey

To create a new journey, click Create New.

Click the Untitled Journey field above the toolbar to add a name, and optional description to your journey.

Note

All journeys must start with an entry criteria and include at least one message block.

Entry Criteria

Add an entry block to decide how and when users qualify for the first message of your journey.

A user can only enter a journey once. You can configure entry criteria based on events. Select AFTER PERFORMING AN EVENT for Entry type.

Click the arrow icon to collapse the editing panel when you’re done configuring your entry criteria.

Note

Custom events are not supported in Journeys entry criteria.

Event Based Entry Criteria

AFTER PERFORMING AN EVENT means that a user will qualify for the journey after they perform the selected event. Click Select Event to choose which event you want to use as your entry criteria.

Use the time selector to configure when users must have performed the event to qualify for the journey. Click on the date range displayed under In the last to access the days, weeks, and months options. The default is “In the last 7 days”.

Filter by Property

You can filter the entry criteria event by an event or user profile property. Select Add filter to choose an event or user property to filter by.

Add a Message

You can add Webhook, Email, SMS, and Push message blocks to your journey. All messages in Journeys are copies of messages that have been previously created and saved in Messages.

Note

Any changes you make to the messages in your journey do not persist outside of that journey. If you edit a message in Journeys, those changes will not impact the original message it was copied from.

Click the plus icon to add a copy of a message and select Webhook, Email, SMS, or Push.

You can also drag and drop the message type you want to connect to a block in your journey.

Click the message block to configure your message. Click Select a message to search for the message you want to connect to your journey.

To edit the message block name, click the Block name field to edit. The name of the message block will default to the name of the message you select from the Messages drop down.

Note

You can only select a message that you have already saved in Messages.

Add Time Delay

Messages are sent as soon as possible, or you can add a time delay to each message to control when your message is sent. You can set a different time delay for each message block in your journey.

To configure a time delay, select either AS SOON AS POSSIBLE or AFTER A DELAY. If you select AS SOON AS POSSIBLE, the message will be sent as soon as users qualify for the message. If you select AFTER A DELAY, use the time selector to choose the days, weeks, or months that the message is delayed.

The time delay is based on when the previous message was sent. If you are adding a time delay to the first message in your journey, the time delay is based on the entry criteria. The time delay is at least the amount of time selected, not exactly.

The time delay is the minimum amount of time between when the user received the previous message, and when the next message is sent.

Note

If a message block has multiple incoming connectors, the blocks associated with those connectors will all have the same time delay.

Edit or Delete a Message

You can edit or delete a saved, paused, or started journey.

Delete connectors from a message block to change how users progress through the message blocks in a journey. You can edit the message content by editing the message block. You can disconnect a message block, or delete a message block from a journey.

Edit Message Block

To edit the content of a message, select the message block and click Edit. You can change the content of a message block without changing the message type by editing the existing message block.

Note

In a started or paused journey, editing the existing message is the best way to avoid users at that step not proceeding through the journey.

Incoming Connectors

All message and cohort blocks, besides the entry criteria block, must have at least one incoming connector.

Outgoing Connectors

You can delete outgoing connectors from a message block to stop a user’s journey at that message in a started or paused journey. New users who qualify for a message that has no outgoing connectors will exit the journey.

Delete outgoing connectors from a message block by hovering over the connector and clicking the trash icon.

Disconnect a Message Block

Disconnecting, but preserving the message block, allows you to track how many users did not proceed past that message in your started or paused journey.

Users who have received the disconnected message but have not qualified for the next message will not proceed through the rest of the journey. These users will not be able to re-enter the started journey.

New users cannot qualify for the disconnected message block.

To disconnect a message block from a journey, hover over the connectors and click the trash icon to delete the incoming and outgoing connectors.

Delete a Message

When you delete a message block, users at that stage in the started or paused journey will not proceed through the rest of the journey. These users will not be able to re-enter the started journey.

To delete a message, hover over the message block and click the trash icon.

Split Journey Path

Add a cohort to split the path of your journey and filter which users receive your message. For more information about cohorts see this article.

Click the plus icon on a block, and then click Cohort to split the path of your journey. You can also drag and drop the cohort filter from the toolbar to add a cohort to your journey.

Under Name, click Select Cohort to choose the cohort you want to use. You can select an existing cohort or create a new cohort. To create a new cohort, click Create cohort. For more information about how to create a cohort see this .

Messages in a journey check to see if new users qualify every fifteen to thirty minutes. Users can not enter cohorts more than once in a journey.

Note

Cohort filters must be connected to a previous entry or message block, and have at least one connection to a following message block in your journey.

Connect Blocks in a Journey

Click the plus icon and select Connect to existing to connect a block to another existing block in your journey.

Note

You cannot connect a block to a previous block.

To remove connectors, hover over the arrow you want to delete and click the trash icon.

Manage Your Journeys

Click the Journeys tab to view all of your saved journeys. You can open, duplicate, delete, pause or resume a saved journey.

Review a Journey

To start a journey, click Review Journey and then click Start Journey.

Open a Journey

To open an active, inactive, or draft journey, click the journey you want to open.

Delete a Journey

To delete a journey, click on the three dots next to the journey you want to open. Select Delete.

Pause or Resume a Journey

Click Pause or Resume to stop or start your journey. When you pause a journey, scheduled messages will not be sent. Users who qualify for a message while the journey is paused and then unqualify before the journey is restarted will not receive any messages. Any users who dropped out of the journey, while the journey is paused will not re-enter the journey when you resume the journey.

This feature is in Beta and is currently available in the Insights, Funnels, Flows, and Retention reports, as well as Dashboards.

Users with the Consumer role cannot create new custom properties, but they can use custom properties created by other users.

Create custom properties in Insights and Funnels to combine different properties or to restrict the property to specific values. Using a combination of properties, functions, numeric operators, and comparison operators described below, you can create a new property based on your existing properties and customize it to your exact specifications.

Create a Custom Property

Take existing properties (event properties or user profile properties) and use Excel-like formulas to transform those properties to create new properties.

Example use-cases include:

Create custom buckets to group your property values into

Merge property values to fix implementation issues

Create new properties based on the values of different properties

Round numeric property values

Extract terms from a URL using regex

Visibility and Editing controls

Click Create event/user profile property to open the property builder. If you select this option under EVENT PROPERTIES you will only be able to select event properties to build your custom property from. If you select this option under USER PROFILE PROPERTIES you will only be able to select user profile properties.

Enter a name for the custom property. Select one or more properties to combine and transform. Each property you select is given a letter code beside it, which you can use in the Formula field to create a formula to customize the property.

When writing your formula, click Ctrl + Space to see a list of all the available functions and their descriptions.

Click theInsert Example drop down to view a list of example formulas and insert them into the Formula field.

Custom properties are temporary for the current report by default if you click Create. To save the custom property permanently for use in other reports and to make it usable by other project members, click Save Permanently. Clicking Save Permanently will take you to an additional window where you can set the .

Functions

Use the following functions in the Formula field to modify your custom property:

Function Name

Definition

Syntax & Example

if

Evaluates if an expression is true or false.

if(condition, value if true, value if false)

Example:

if(A=="Facebook" or A=="Twitter", "Social", A)

ifs

Runs multiple checks and returns a value corresponding to the first true result. If no conditions are true, undefined is returned.

ifs(condition1, value1, condition2, value2, )

Example:

ifs( A<60,"Less than 1 hour",

A<120, "More than 1 hour but less than 2 hours",

A>=120, "More than 2 hours")

not

Returns values that are not true.

not(condition)

Example:

not (A)

and

Returns true if both conditions are met. Else, returns false.

x and y

Example:

if(A=="San Francisco" and

B=="Chrome", "Valid user", "Invalid User")

or

Returns true if either condition is met. Else, returns false.

x or y

Example:

if(A=="San Francisco" or B=="Chrome", "Valid user", "Invalid User")

in

Returns true if the first condition is contained in the second condition.

x in condition

Example:

if("Facebook" in A, "Facebook Corporation", A)

boolean

Casts the argument to a boolean.

boolean(value)->false, boolean(alternate value)-> true

Example:

boolean(A)

number

Casts the argument to a number.

number(value to cast)

Example:

number(A)

string

Casts the argument to a string.

string(value to cast)

Example:

string(A)

defined

Determines if a value exists. If a property is not defined on a parent event or profile, this will return false, otherwise this will return true.

defined(variable to check for existence)

Example:

defined(A)

has_prefix

Determines whether a string starts with another string. This comparison is case-insensitive.

has_prefix(string to check, prefix)

Example:

has_prefix(A, "United")

has_suffix

Determines whether a string ends with another string. This comparison is case-insensitive.

has_suffix(string to check, suffix)

Example:

has_suffix(A,"States")

min

Determines the minimum value between two numbers.

min(number, number)

Example:

min(A,B)

max

Determines the maximum value between two numbers.

max(number, number)

Example:

max(A,B)

floor

Returns the largest integer that is smaller than or equal to the input (ie: rounds down to the nearest integer).

floor(number)

Example:

floor(A)

ceil

Returns the smallest integer value greater than or equal to the input (ie: rounds up to the nearest integer).

ceil(number)

Example:

ceil(A)

round

Returns the nearest integer value of the input value.

round(number)

Example:

round(A)

upper

Cast string property values to uppercase.

upper(string property)

Example:

upper(A); upper("hello") -> "HELLO"

lower

Cast string property values to lowercase.

lower(string property)

Example:

lower(A); lower("FacEBook") -> "facebook"

regex_extract

If haystack is a string and pattern matches at least one substring, extracts the result from the first pattern match in haystack. The result is a string equal to the entire regex match, or if capture group is specified, only that portion of the match.

regex_extract(haystack, pattern, <optional capture group #>)

Example:

regex_extract("iPhone5.1","iPhone(...)",1) ->5.1

regex_match

Returns true if the pattern matches any part of the string.

regex_match(haystack, pattern)

Example:

regex_match("zzhaystackzz", "ha(..)ack") -> true

datedif

Returns the date/time difference between two date/time values. Users have the option of getting the time difference in one of these units:

D: number of days between start_date and end_date.

W: number of weeks between start_date and end_date.

M: number of months between start_date and end_date.

MD: number of days between start_date and end_date after subtracting whole months.

YM: number of whole months between start_date and end_date after subtracting whole years.

YD: number of days between start_date and end_date, assuming start_date and end_date were no more than one year apart.

Please also note, that in order to get the current date, users can use TODAY().

datedif(start_date,end_date,unit)

Example:

datedif(registrationdate,TODAY(), "M") -> 5

len

Returns the length of the string or the list.

len (string) or len (list)

Example:

len("Canada") -> 6

Numeric Operators

Use the following numeric operators in the Formula field to modify your custom property using:

+ : Addition

- : Subtraction

* : Multiplication

/ : Division

\% : Modulo

Comparison Operators

Use the following comparison operators in the Formulafield to modify your custom property:

< :The first number is strictly less than the second number.

> : The first number is strictly greater than the second number.

>= : The first number is greater than or equal to the second number.

<= : The first number is less than or equal to the second number.

== : The first argument is equal to the second argument. If both arguments are strings, the comparison is case-insensitive.

!= : The first argument is not equal to the second argument. If both arguments are strings, the comparison is case-insensitive.

False : Represents the literal value of boolean false.

True : Represents the literal value of boolean true.

Undefined : Represents the literal value of cases that aren’t defined.

Use Cases

Custom Bucketing

Use custom properties to create arbitrary ranges of your numerical properties. This is applicable when you want to create age groups from age, income classes from salary, and other numeric property transformations relevant to your business.

For example:

If you have a property for “Days since registration” and you want to bucket the users into “Months since registration” (0-1 months: X users, 1-6 months: Y users, 6+ months: Z users), you can use custom properties.

Take the property of “Days since registration” and create a new property called “Months since registration" with this transformation:

Ifs( A/30 <= 1, "0-1 months", A/30 <=6, "1-6 months", A/30 >6, "More than 6 months" )

Merge Values to Fix Implementation Issues

Use custom properties to combine multiple property values into one. This is helpful when customers want to take multiple variations of a property value (e.g. facebook, fb, fbsocial) and then combine them into one property value (e.g. facebook).

If you send values into Mixpanel with variations (even though they may have been minor) and you want to correct this issue by grouping those values together.

For example:

A marketing manager wants to understand what portion of the user base is coming through a social traffic acquisition path. They want to group all social channel values into a single value, and keep the rest of the channels as-is.

They can create a custom property using the channel with this transformation:

if("Facebook" in A or "Linkedin" in A or "Twitter" in A, "Social", A)

Create New Properties Based on Values of Different Properties

Use custom properties to create a new property using the values of multiple other properties.

For example:

A marketplace company wants to track total purchase amount for an order, but the per-unit price is passed as a property and the number of items is passed as a property.

They can create a custom property using “price” and “quantity” with this transformation:

A*B

Modify Defined Properties

Use custom properties to create a new property if and only if a property is defined.

For example:

A telco company charges its customers based on talk-time (minutes spoken) and on apps purchased. If the company wants to track the average duration per minute, they would want to restrict the calculation to just the purchases for talk-time (where duration (minutes) is defined).

They can create a custom property using “Duration” and “Amount” with this transformation:

if(defined(A), B/A, B)

Check whether Property Values Are the Same

Use custom properties to create a new property if two property values are the same.

For example:

A company wants to find out what percentage of purchases are being made by users that have changed countries since sign up.

They can create a custom property to determine whether the two country values are the same with this transformation:

if(A==B,FALSE, TRUE)

Transform String Property Values to Upper/Lowercase

Use custom properties to change the case of a string property value.

For example:

If a company that sells ice-cream wants to look at popular pie flavors, and if the flavors were written with different casing (“vanilla”, “Vanilla”, vaNilla”), the three values would show up differently as opposed to being the same.

They can create a custom property that combines and casts all these values to the same case using this transformation:

upper(A) or lower(A)

Visibility and Editing Controls

When you create custom properties and select Save Permanently, you have the option to decide whether it should be exposed to other project members (visibility controls), and whether you want other non-project owners to have the ability to change the custom properties (editing controls).

Visibility Controls

When users create a custom property, they have the ability to either:

Create a custom property temporarily.

Save a custom property but for themselves. The custom property persists, but is only available for that user.

Save a custom property for everyone to see and use. The custom property persists and is available to all users in the project.

Users can change these settings at any point of time.

Editing Controls

When users create a custom property, they have the ability to choose to not let other non-project owners edit the definition of the custom property. The project owners can always change the definition of any custom property.

Mixpanel allows you to import profiles in bulk using CSV.

After import, events that users or groups trigger will be visible on his or her profile in the "Activity Feed".

To get started, click CREATE OR UPDATE PROFILE.

Cohorts

Prepare Your CSV for Upload

When editing the CSV that you want to upload as profiles, you shouldnotinclude column headers (e.g., Email, Name, etc.). Instead, you’ll identify column headers during the CSV upload wizard in the Mixpanel UI.

Note:

If you upload a CSV with new information for existing contacts or companies,any existing informationwill be overwritten by new values you've imported.

Add an Identifier Column

The most important column in your spreadsheet is the $distinct_id column for user profiles or group identifier for group profiles, as these are the canonical identifiers in Mixpanel.

For more information on how $distinct_id works in Mixpanel, see:

Distinct IDs

Distinct ID Creation

Group Analytics

To ensure future actions by each user is recorded on the correct user profile, make sure the value you assign for $distinct_id or group identifier on import is the same value on which you’re identifying users when they log in.

If you do not assign an identifier column, Mixpanel will use your $email column as the $distinct_id value; if you don’t have an $email column either, then the $distinct_id value will be assigned randomly by default as described above.

Add Additional Columns for Properties

After the $distinct_id column, you can add as many columns as you want for additional profile properties.

Keep in mind that Mixpanel reserves a handful of user profile properties as special or reserved Properties. These properties will allow you more flexibility and functionality within the Mixpanel web application.

For example, if you are interested in using Mixpanel’s messages capabilities, you will need to include an $email property (not just email).

Other special properties include $first_name, $last_name, $username, and $phone. Ensure that if you’re adding any of these values that you enter the column headers with the dollar sign and name so that Mixpanel recognizes them as a special or reserved Property.

Note thata '+' needs to precede phone numbers. This is especially useful for international numbers.

Duplicate Profiles

If you import user profiles using $distinct_id values that already exists, those profiles will be updated with the additional user profile properties in your CSV.

Mixpanel imports based only on $distinct_id and will not deduplicate user profiles automatically based on other properties, like $email or $last_name.

If you upload user profiles that have the same email address or the same name as existing user profiles, you will be uploading duplicates - they will not be combined.

Ensure that the users you’re uploading don’t already have a user profile before you import, and if they do, ensure that the identifier column matches the existing profile’s identifier.

Selecting a profile will display the identifier in the URL as the query parameter, such as "?distinct_id".

Change Profile Type

You can upload user profiles using the $distinct_id or group profiles using the group identifier.

To change the type of profile you are importing, select theCreate Profiledropdown and select the profile type.

Ensure that your CSV has the right identifier when you import profiles. Use the $distinct_id for users, and the group identifier for groups.

Advanced User Profile Imports

The CSV import wizard treats every property value as a string. This means lists (such as Push Notification tokens) and numbers won't be properly imported.

For more advanced user profile imports, we recommend sending updates to the /engage endpoint instead of using the CSV import tool.

Import Profiles to Create a Cohort

To upload a group of user profiles and easily sort them into a cohort, add avalue to the CSV which sorts the profiles into a cohort as a property. For example, give each profile the unique property of "Cohort = Android Users". Next, go to the tab to create a cohort as usual, and filter to user profiles with that property and save. This will create a cohort of users with that matching property.

Note that when creating cohorts this way, the cohort will remain static, meaning that it will not update over time like other cohorts as the property is unchanging.

Mixpanel's Insights allows you to analyze your user data as a current snapshot or as a trend over time. This article explains how to interpret an Insights report. Learn about Insights report basics here. Learn about how to build an Insights report here.

Visualization Tools

In addition to the stacked bar chart and stacked line chart, Insights has regular bar charts, line charts and a table view. Resize the columns in the bar chart in order to see more or remove detail.

custom properties

When breaking down results, click on a bar in the chart to either filter or exclude that property value. Filter zooms in on that property value, filtering the entire report to that property value. Exclude filters out that property value from the results.

Analysis & Value Settings

You can switch between Absolute and Relative totals by selecting the three vertical dots in the top right of the chart and selecting either # Absolute or \% Relative.

The Absolute view will show you, in numbers, your totals for different event counts. Relative view will display these counts as a percentage of the whole.

The Analysis options will determine the way the chart is calculated and visualized. The options are:

Linear: This is the standard view for the chart.

Rolling: Rolling analysis calculates the rolling average of the data set. A rolling average curve is a series of averages from subsets of data. Use rolling average analysis to remove noise or spikes from data and smooth out trends over time. Mixpanel calculates the rolling average based on the selected time interval (hour, day, week, month or quarter) for each data point in the graph.

Time Interval

Default Rolling Time Range

Hour

Last 12 hours

Day

Last 7 days

Week

Last 5 weeks

Month

Last 3 months

Quarter

Last 2 quarters

For example, if you make a rolling analysis query for the past 30 days, Mixpanel calculates the rolling 7-day average by default. The value reported at each day in the line graph is the average of the values from the 7 days leading to that day. In the case of the first 6 days in your selected time period, the 7-day-average calculation will include days before the selected time period.

Logarithmic: A nonlinear scale based on orders of magnitude, rather than a standard linear scale, so the value represented by each equidistant mark on the scale is the value at the previous mark multiplied by a constant.

Cumulative: Adds up the values of each point on the graph as it goes along, so the height of the line will increase over time.

Sorting

When you are viewing a bar chart, you have four different sorting options: A-Z Ascending, Z-A Descending, Value Ascending, or Value Descending. To switch sorting views, select the Events icon in the upper left hand of the report and select which view you would like to see.

Time Period Comparisons

Compare the current period of time to previous periods of time in order to track trends and growth in your product’s use. Compare traffic from a specific campaign period or event from one year to the next, or compare the success of that campaign to your normal traffic.

Note that if a data point for a previous year falls on a weekend, the data point is automatically moved to the next Monday to give a more clear picture of the data change from one year to the next.

Click on the Compare to past button at the top of your Insights graph and select the time period you wish to compare to. You can also select a custom date range.

The past data will appear as a striped bar, a dotted line, or an additional table column.

As you can see from this graph, there was significantly more activity in the top events for this company in the previous week than there was this week. This information can be used to diagnose the effects of major changes to the product. In this case, perhaps a change to the product made it less usable for customers, making the overall activity drop. Hover over a line on the graph to see details.

This makes it easy to see the actual difference in numbers between two time periods, including the percentage difference. This percentage difference is not available in tables.

Bucketing

Insights will automatically group your high-cardinality segments into ranges. Ranges cannot be manually edited. You can create to manipulate these buckets.

Annotations

In order to clarify the results in your Insights report add detailed annotations directly to the line chart. Annotations are tied to a specific date on the chart, rather than a specific data point on the chart.

Only project admins can create, save, and delete annotations.

To add an annotation, hover your mouse over the point on the chart you want to annotate, and click the blue + button that appears.Enter a description for the annotation, such as a holiday that occurred on that day or the end date of your fiscal year, then click Save. If you accidentally selected the incorrect date on the chart, you can edit the date and time of the annotation in this window.

View an existing annotation by clicking on the blue button containing “” found at the bottom of a report. You will be able to see who submitted the annotation.

Hover the cursor over the annotation to edit or delete it. Click on the pencil icon to edit an annotation, or the trash icon to delete an annotation. Add additional annotations to the same date by clicking Add annotation.

Analyze Time Periods in Reports

Analyze your data further by highlighting a specific time period in a report. If you would like to reset the report to the original time frame, select the Reset Zoom icon that appears in the upper right-hand corner of the chart.

Mixpanel Messages are automatically set up to be delivered only once to a user for a given campaign. Push notifications, however, are delivered once per device token stored on the profile. Each of your users may have more than one device they use to access your application. The device token is akin to a phone number; it tells Apple/GCM to which device they should deliver the message.

Multiple Device Tokens

A common reason a user can have multiple device tokens is if they use your app both on their phone and their tablet - in this case, barring any targeting restrictions by device, the user would receive your message in both places.

Multiple Reinstalls

Another culprit of seeing more than just a few device tokens on one profile can also be the user uninstalling and reinstalling the app multiple times. The result can look something like this:

using the $remove HTTP operation (scroll down to "Update Operations")

On each new app install, a new token is added to the user's Mixpanel profile. Then, when a push is sent targeted at this user, Mixpanel sends one message for each device token for the user.

Although Mixpanel marks the push notification as having been sentNtimes (Nbeing the number of tokens on that user’s profile), old tokens get invalidated when sending, so the end user would only receive the push notification once, although they will see it on each active device. Learn more about how Mixpanel manages push tokens when they are invalid or when the app has been uninstalled.

Multiple Users with the Same Distinct ID

One final cause of seeing many device tokens on one profile can be a problem with assigning the same distinct_id to multiple users ( what is distinct_id? ). If this is happening, you’ll want to take a close look at how you’re managing user identity to ensure each user profile has information for only one unique user - read more about managing user identity in Mixpanel.

Remove Push Tokens

There are two methods for removing push tokens from your profiles:removeAllPushDeviceTokensandremovePushDeviceToken. With these methods you can remove individual tokens from your profiles or remove all tokens from your profiles prior to adding a new token with theaddPushDeviceTokenmethod. You can also remove tokens.

Mixpanel Group Analytics allows behavioral data analysis at a customized group level (such asaccount, deviceor any other way you want to assess your business).

Historically, Mixpanel grouped events by a single identifier called the distinct_id. This ultimately grouped events by the individual user. Group Analytics allows you to use an identifier other than the distinct_id, such as company ID, account ID, project ID, or billing ID.

Group Analytics is available as an add-on package to customers on Enterprise plans. Reach out to your Customer Success Manager or the Mixpanel Sales Team ( via Contact Sales on the pricing page )to enable Group Analytics in your reports.

Group By a Custom Identifier

Mixpanel Group Analysis allows you to select alternative unique identifiers in reports.

By default, Mixpanel counts unique users by distinct_id. Group Analytics allows you to uniquely count events by an alternative identifier, such as company ID, invite ID, or another value shared by a group of individualswith different distinct_ids.

This allows behavioral analysis from a business or group level, as opposed to an individual level. You can answer questions such as:

What companies are engaging the most with a product?

In instances where there are more than one user per account, such as a video streaming service, how are events triggered at an account level?

What groups convert through a funnel to a goal event (as opposed to what individual users convert)?

Group Profiles

Much like a user profile, Group profiles are a collection of properties and event history specific to a group.

Group Profiles have an activity feed that shows the events performed by users in a group, and it displays the properties unique to that group.

Follow the instructions here to learn how to upload Group Profiles using the Explore report

To access a group profile:

1- Go to Explore (under the “Users” icon on the main navigation menu).

2- Click the Analyze uniques by dropdown above the query builder.

3-Select the group identifier.

4- Groups profiles will populate the Explore report.

Example Use Case

An example use of Group Analytics is a business to business (or B2B) software company. Most B2B companies measure important KPIs at the company level instead of the individual user level.

The company might want to know how to target their customers for plan upgrades. When looking at potential targets for plan upgrades, the company can group by “Company Identifier” and target companies that use the product the most, as opposed to individual users.

This allows for the identification of companies that exhibit high likelihood of upgrading their plan, as opposed to individuals.

Change the Group Identifier

Choose a group identifier from a Mixpanel report. Note that you must have purchased the Group Analytics package in order to access the group by identifier.

To change the identifier in a report:

1. Go to a report.

2. Click the Analyze uniques by dropdown above the query builder.

3. Select the group identifier.

4. The report will now display results grouped by the newly selected group identifier.

Implementation

To view the set up guides for Group Analytics, follow the instructions connected to the library you are using found in Mixpanel's Developer Documentation.

HTTP

Javascript SDK

iOS-Swift SDK

iOS-Objective-C SDK

Android SDK

Java

Python

Ruby

Group Keys in Project Settings

Group keys are project specific, and the group key should be set up before group data is sent. Note Mixpaneldoes not backfillhistorical data before the group key was implemented.

Group keys must be event properties. All events need to have a defined group key on them in order to be attributed to a group.

To administer group keys, navigate to your Project Settings. Click+Add Group Keyunder theGROUP KEYS section.

Enter an event property to attribute the group key to. You can also enter a display name for the group key. ClickSave.

Upload Group Profiles Using Explore

It is possible to create Group Profiles by CSV upload as an alternative to the groups API. .

The Insights report is the default report all users see when navigating into Mixpanel. This report gives users a powerful tool for exploring their data. The series of videos presented here is meant to give an in-depth look into the different features available, helping users quickly get up to speed on what is possible in Insights.

Total Duration: ~30 minutes

Introduction

Topics Covered:

Course expectations

Lesson topics

Video Transcript

Hey everyone. My name is Mikey and I am a product trainer here at Mixpanel. In this series of videos, we are going to take an in-depth look at the Insights report. The Insights report is one of the primary reporting tools used for exploring your data. It can be used to analyze your data in a variety of ways including segmentation, charts, graphs, and formulas.

Before we get too far into the material I want to take a minute to go over some course logistics and see what we will be getting into.

The goal of this course is simple, to help you become an expert in building reports using Insights. By the end of this course, you will be familiar with the various options available in the query builder as well as the different visualization tools we have in the report.

I’ve broken down the material into a series of videos that allow you to easily jump to the sections you are interested in. Under the video in each section, you will see a brief list of the topics discussed with links to help quickly navigate to that section of the video. I will also include some links to additional help material for topics I mention but may not cover in complete detail.

As you can see we have quite a bit of material to cover but before we get started I want to take a quick look at the project we will be working out of, Music Finder. The Music Finder application is a simple hypothetical music streaming service where users first need to sign up and then they can play or purchase songs and albums. The Music Finder project we will be using is pre-populated with user data from this hypothetical app.

And with that, let’s go ahead and dive into the Insights report!

Query Builder

Topics Covered:

Selecting events and people properties

Function dropdown menu options

Breaking events down

Comparing events

Filtering

Time selection options

Reset your query

Video Transcript:

Let’s start our discussion of Insights with a brief description of how the report is structured.

When we hop into Insights, we can see the interface is broken down into two main sections. The top section is the query builder - this is where we will be selecting the data we want to take a look at. Here we can select from the different events, properties, and date ranges available in our Mixpanel project. The bottom section is where we will see the results of our query and where we choose how to view the selected data.

Initially we are met with a default query. The default query for Insights consists of our Top Events in the past 30 days. Top Events will display up to the 12 highest volume events for the time period selected.

Now that we have an idea of how the report is generally structured, let’s start with how to build our own custom query.

To begin building a custom query, we first need to select the event that we want to see. Clicking the current queried event will bring up a drop-down menu that contains the event and user data in our project.

Event data consists of the events and event property information sent to Mixpanel whereas users will contain any people properties we have set for users in people profiles. Any custom events created will also be available for use in analysis under the event tab.

Let’s say we are interested in the Song Play event. We can select this event from the dropdown menu or search for it by typing in the event name. With the event selected we see that we are looking at the total number of Song Play events in the past 30 days. Total here means that this is looking at all instances of the event, regardless of who triggered it. In this case, there were around 1700 Song Play events triggered in this time period total.

There are several other ways we can choose to analyze the Song Play event information in Insights. The function dropdown menu will reveal these options. They are Unique, Average, Median, Min, Max, Daily Active Users (DAU), Weekly Active Users (WAU) and Monthly Active Users (MAU). Uniques represents the number of users who triggered an event and is based on an identifying property, by default Mixpanel uses the distinct_id as this identifying property for uniqueness.

As we saw there was a total of roughly 1700 Song Play events in the past 30 days. When we change the total value to uniques we can see that 100 unique Song Play events are tallied. Another way of thinking about this is that 100 users triggered 1700 Song Play events in the past 30 days. The average option shows the average number of times an event was triggered by an individual user or the total number of Song Play events divided by the unique number of Song Play events. In this case, averaging to about 17 songs played per user.

The concept of uniques extends to the Min, Max and Median options as well. Each of these options look across all the unique users who triggered an event. Max will look for the user who triggered that event the most and then return the number of times the event was completed by that unique user. Min works similarly for the user with the minimum event triggers and median returns the median value across all unique users.

The daily, weekly, and monthly active users options will automatically create a line chart that calculates the number of unique active users for each time intervals (the day, week, or month) of the date range selected. For more information about how these values are calculated please check out our help documentation.

Let’s stick with the total number of Song Play events and go ahead and dig into this data a bit more. The Insights report gives us two options to take a closer look at our data, Breakdown and Compare. The Breakdown option will allow us to group the data by the event properties, people properties, or even the different cohorts we have set up. For the event and people properties, if the property values stored are the same they will be grouped together in the report. The cohorts option lets us compare users in the selected cohort to all users. Let’s use breakdown to take a look at the different Genres for the Song Play event and then also group these events based on the Plan Type the user has using the Plan Type people property.

Just a quick note, you may have noticed, when hovering over these properties we can see some information about the event displayed next to it. This information stems from the projects Lexicon which can be found under the Data Management tab. Lexicon is a great tool that can be used to keep Mixpanel data clean, organized, and easy to use and I highly recommend taking some time to check it out in your own project when you have an opportunity.

Back to our Insights query, when hovering over the event and properties selected, we see that it is possible to change the breakdown order for the properties and to remove properties or events with the options presented next to the event or property in the user interface. Let’s move the Plan Type property breakdown in front of Genre. We see that the order of the broken down results below has changed corresponding to this move. Next, let’s remove the Plan Type breakdown entirely.

As mentioned, we can also breakdown by our Cohorts. For this example, let's look at our New Users Cohort. When breaking down by a cohort we have the option to look at users who are either in or not in the Cohort and Mixpanel will display our selected Cohort’s results and as well as results from All Users.

We can take this query a step further and see how the Song Play event compares with the Song Purchase event using the Compare option. The properties we are breaking the Song Play event down by are now also applied to the Song Purchase event. And with just those few clicks, we can see which genres of music our users are playing the most and compare this to the song purchase habits of our users.

Now imagine we want to focus in on a specific subset of this data. Mixpanel gives us the ability to do this with the Filter function. In the Filter menu we see that it is possible to filter by either a Cohort or an event or people property defined in our project. Here we can filter by the Plan Type property where the value is equal to Premium to see Song Play and Song Purchase instances where these events were performed by users on a Premium plan. Then we can remove the New User Cohort breakdown and add an additional filter to see only users in our New User cohort.

Next, let's take a look at the different options available in the time selector. Currently, this is set to the past 30 days but in this menu we see a variety of pre-set options and the option to select a date range. The select date range menu opens up some additional options, in the last, between, since, and on. In the last will allow us to make a time range similar to the default in the last 30 days but it gives the option to choose the time value and scale ranging from hours to days, weeks, or months.

The between option allows us to specify two dates to query between. There is also the option to make this a rolling date range meaning the dates used will adjust relative to the current day so if today we set the date range to be between 1/3/19 and 1/7/19 tomorrow the report will query between 1/4/19 and 1/8/19.

Since and on a date both function as they sound. Since will query the data collected on or any time after the date selected and the on option will query only the data collected on that specific day.

One final piece of the query builder to be aware of is the small x seen in the top right corner. This is the reset query button and it will completely clear the query we have been working on to give us a brand new Insights query to work with.

Advanced Queries

Topics Covered:

Mixpanel data types

Different filter options

Typecasting

Summing properties

Numeric operator dropdown options

Video Transcript:

In this video, we will be looking a bit deeper into some of the features available in the Insights report. The features we will be looking at here can be used to help with things like correcting small errors in data from an implementation mistake or finding total time or revenue recorded by a specific event.

Let’s begin by taking a closer look at event and people properties and how they can be manipulated when filtering and breaking events down but before we jump back into the Insights report we need to take a quick look at the different data types Mixpanel uses.

Mixpanel supports 5 different data types, strings, numeric values, booleans, dates, and lists. Mixpanel handles each type of data a little bit differently when breaking them down and each data type has its own different set of filter options available in the UI. There are sometimes instances where we would want to use the filtering options available with one data type even though the data is being sent into Mixpanel as another type or we may want to change the way Mixpanel displays data in our report when breaking things down.

To handle cases like these, Mixpanel gives users the ability to typecast or change the type of a property from one data type to another. Let’s take a look at a few examples where typecasting can be really helpful.

Alright, now that we are back in Music Finder, we are going to take a look at the Album Purchase event to try and see what the prices are for the different albums being purchased. This event has the Price property associated with it sent in as a numeric value. By default for numeric properties, Mixpanel will look at the range of values for the property and bin the values into buckets. This behavior is not helpful in our case as we are interested in seeing the actual prices paid for each album instead of how many fall into the different ranges of prices.

Typecasting can help here because string data types in Mixpanel will display a property value exactly how it was sent to Mixpanel. Clicking back into the Price property we see the Typecast option. This will display the different typecasting options, String, Number, and True/False. If we select the string type we see that the Album Purchase event is broken down by the exact price of the album instead of being binned. If we were interested whether or not the property existed as a non-empty value on all Album Purchase events, we could use the True/False option. Typecasting to that changes the property to the boolean type, returning True if the property is set with some value and False if it is not set or has an empty value.

We can also typecast when using filters. Let's take a look at the Album Publish Date event property on the Album Purchase event. Here we have accidentally had sent this property to Mixpanel as a unix timestamp instead of the recommended YYYY-MM-DDTHH:MM:SS date format. Mixpanel will interpret the unix timestamp as a number instead of a date automatically and we will not be able to use date type filter options with the data as is. We can typecast Album Published Date to a Date type property by clicking the property name in the filter and then selecting Datetime from the dropdown. This will force Mixpanel to interpret the timestamp as a date and allow us to use the date filter options when working with this property.

Another advanced query builder feature to mention is the ability to sum numeric properties.

Going back to our Album Purchase event with the Price property, let’s say we want to know the total revenue from albums purchased in the month of March. In Insights it is possible to sum numeric event or people properties. For people properties, we can select the property under the user tab. For event properties, search for the event that the property is on, in this case, Album Purchase and when hovering over that event there is the Properties button on the right-hand side. Clicking into properties lets us select the property we want to sum.

By default we see the total sum of each Price property value across all Album Purchase events in the time period selected. In the numeric operator dropdown menu we get some different options including Average, Median, Min, Max, P90, or P99. Each calculates what the name implies based on the event or people property selected. P90 and P99 refer to the 90th and 99th percentile of the data respectively.

Formulas in Insights

Topics Covered:

Formula building

Arithmetic options available

Visualizing multiple formulas

Video Transcript:

Hey everyone. In this video, we are going to be taking a look at the formulas functionality in our Insights report. This tool will allow us to create some pretty cool custom formulas using simple mathematical operators and the event or people data in a project. Let's go ahead and dive into our Music Finder project to see how formulas in Insights works.

To create a formula in the Insights report we first want to select the events or people information to use in the formula. In this example we will be looking at two events, “Song Play” and “Song Purchased”.

Once the events of interest are selected we can create a new formula by clicking the Add Formula button seen here. In the Formula builder, we reference the events as variables in the formula using the letters seen just to the left of the events. Mixpanel formulas will allow us to use simple arithmetic operators like Addition (+), Subtraction (-), Multiplication (*), and Division (/). We can also use parentheses to determine the order of operations if need be.

Let’s say we are interested in the ratio of the number of songs played to the number of songs purchased. We input the formula using the variable letters and then can give the formula a name to display in the report. If no name is given, it will default to the formula we entered. We can use numbers as constants in formulas as well, for example, if we wanted to view a ratio as a percentage we can multiply by 100.

Now we can see the formula we created below displayed in the Insights report. We can dig deeper and break down the formula by a property to see how this ratio compares across different values. Filters can also be applied to display a particular value of interest.

We can display more information like the raw events numbers or additional formulas using the Add Formula button. These formulas can use some of the different visualization options and can be added to the Dashboard or Saved for easy viewing later.

And there you have it, formulas in Insights.

Visualization Options

Topics Covered:

Compare to past

Bar chart

Analysis Options

Value Display Options

Line chart

Annotations

Drill down (zoom) into chart

Pie chart

Table view

Video Transcript:

Now that we have seen how to build different queries in the Insights report, let’s take a closer look at the different options available to customize the way we are viewing our data. By default, the Insights report will display as a bar chart with events listed in descending order based on event volume. As we will see, there are a lot of different ways to view our data in Mixpanel so let’s dive in.

First let’s take a look at the Compare to past feature. Compare to past will allow us to look at data from two different time periods on the same chart. The Compare to past menu gives us several preset options and the ability to select a custom date range for comparison.

The date ranges used for the comparison are based on the time period selected in our queries time section. For example, imagine today is 2/11/19 and we are looking at the top events for the past 30 days and we selected the compare to the previous week option, the initial query would be looking at the 1/12/19 to 2/11/19 time period and the compare to past query would be from 1/5/19 to 2/4/19 - still a 30 day time period but with the starting and ending dates a week prior to the initial query. Hovering over the results in the chart will display the starting and ending dates for the query being made. The Compare to past feature is available when using the bar, line, and table views in Insights.

Now let's take a closer look at the different chart types available in Mixpanel. Starting with the bar chart, we have the option to create a regular or stacked bar chart. Hovering the cursor over the bar will give us some details about the property or event we are viewing like the event name, absolute count and relative percentage. If we want to change the order in which results are displayed there are some different sorting options available. We have the option to sort based on alphabetical order or the value associated with the event or properties being used. These columns can also be resized by dragging the column border. The column with Linear in the title is where the analysis type is displayed. It is possible to change the sorting order based on value when we click this column header.

The three vertical dot menu in the right-hand corner of the analysis type column header will display an additional menu that will allow us to select from the different analysis types and choose the way our values are displayed.

The analysis options will determine the way the chart is calculated and visualized. The options are Linear, Rolling, Logarithmic, and Cumulative.

Linear is the default value and uses a standard linear scale, increasing at a regular interval. When using the Rolling option Mixpanel will calculate the rolling average based on the chosen time units (hours, days, weeks, months) for the entirety of the viewable date range in the graph. This analysis type is good for removing spikes or noise from data. Logarithmic is a nonlinear scale based on orders of magnitude so each equidistant mark on the scale is the value of the previous mark multiplied by some constant. Mixpanel uses a base of 10 for its logarithmic option. Finally there is the Cumulative option which adds the values of each point up as the graph moves along, resulting in a line that increases over time. The Bar chart can only use the Linear and Logarithmic options.

For the value display, there is the option to view the results as the absolute number or a relative percentage. The absolute number shows the numeric value of the different event or property values chosen. The relative percentage will show the percentage of the whole that each value represents. Looking at our example query of Song Play broken down by Genre in the past 30 days, we can see that there were 1702 songs played total and of those 1702 songs 559 were in the Rock genre. The absolute number would be 559 but the relative percentage would be (559/1702) * 100 or 33 percent of Song Play events in the last 30 days were Rock songs.

The final piece of the bar chart UI to look at is the legend. The legend will appear when we use the Breakdown option and it will list the different values for the properties in the breakdown. In our current example, we have the Song Play event broken down by Genre. Let’s remove the Genre breakdown and use a higher cardinality property like Email.

Now we see that the chart is limited to 24 different bars by default. We can remove results from the chart by unchecking the box or we can use the More option and check additional boxes to add more results to it. The unchecking of the boxes in the legend to remove property values will not persist in saved reports or if the report is reloaded.

To remove a value in a method that persists beyond this page we would need to add a filter. The bar chart legend has a cool little feature that will allow us to quickly make a filter from the legend by clicking the x that appears next to the value when hovering over it. As we can see a filter for email does not equal [email protected] has appeared in the query builder.

The next chart type is the line chart. With the line chart we have the option to view the data as a regular or stacked line. The line chart behaves a bit differently from the rest of our visualization options in that it shows the data aggregated in increments of hours, days, weeks, months or quarters in the time period selected, instead of summed into one value for the entire period. For example in the chart here, we are looking at the data from the past 30 days but instead of the aggregate number over the entire 30 days we see the number of Song Play events for each individual day over the past 30 days. To change the time increment used in the Line chart we select the value from the drop-down here. Changing this value to weeks, now each week's totals are calculated.

This behavior is especially important when looking at unique values. Imagine we are still looking at data over the past 30 days, with the bar chart Mixpanel will look at all users across the entire 30 day period and count how many unique users there are for that event. If we changed to a line chart for the same 30 days with a daily interval, Mixpanel instead looks at each individual day in the past 30 days and counts how many unique users are present on each day. This means that each day the unique count is reset so the same user can count on two separate days. For example, a user could do a Song Play event today and yesterday and will be counted on each day as a unique user in a line chart, as opposed to one user over the entire 30 days in the other charts. This means summing uniques from each day in a line chart would not be the same thing as looking at uniques looking across the 30 day period as a whole.

With the line chart we again have the option to sort the events and properties from the analysis type column and this time all four analysis options are available in the three vertical dot menu.

There two line chart specific features to mention as well, the ability to add annotations and zoom in on sections the chart. Annotations allow us to add a note to a specific datetime in the line chart. These can be added by hovering over the date values on the x-axis and clicking the blue plus symbol that appears. From there we can select a date and time the annotation should apply to and then add a description. An important note here is that only users with project admin access or higher will be able to create, save and delete these annotations.

With the line chart, we may want to take a closer look at certain sections of the chart and this is where the zoom feature comes in handy. To zoom into any part of the chart quickly we can click on the chart where we want the new starting point to be and drag the cursor to the stopping position like so. To zoom back out we just click the reset zoom button that appears in the right-hand corner. This is a great way to view a time period in greater detail without having to go back to the query builder and change the time selection.

Next up is the pie chart visualization. The pie chart will show up to 20 different segments in the chart by default. As with the other visualization options, the legend appears when using the breakdown option and we can again add additional segments by clicking the More button and checking additional values. The hiding of segments is a bit different in that unchecking the value in the legend means that value will be added to the Other section of the pie instead of removed from the chart. A filter needs to be added if we did not want the value to appear in the results at all.

The number in the center of the pie chart represents the sum count of the different events being looked at. So for example, right now we are looking at the total number of Song Play events in the past 30 days, 1702 as seen here. If we were to compare another event in the query, lets say total Song Purchased, then the middle number would be the total Song Play event count plus the total Song Purchased event count, or 1702 + 319, for a total of 2,022. Like the bar chart, hover over the slice of the pie to get more information like exact count, the relative percentage of the pie chart total, and the event or property name that portion represents.

Last but not least is the Table view. As the name implies this shows the data in a table and is great for viewing high cardinality properties as we are able to view many more unique values in this view than the others. Sorting data alphabetically and by value is still possible but in this view, we just need to click on the column headers. If it is a text column it will sort alphabetically and for numeric entries, it will sort by value.

Saving and Downloading Insights Reports

Topics Covered:

Saving reports

Adding to dashboards

Exporting data

Video Transcript:

At this point we have spent some time building the right query and have configured the visualization options to our liking to get that perfect Insights report. After spending all that time and effort building a report we want to make sure we don’t have to go back and do this again every time we want to see this particular data.

We can save reports in Insights by typing in the name we want for our saved report in the box seen here. As an example let’s look back at the total revenue on the Album Purchase property from one of our previous videos. We quickly create this report with the Price property on the Album Purchase event and let's make it a line chart to see how revenue varies daily. Now we will want to save this report so we can quickly return to it.

Let’s give the report a descriptive name, Album purchase revenue - past 30 days and then click the save button when we are done. The saved Insights reports can be accessed via the Saved Reports button in the top right-hand corner of the report here. We can make changes to the report and Save it again from where the report name is set or we can have the altered report be a new saved report with the Save new option.

Insights reports can also be added to the Dashboard for quick access and viewing. Adding reports to the Dashboard can be done by clicking this button and selecting or creating the Dashboard we want to add the report to. Think of the dashboard as a place to view important metrics at a glance and quickly navigate to those reports should we want to take a closer look.

In addition to being able to save reports, we also have the ability to export results directly from the Insights report. The Download button gives three options, Download PNG, Download PDF, and Download CSV. The Download PNG and Download PDF options will create a screenshot of the report and download it in the format mentioned.

The Download CSV option will allow us to download the results of Insights reports in CSV format. This feature is particularly useful when working with higher cardinality properties that may be difficult to view in the UI. The API used to build reports is limited to 10,000 unique rows of results so if we were working with extremely large datasets it may be necessary to try and break the data up into chunks with smaller date ranges or look into using the JQL tool to export the results.

Wrap Up and Course Feedback

We have reached the end of our deep dive into the Insights report. I hope after watching these videos you feel that you have a good grasp on the different features available in Insights and how to use them.

Please use the buttons below to let us know whether or not you found this course helpful. If you would like to provide any further feedback on this course, or if you have any suggestions for additional training resources, please reach out to us at [email protected].

Thank you for watching and best of luck as you continue your Mixpanel journey!

Identity Merge is currently in closed BETA and is subject to change.

Identity Merge (ID Merge) is an updated version of Mixpanel’s identity management services. It is designed to address the challenges customers face when using previous versions of Mixpanel’s identity management.

This article covers the improvements to Mixpanel's identity management infrastructure and the new tools available that will make implementation easier.

Benefits of the New System

Mixpanel has made several changes to how identity works in Mixpanel.

All pre-authentication activity can now be mapped back to a user

Previously, Mixpanel could only map pre-sign up activity back to a user who was later identified. This only worked once. Any activity a user did anonymously before signing in again could not be attributed to that user. The new system makes it possible to connect all pre-authentication activity back to an authenticated user - regardless of what device they are on or when they register.

Merge data with different unique identifiers

Mixpanel could not merge events with different unique identifiers. The new $mergeevent and the existing identify and alias methods can now merge event streams under a single user, even after data has been ingested.

Enable ID Merge

You can see if your project has ID merge enabledby checking for the id merge toggle in Project Settings. If you wish to add an additional project to ID merge, email [email protected].

here

For client-side implementations, make sure your SDK version is up to date so ID merge works when turned on. ID Merge is compatible with:

Javascript: 2.29.0+

iOS - obj: 3.4.7+

iOS - swift: 2.6.3+

Android: 5.6.3+

Unity: 2.0.0+

You don't need to change anything if you already have a Mixpanel implementation with a functioning identity management system.

Changes After Enabling ID Merge

The following is a list of expected changes after enabling the ID merge feature.

New events will show up in your project

Mixpanel will track new events the identify or alias methods are called in your implementation. These events do not count towards billing

Unique user counts may decrease, user profile counts may decrease

Since ID Merge can merge already ingested events together under a single user, you may notice a change in the unique counts of events in your project. If a user profile exists for multiple distinct ids that are merged, Mixpanel will hide all but one of the user profiles.

Monthly Tracked User (MTU) tallies may decrease

The MTU billing system is based on the number of users you track with Mixpanel. Since ID Merge is able to map user activity together more effectively, you may notice a decrease in your MTU count. Note: Previously months billing tallies will not be modified.

You can no longer control the canonical id for users in Mixpanel

The ID Merge system will now determine which distinct_id is used as the canonical id for a user in Mixpanel. Any merged id can be used to query for information about a user with our APIs, but the results of the query may return a with different distinct_id value than the one used in the query. The id that is returned is the canonical id determined by Mixpanel for that user.

To ensure the queried id is available in the results, it is best practice to send your chosen user id in as an explicit property for events and profiles.

Avoid using non-Mixpanel generated anonymous ids

The updated identify and alias methods come with some built in guardrails to help avoid users sharing a device from being incorrectly merged together. These guardrails rely on anonymous activity using Mixpanel generated distinct id’s. Whenever possible use Mixpanels built in SDKs to generate anonymous distinct id’s to allow for correct merging behavior. Note: We’ve worked Segment to ensure their anonymous id’s are compatible with our new system.

User profiles will not automatically aggregate all user properties when merged

This will mainly affect implementations that have duplicate or anonymous user profiles.

ID merge will map events from merged ids together. When this happens, Mixpanel will display the profile with the Mixpanel determined canonical id. User property values will not be updated or added based on other profiles merged. To avoid losing profile properties, we recommend creating user profiles after a user has been identified.

Distinct_ids cannot be un-merged

Merged distinct IDs cannot be unmerged.

$merge Event

The $merge event will merge the event histories of two unique IDs. If one or both are already merged with data tied to other IDs, then the result will be the merge of all data of the IDs.

Note: merge is a very powerful tool, so we will only accept merge events that are sent via https://api.mixpanel.com/import, which is protected by the project api secret. See for how to send events to Mixpanel via the import endpoint.

Event properties

Property name

Type

Description

$distinct_ids

List

required

A list of two distinct_ids that you would like to merge together. There must be exactly two IDs in the list.

token

String

required

The project token. If using an off-the-shelf SDK this should be included for you automatically.

Example

{

event: '$merge',

properties: {

$distinct_ids: ['B55CAFBF4708C950', 12345],

token: 'e3bc4100330c35722740fb8c6f5abddc'

}

}

Mixpanel’s client-side libraries send user location data (city, region, country) as Properties by default. Mixpanel pulls the user’s IP address and runs it through a third-party IP geolocator (MaxMind). MaxMind then returns city, region, and country, and Mixpanel sets those as Properties. Then, the IP address is discarded - Mixpanel does not store users’ IPs.

In order to disable or anonymize geolocation data (i.e., not send city, region, and country by default when using a client-side library), you simply need to stop collecting the user’s IP, which will then not populate the city, region, and country properties. At this time, there is no way to selectively disable one or two of the three location default properties. However, you could disable the three default properties and then set your own custom property for the one or two that you’d still like to collect.

JavaScript

If you don’t want Mixpanel to set city, region, and country by default, you can change the config via your init. This will not collect IP and therefore not populate city, region, and country default properties:

mixpanel.init("YOUR_TOKEN", {'ip':false})

iOS

To disable IP collection on iOS, make a small change in the Mixpanel library installed on the app, changing:

useIPAddressForGeoLocation = YES

to:

useIPAddressForGeoLocation = NO

Android

To disable IP collection on Android, set useIPAddressForGeoLocation to false (NOTE: only available on Android SDK versions > 5.2.0 ):

<meta-data android:name="com.mixpanel.android.MPConfig.UseIpAddressForGeolocation"

android:value="false" />

Mixpanel supports individuals’ right to control their personal information. Tools are available to Mixpanel users that help end users access their own data. This includes the ability to specify whether or not end user data is collected by default, and the ability to opt users out of Mixpanel tracking at any time.

It is important to consider how to manage the opt-out state of users across platforms when designing a tracking implementation. While Mixpanel provides the tools necessary to control a users’ opt-out state, proper design can maximize the number of users consenting to tracking while respecting individuals right to control their personal information.

Opt Users Out of Tracking

Client Side Implementations

It is possible to manage opt-out state of end users in Mixpanel’s client side libraries through the use of Mixpanel opt-out methods.

No data will be sent for users from a particular Mixpanel instance that has a local opt-out state of “true.” Use Mixpanel opt-out methods to toggle the opt-out state for a particular user either to “true” (data is not tracked) or "false" (data is tracked).

Mixpanel opt-out methods control data that is sent out from a particular tracking implementation located on an end-user’s device. In order to prevent data from a particular user being sent to Mixpanel, that user must be opted out of tracking on every platform from which data is sent (i.e. from a mobile device and a web browser).

You can read more details about how to opt individual users out of tracking in Mixpanel’s developer documentation:

JavaScript

Objective-C

Swift

Android

Server Side Implementations

The exact conditions under which data is sent to Mixpanel server-side is custom configured by the developer of a server side implementation. Controlling an end user’s opt-out state must be built into the tracking logic. The implementation developer should configure Mixpanel data collection methods so that they run only when data should be sent to Mixpanel.

Opt-In Event

An "$opt_in" event is created by default whenever a user opts into tracking. This event is tracked with the default Mixpanel properties.

It is possible edit the properties that send with an "$opt_in" event. View the developer documentation for additional information on configuring opt out methods.

Best Practices for Managing Cross-Platform Opt Out States

It is important to manage the opt-out state of one user across devices if Mixpanel is implemented using multiple platforms. General guidelines to help manage a user’s opt-out state on a multiple platform Mixpanel implementation include:

Set up a single source of truth for a user’s opt-out state. It is important to update all Mixpanel instances to reflect a user’s current opt-out state. All changes should be made based on a single point of reference that stores the user’s opt-out preference.

Flush the tracking queues on the user’s device to send previously-collected data to Mixpanel before setting a user’s opt-out state. This will allow you to collect data cached on the device before a user opts out.

Unsubscribe users from emails or other messages before opt-out.

Delete the user profile after opt-out.

"Do Not Track" Settings

Follow the instructions in this guide to prevent your browser from sending data to Mixpanel.

Mixpanel toggles tracking according to " Do Not Track "(DNT) settings in web browsers. If the DNT setting is set, then Mixpanel won’t collect information from that Mixpanel instance.

DNT settings apply to a particular browser instance -- moving to a different browser that does not have DNT configured may cause data to be collected. In addition, DNT applies to web tracking only -- data may be collected and sent to Mixpanel on mobile apps or other platforms that run Mixpanel outside of a DNT-configured web-browser. These platforms must be configured by the platform developer with logic to opt-users out of tracking using the opt out methods outlined above.

Javascript Engagement

City($city) - The city of the event sender, parsed from IP.

Region($region) - The region (state or province) of the event sender, parsed from IP.

Country(mp_country_code) - The country of the event sender, parsed from IP.

Browser($browser) - Browser name (not versioned).

Browser Version($browser_version) - Browser version number.

Device($device) - The name of the event sender's device, if they're on mobile web.

Device ID ($device_id) - Aunique string that identifies a user before an authentication or identification flow. By default,Mixpanel's client-side SDKs generate a $device_idfor every unique browser or device. If using a client-side SDK, the $device_id is an event property that won't need any additional work.The $device_id does not change on the same device.

User ID ($user_id) - Aunique ID that mixpanel.identify() sets. The $user_id value should be constant. Values that change makes it more difficult to track users. mixpanel.identify() does not work with server-side implementations. As a result you must set $user_id directly to work in server-side implementations.

Current URL($current_url) - The full URL of the webpage on which the event is triggered.

Initial Referrer($initial_referrer) - Referring URL at first arrival.

Initial Referring Domain($initial_referring_domain) - Referring domain at first arrival.

Operating System($os) - OS of the event sender.

Mixpanel Library(mp_lib) - Mixpanel Library that sent the event.

Referrer($referrer) - Referring URL, including your own domain.

Referring Domain($referring_domain) - Referring domain, including your own domain.

Screen Height($screen_height) - The height of the device screen in pixels.

Screen Width($screen_width) - The width of the device screen in pixels.

Search Engine($search_engine) - Search engine a customer used when they arrived at your domain.

Search Keyword(mp_keyword) - Search keywords detected on the referrer from a search engine to your domain. This property is only collected when search keywords are included in a URL.

UTM Parameters(utm_source, utm_medium, etc.) - Any utm tags associated with the link a customer clicked to arrive at your domain. Each utm will be collected under its own property. Mixpanel only tracks first touch UTM parameters by default.

Processing Time(mp_processing_time_ms) - Time in milliseconds in Unix Processing Time when an event was ingested by Mixpanel.While the "Time" property in Mixpanel is set in the time zone specified by the project,mp_processing_time_ms will always be in UTC (GMT) time.

Insert ID ($insert_id) - A random 16 character string of alphanumeric characters that is unique to an event. Mixpanel uses $insert_id to deduplicate events.

Javascript People

Default properties update within a profile whenever a property is set or updated with a mixpanel.people.set() call.

City($city) - The city of the event sender, parsed from IP.

Region($region) - The region (state or province) of the event sender, parsed from IP.

Country($country_code) - The country of the event sender, parsed from IP.

Timezone($timezone) - Timezone of the event sender, parsed from IP.

Browser Version($browser_version) - Browser version number.

Browser($browser) - Browser name (not versioned).

Initial Referrer($initial_referrer) - Referring URL at first arrival.

Initial Referring Domain($initial_referring_domain) - Referring domain at first arrival.

Operating System($os) - OS of the event sender.

Last Seen($last_seen) - The last time a user profile property was set or updated (should not be set manually).

iOS Engagement

City($city) - The city of the event sender, parsed from IP.

Region($region) - The region (state or province) of the event sender, parsed from IP.

Country(mp_country_code) - The country of the event sender, parsed from IP.

App Build Number($app_build_number) - General build of this app.

App Version($app_version_string) - Current app version.

$app_release- Deprecated

$app_version- Deprecated in favor of$app_version_string

Carrier($carrier) - Wireless carrier of the device owner.

iOS Version($os_version) - Current version of iOS on the device.

Manufacturer($manufacturer) - Always Apple (so far...).

Lib Version($lib_version) - Mixpanel library used to send this data.

Mixpanel Library(mp_lib) - Mixpanel Library that sent the event.

Model($model) - Device model ID, in format "iPad 3,4". Full list here.

Device Model(mp_device_model) - Legacy device model ID, same as $model.

Device ID ($device_id) - Aunique string that identifies a user before an authentication or identification flow. By default,Mixpanel's client-side SDKs generate a $device_idfor every unique browser or device. If using a client-side SDK, the $device_id is an event property that won't need any additional work.The $device_id does not change on the same device.

Operating System($os) - "iPhone OS" (outdated naming convention).

Radio($radio) - Current cellular network communication standard (3G, 4G, LTE, etc).

Screen Height($screen_height) - Height, in points, of the device screen.

Screen Width($screen_width) - Width, in points, of the device screen.

Wifi($wifi) - Set to true if Wifi is connected, false if not.

Processing Time(mp_processing_time_ms) - Time in milliseconds in Unix Processing Time when an event was ingested by Mixpanel.While the "Time" property in Mixpanel is set in the time zone specified by the project,mp_processing_time_ms will always be in UTC (GMT) time.

Insert ID ($insert_id) - A random 16 character string of alphanumeric characters that is unique to an event. Mixpanel uses $insert_id to deduplicate events.

iOS People

Default properties update within a profile whenever a property is set or updated with a mixpanel.people set call.

City($city) - The city of the event sender, parsed from IP.

Region($region) - The region (state or province) of the event sender, parsed from IP.

Country(mp_country_code) - The country of the event sender, parsed from IP.

Timezone($timezone) - Timezone of the event sender, parsed from IP.

iOS App Release($ios_app_release) - General build of this app.

iOS App Version($ios_app_version) - Full detail of this app build.

iOS Device Model($ios_device_model) - Device model ID, in format "iPad 3,4". Full list here.

iOS Lib Version($ios_lib_version) - Mixpanel library used to send this data.

iOS Version($ios_version) - Current version of iOS on the device.

Last Seen($last_seen) - The last time a user profile property was set or updated (cannot be set manually).

Total App Sessions -The total number of "App Session" events that the user has sent.

Total App Session Length-The total number of seconds that a user has spent using the app. This is calculated by adding the "Duration" property attached to the "App Session" event.

First App Open Date -The date the app was first opened on a user's device.

Android Engagement

City($city) - The city of the event sender, parsed from IP. .

Region($region) - The region (state or province) of the event sender, parsed from IP.

Country(mp_country_code) - The country of the event sender, parsed from IP.

App Version($app_version_string) - Current app version.

App Build Number($app_build_number) - General build of this app.

$app_release- Deprecated

$app_version- Deprecated in favor of$app_version_string

Bluetooth($bluetooth_enabled) - Set to true is Bluetooth is enabled, false if not.

Bluetooth Version($bluetooth_version) - Set to "none", "ble", or "classic".

Brand($brand) - Device brand.

Carrier($carrier) - Wireless carrier of the device owner.

Has NFC($has_nfc) - Set to true if Near Field Communication is being used, false if not.

Has Telephone($has_telephone) - Set to true if this device has telephone functionality, false if not.

Lib Version($lib_version) - Version of the Mixpanel library used to send this data.

Manufacturer($manufacturer) - Device manufacturer.

Model($model) - Device model.

Mp_device_model- Deprecated

Device ID ($device_id) - Aunique string that identifies a user before an authentication or identification flow. By default,Mixpanel's client-side SDKs generate a $device_idfor every unique browser or device. If using a client-side SDK, the $device_id is an event property that won't need any additional work.The $device_id does not change on the same device.

Mixpanel Library(mp_lib) - Mixpanel Library that sent the event.

Operating System($os) - OS of the event sender.

Os Version($os_version) - Current Android version for this device.

Screen DPI($screen_dpi) - Pixel density of the device screen.

Screen Height($screen_height) - Height, in pixels, of the device screen.

Screen Width($screen_width) - Width, in pixels, of the device screen.

Wifi($wifi) - Set to true is Wifi is connected, false if not.

Google Play Services($google_play_services) - Verifies that Google Play services is installed and enabled on this device, and that the version installed on this device is no older than the one required by this client.

Processing Time(mp_processing_time_ms) - Time in milliseconds in Unix Processing Time when an event was ingested by Mixpanel.While the "Time" property in Mixpanel is set in the time zone specified by the project,mp_processing_time_ms will always be in UTC (GMT) time.

Insert ID ($insert_id) - A random 16 character string of alphanumeric characters that is unique to an event. Mixpanel uses $insert_id to deduplicate events.

Android People

Default properties update within a profile whenever a property is set or updated with a mixpanel.getPeople().set() call.

City($city) - The city of the event sender, parsed from IP.

Region($region) - The region (state or province) of the event sender, parsed from IP.

Country(mp_country_code) - The country of the event sender, parsed from IP.

Timezone($timezone) - Timezone of the event sender, parsed from IP.

Android App Version($android_app_version) - Current app version.

Android App Version Code($android_app_version_code) - Current app version.

Android Lib Version($android_lib_version) - Version of the Mixpanel library used to send this data.

Android OS Version($android_os_version) - Current Android version for this device.

Android Brand($android_brand) - Device brand.

Android Model($android_model) - Device model.

Android Manufacturer($android_manufacturer) - Device manufacturer.

Last Seen($last_seen) - The last time a user profile property was set or updated (cannot be set manually).

Mixpanel's Insights allows you to analyze your user data as a current snapshot or as a trend over time. This article explains Insights report basics. Learn about building an Insights report here. Learn about how to interpret an Insights report here.

By default, Insights will show you the top events logged in Mixpanel in the last 30 days. You can choose to focus on a specific event, specific properties associated with that event, compare multiple events, or change the date range.

Insights removes limitations around data exploration by allowing you to keep choices (i.e. choosing to use breakdown or compare) independent of one another.

Access Saved Reports

Access saved reports by selecting the Loadbutton.

Pricing Page

View any of the saved reports of your team members or a list of your own saved reports.

Non-MTU Plan Limits

Free: Up to 5 saved reports

Startup: Unlimited saved reports

Enterprise: Unlimited saved reports

See our for more details.

In this webinar we walk through an entire Mixpanel implementation from scratch and highlight best practices along the way. The implementation shown in the webinar is built using the Mixpanel JavaScript library, however, the concepts discussed are relevant across the various integration libraries.

Duration: 1 hour

Webinar Recording

Mixpanel Personal Settings enables you to view personal details and make project changes including:

Viewingproject token, API key, and API secret.

Reset project API key and API secret.

Generate OAuth token for GDPR APIs.

Request or delete account usage data as part of a GDPR request.

Manage your Mixpanel activity.

Accessing Personal Settings

To access personal settings:

In the Mixpanel header bar, click the icon with your initials.

Under “PERSONAL SETTINGS”, click Profile & Preferences. The "PERSONAL SETTINGS" page displays as shown in the GIF below.

GDPR Compliance

Viewing Personal Details

View details about a person in the "Profile & Preferences" section. These details include general information, such as the name of the account holder and the name of the organization.

See the table below for descriptions of these details:

Field

Description

DETAILS

Name

The name of the organization's owner.

Email

The email address of the organization's owner.

Password

The password of the organization's owner.

Additional billing email:

An alternate email address to receive billing information.

Two factor phone number:

A phone number that receives a verification code bytext message or automatedphone call.

YOUR ORGANIZATIONS

Organization ID

The ID of the organization.

Organization Name

The name of the organization.

Organization Role

The role of the account holder listed above in the organization.

Viewing Project Token, API Key, and API Secret

In "Projects", you see each project in the organization. Each project contains values for its token, API key, and API secret. You can also reset the API Key and API Secret for each project.

See the table below for descriptions of these details.

Field

Description

Token

Your project token is used whenever you want to send data (events or users) to Mixpanel.

Your token is public, and is the only project-specific object required to send data to Mixpanel.

Since Mixpanel users can have multiple projects, and each project has its own project token, whenever you want to send data to a specific project, you'll need to specify the project token so we know where to send the data.

API Key

Your API key acts as both a unique identifier and a token for authentication. It will generally have a set of access rights on the API associated with it.

Your API key will correspond to the project you wish to consume from.

API Secret

This is a secret API key corresponding to your project. You should never share this API secret or send it over email.

You will use your secret to sign an API call, and it is required to extract data from your Mixpanel project.

Reset

The location to resetthe API Key and API Secret for the project. To reset theAPI Key and API Secret, see "ResettingProject API Key and API Secrets".

ResettingProject API Key and API Secret

Only project owners and project admins can reset the API Key and API Secret.

To reset theAPI Key and API Secret:

In the Mixpanel header bar, click the icon with your initials.

Under “PERSONAL SETTINGS”, click Profile & Preferences.

Click Project in the left navigation bar.

Select a project and click Reset in the "Reset" field.

The "Reset API Credentials" message asks if you're sure you want to reset the values, and possibly affect projects in production.

Click Reset. Mixpanel resets the values for the API key and API secret.

GeneratingOAuth Token for GDPR APIs

To generate an OAuth Token for GDPR APIs:

In the Mixpanel header bar, click the icon with your initials.

Under “PERSONAL SETTINGS”, click Profile & Preferences.

Click Data & Privacy in the left navigation bar.

In the "GDPR API" field, click Reset.

The "Reset GDPR API token" message asks if you're sure you want to reset the value and invalidate any application using it.

Click Reset. Mixpanel resets the value of the GDPR API token.

Requesting or DeletingAccount Usage Data

Mixpanel captures data about how customers use Mixpanel to inform decisions about product development and to improve services.

Mixpanel account holders can request to access or delete that data. Account holders can submit these requests to exercise their Right to Access and Portability, and their Right to be Forgotten as part of the General Data Protection Regulation (GDPR).To learn more about GDPR, see.

The request to export or delete account usage data can take multiple weeks to process.

To request account data:

In the Mixpanel header bar, click the icon with your initials.

Under “PERSONAL SETTINGS”, click Profile & Preferences.

Click Data & Privacy in the left navigation bar.

In the "YOUR MIXPANEL DATA " section, click RequestData.

A message displays indicating that Mixpanel has received the data request.

To delete account data:

In the Mixpanel header bar, click the icon with your initials.

Under “PERSONAL SETTINGS”, click Profile & Preferences.

Click Data & Privacy in the left navigation bar.

In the "YOUR MIXPANEL DATA " section, click DeleteData.

The "Erase personal data" message indicates that Mixpanel will erase all personal data it has collected. The account remains operational.

Click Erase Data.

A message displays indicating that Mixpanel has received the data request.

Managing Your Mixpanel Activity

You can permit Mixpanel to use cookies to personalize your Mixpanel experience and log your product usage to help Mixpanel improve products and services.

To permit either options, slide the button in each field to display green. Or slide the button in each field to display gray to prevent Mixpanel from using cookies or logging product usage.

Deleting Your Mixpanel Account

Under Personal Settings, there is an option for you to delete your account.

ClickDelete in "Personal Settings" to delete your Mixpanel account instantly. You will no longer be able to access any projects or organizations that you have access to after account deletion. Projects and event data in a project are not deleted when you delete an account.

You will be prompted to designate a new owner if you are the only owner in one organization and try to delete your account.

You can only delete your Mixpanel account once there is a new organization owner.

This article describes how to track the first time a user visits your website or app so you can derive metrics for new versus existing users.

First-time users arrive at your website or app for the first visit. It is important to distinguish first time versus returning users so you can answer questions, such as:

How do first-time users convert through sign up?

What is first-time versus returning user retention?

What traffic source do my first-time users come from?

The answers to such questions provide valuable product insight not readily available when analyzing all users simultaneously. Measuring first-time users gives you a granular view of what your users are doing when they have never used your website or app before.

You may find user experience insights that you cannot discover without analyzing these users.

For example, you might discover that most of your users do not sign up the first time they visit your site. This insight could mean your home page is too cluttered or your sign up process is not being emphasized enough, allowing you to make the necessary user interface tweaks to test the new layout for future first-time users.

Tracking First-Time Users

To track a first-time user in Mixpanel, specify an event and property combination that designates a first time user. To do this, attach a property to an event or set of events when first-time users perform them. In Mixpanel, super properties allow you to assign a property value to a user which accompanies all of the events they perform.

External Database

You can track first-time users directly using a list of all first-time users in a database.

The list is a record of each distinct_id that accesses your website on a separate database. Whenever you encounter a user, you can check if the distinct_id exists in the list of users who’ve appeared previously. This approach lets you check if the user is new or returning. It then assigns a property value to their “Home Page” or “App Open” or equivalent event.

Mixpanel

To track first-time users with only Mixpanel, assign all new users a super property when they arrive at your site. Instead of checking if a user has or has not been to the site, you would assume all users are brand new. Then, when a user arrives, you would assign a super property value to indicate if the user is returning.

Using this code, you can quickly and easily track any new first-time user.

mixpanel.track("Home Page Viewed");

mixpanel.register({"First Time": "FALSE"});

First-time Landing Page

Instead of setting a property value based on the user’s visit to a general page, which every user visits, you could direct new users to a specific page.

For example, from a welcome page you can send an event to track a first-time user. Mixpanel recommends you use this same event name as your normal first screen event so you can compare the metrics for first-time and recurring users more easily later on.

mixpanel.track("Home Page Viewed", {"First Time": "TRUE"});

Callbacks

The implementations in this article assume you will set a super property after sending an event.

In some instances, the time the page takes to load can cause the super property to set before the event is sent, even if it is located later in the code.

As a solution, register the super property in the callback for the event.

mixpanel.track("Home Page Viewed", {"First Time": "TRUE"}, function()

{

setTimeout(mixpanel.register({"First Time": "FALSE"}), 500);

});

Measuring First-Time Users

In Funnels, you can view how first-time users convert through a specified set of actions on your site or app.

It could be as simple as viewing sign ups through the process, or as complicated as tracking a purchase from San Francisco within 30 days of a first-time event.

Sorting your first-time users in funnels allows you to view the distinct conversion rates of first-time users versus returning users.

You might find that returning users are more likely to perform certain events than a first-time user. As a result, you might want to tweak your site or app design to better highlight the goal you want your new customers to complete.

Using Retention, you can directly measure how first-time users are retained when compared to returning users.

This analysis allows you to view how new users return to your site to perform a specific event as compared to your already existing users.

You can then find out what events drive users back to your website, as compared to what events first-time users perform. If these are not in sync, you could update your website or app to properly introduce first-time users to the features you want them to be using regularly.

Depending on your implementation library and use case, one of the above methods for tracking first-time users could be more applicable to your needs.

Welcome to Mixpanel! Your journey to getting insightful and actionable analytics begins with the Mixpanel Basics. This guide is designed to surface the fundamental knowledge and resources necessary to succeed with Mixpanel. The core concepts presented here are paramount to working with Mixpanel and will be assumed knowledge in all other training material.

In this guide we will cover:

What is Mixpanel? - An introduction to Mixpanel and what it can do.

The Data Model - How Mixpanel data is structured.

Your Account - Overview of your personal settings in Mixpanel.

Wrap-up - Tailored suggestions on where to go for continued learning and review of key terms in this guide.

Additional Resource Links

As you work your way through this guide (and other Mixpanel training guides), you will come across green callout boxes such as this. We will use these boxes to highlight additional resources to further develop your understanding of Mixpanel. These resources often go into much more depth of detail than what is covered in the guides, so we highly recommend that you check them out!

What is Mixpanel?

Mixpanel is a user analytics tool that allows you to track how users interact with your Internet-connected application. Data is sent from a user’s device or your server to Mixpanel, where it can be analyzed in real-time to better identify trends and understand user behavior. Mixpanel also allows you to use your behavioral analytics data to precisely target users with various types of messages and experiments to help drive maximum engagement and adoption.

Introduction to Mixpanel Course

For a more visual and holistic overview of Mixpanel, check out the Introduction to Mixpanel course which contains 45 minutes of video lessons covering the fundamentals of working with Mixpanel. We highly recommend this course to all new users as we have found that viewers of this course gain much more immediate value out of Mixpanel. And how do we know this? We use Mixpanel to track and analyze this, of course!

The Data Model

Unlike some other analytics tools which are limited to tracking pre-defined measures of engagement, such as page views and browser sessions, Mixpanel employs an event-based, user-centric model that tracks the specific actions that individual users take within your product.

This event-based approachto analytics captures a deeper understanding of user engagement, which allows for more granular analysis and effective targeting of messages and experiments.

As for the actual structure of the Mixpanel data model, it is built on three key concepts: events, properties, and user profiles. Let's quickly discuss each of these components.

Events

An event is a meaningful action that a user performs in an application or on a website.

Events can be a wide range of actions. For example, a music service might track a new user signing up for an account or a user playing a song as events.

It is important to determine which user actions are important to collect and later analyze. Those actions should be tracked as events.

Event Properties

An event property is a detail about an event.

To elaborate, event properties are descriptive key-value pairs associated with an event, either describing the event itself or the user who performed that event.

When determining which events to collect, it is important to specify which details about that event should also be collected. Event properties are incredibly important, as they provide the necessary context about events to ensure valuable analytics. Properties also facilitate the dissection of data, allowing for more detailed insight into event-driven data.

When a new user signing up is tracked as an event, the type of plan they signed up with can be collected as a property of the sign-up event. If a user plays a song, the title of the song can be collected as a property of the song play event.

here

Once tracked, events and their properties are immutable, meaning they cannot be changed.

User Profiles

A user profile is a collection of information about an individual user.

Like events, user profiles have properties that describe the profile. Unlike events, however, user profiles and their properties constantly change to reflect the most recent information about a user.

A user profile property could be a static value, such as a first name, or be something more likely to change, like the date of last login or the number of songs a user has played.

Different Mixpanel Properties

Still have questions about the different types of properties? Check out this article for more examples and additional detail on property types.

Your Account

Before looking at your individual Mixpanel account, we need to take a quick look at the Mixpanel admin system. Each Mixpanel account will be part of at least one organization and any number of projects owned by the organization. An organization is the entity that connects Mixpanel plans, projects, and accounts together. Projects can be thought of as containers for your Mixpanel data which are often separated by some logical criteria, testing (dev) vs production data for example.

A plan determines what features each project in the organization will have access to in Mixpanel. Access to features for each account can be further limited by organization and project roles. Your account will have one organization role for each organization and a project role for each project it is a part of.

Organization and Project Roles

The Organization Roles and Permissions article and the Project Roles and Permission article have more information on the respective roles and what each has access to in Mixpanel.

After logging into Mixpanel, you will see the current project you are in and your project role for that project in the upper left-hand corner of the page. Mixpanel displays a drop-down of all your projects when you click on the project name (red box below).

The upper right-hand corner (yellow box above) displays your name in bold, above your organization name. If you belong to more than one organization, the total number of organizations is shown instead (as pictured).Opening the menu here, you find your personal settings by clicking Profile & Preferences under Personal Settings.

Personal Settings Overview

For complete details on the options available in your personal settings, check out this article.

The above covers the basic level of Mixpanel admin that all users should need. If you are someone responsible for administering Mixpanel for your organization or a project, there are a few more things you should be aware of.

Guide to Mixpanel Admin

To learn a bit more about the Mixpanel system and the different ways to invite users and manage the various settings available, check out our Guide to Mixpanel Admin.

Wrap Up

Congratulations on completing the Mixpanel Basics! By finishing this guide, you now have the basic knowledge necessary to begin diving deeper into Mixpanel.

Next Steps

Where to go next with Mixpanel really depends on your role in regards to Mixpanel and where your company's implementation currently stands.

Guide to Mixpanel Implementation

The Guide to Mixpanel Implementation will walk you through the process of setting up Mixpanel tracking for your projects. Any users looking to set up tracking for a new project or re-implementing on an old project should start here.

If your project already has data, you should be ready to begin learning about your data and the advanced analytics capabilities in Mixpanel.

Guide to Mixpanel Analysis

Mixpanel offers a wide range of reports and analysis techniques for looking at your data. The Guide to Mixpanel Analysis will introduce you to the different reports in Mixpanel, show you how to build them and provide some example use cases.

Key Terms (Review)

Here we will define some of the key terms we discussed in Mixpanel Basics.

Term

Definition

Event

A meaningful action that a user performs in an application or on a website.

Event Property

Detail attributed to an event. Structured as a key:value pair where key is the property name and value is the value given to that property.

Organization

The controlling entity that links individual accounts, projects, and a Mixpanel plan together.

Organization Role

Each account within an organization has one organization role which determines what that account has access to in the Organization Settings. Different organization roles and their permissions can be seen here.

Plan

A plan defines the features and data volume limits for the organization over a specified term length. All projects housed within said organization are subject to the plan's specifications. Plan information can be seen in the Organization Settings menu.

Project

A container for your product's analytics data.

Project Role

Project roles determine what features an account will have access to in a project. An account can have a different role for each project it is a part of. Different project roles and their permissions can be seen .

User Profile

Collection of information about a user. Consists of one or many user profile properties.

User Profile Property

Detail attributed to a user profile. Structured as a key:value pair where key is the property name and value is the value given to that property.

Lexicon is a data dictionary that stores descriptions of events and their properties.

Project owners and administrators can add and manage descriptions for all events and properties, and organize data for clarity and discoverability.

Event and Property Descriptions

In Lexicon, you can add or change descriptive information about your events and their properties.

Events are actions a user performs in your application or website.

Event properties are the specific details that describe the action.

In large implementations of Mixpanel with multiple teams and hundreds of events and properties, it can be difficult for other team members to interpret event information.

Using Lexicon, you can better understand your events because you can add or change event information, track who modified it, and verify whether the current information is accurate.

Download Your Lexicon Data

Project owners and admins can clickDownload CSVin Lexicon to receive a CSV file via email that contains the event and properties, or user profile properties data from a project.

The requester receives an email with a link to download a CSV file. The link remains active for 2 weeks.

An events and properties file contains the following columns:"Event", "Event Display Name", "Event Description", "Event 30 Day Volume", "Event 30 Day Query Volume", "Event Tags", "Event Hidden", "Event Dropped", "Event Property", "Property Display Name", "Property Description", "Property 30 day Volume", "Property 30 Day Query Volume", "Property Type", "Property Example Values", "Property Hidden", "Property Dropped".

Each events and properties file can contain up to 5,000 events, and 2,000 properties per event.

A user profile properties file contains the following columns:"Property", "Property Display Name", "Property Description", "Users With Property", "Property 30 Day Query Volume", "Property Type", "Property Example Values", "Property Hidden", "Property Dropped".

Eachuser profile properties file can contain up to 2,000 user profile properties.

Default Properties

Lexicon contains property definitions for the default properties that Mixpanel’s client-side libraries automatically send with each event across web and mobile platforms.

If you use the Mixpanel JavaScript library for your web implementation, Mixpanel sends this list of properties.

If you use the Mixpanel Android library for your mobile application, Mixpanel sends this list of properties.

If you use the Mixpanel iOS Objective C library or the Mixpanel iOS Swift library for your mobile application, Mixpanel sends this list of properties.

drop

Organizing and Finding Data

Mixpanel provides tags to help you organize and find your data.

A tag is a label you assign to an event. Tags enable you to categorize events and make them easier to findespecially in large Mixpanel implementations with multiple teams.

Event and property definitions that are clear, accurate, and findable reduce the learning curve and help teams get up to speed faster. This feature is particularly useful when a new member joins the team.

Before new members join your project, you can review your event and property definitions for accuracy and add tags to better organize them.

In this article, you'll explore the Lexicon user interface and learn how to:

Add and change event and event property descriptions.

Filter events and properties.

Hide or show events and properties.

Add and change one or more event tags.

Use tags in Insights reports.

Drop and undrop events and properties.

Merge or unmerge events and properties.

Understand query volumes for events and properties.

Exploring Lexicon

This section provides a tour of Lexicon.

To open Lexicon, select Data Management and then select Lexicon.

When you open Lexicon, you see four views:

Events

Custom Events

Event Properties

User Profile Properties

This GIF shows each view and its filters.

Events

Events are actions a user performs in your application or website.

This table contains descriptions for each field in the “Events” view.

Field

Description

Name

The database name of the event.

Display Name

The event name that displays in the Mixpanel interface.

Description

The information that describes the event, such as what triggers it or what properties are sent with it.

Status

The event is either hidden or visible in the Mixpanel project.

Volume

The total number of events that users fired in the last 30 days.

Queries

The total number of API and UI queries that users executed in 30 days.

Custom Events

Custom events are events and properties you combine into one event to use in Mixpanel reports.

The fields for custom events are “Name”, “Display Name”, “Description”, and “Queries”.

See the table in Events for field descriptions.

Event Properties

Event properties describe details about events, such as distinct_id or browser.

This table contains descriptions for each field in the “Event Properties” view.

Field

Description

Name

The database name of the event.

Display Name

The event name that displays in the Mixpanel interface.

Description

The information that describes the event, such as what triggers it or what properties are sent with it.

Status

The event is either hidden or visible in the Lexicon.

Events With Property

The total number of events that users fired in 30 days.

Queries

The total number of API and UI queries that users executed in 30 days.

User Profile Properties

User profile properties describe details about your users, such as username or email address.

This table contains descriptions for each field in the “User Profile Properties” view.

Field

Description

Name

The database name of the property.

Display Name

The property name that displays in the Mixpanel interface.

Description

The information that describes the property, such as what events it is sent with.

Status

The property is either hidden or visible in Mixpanel reports.

Users With Property

The total number of profiles that contain this property.

Queries

The total number of API and UI queries that users executed in 30 days.

Adding or Changing Descriptions

Lexicon lets you add or change descriptions for:

Events

Custom Events

Event Properties

User Profile Properties

Add or Change Event Details

To add or change events:

Select the “Events” view.

Click an event to display "EVENT DETAILS".

In “EVENT DETAILS”, click the Pencil icon at right side of the property to modify the “Display name”, “Description”, “Tags”, and “Platforms” fields.

You can scroll down to “EVENT PROPERTIES” and add or modify the “Display Name”, “Description”, and “Example Value” fields.

Add or Change Custom Event Details

To add or change custom events:

Select the “Custom Events” view.

Click a custom event to display "EVENT DETAILS".

In “EVENT DETAILS”, click the Pencil icon at the right side of the property to modify the “Display Name”, “Description”, “Tags”, and “Platforms” fields.

You can scroll down to “EVENT PROPERTIES” and add or modify the “Display Name”, “Description”, and “Example Value” fields.

Add or Change Event Properties

To add or change event properties:

Select the “Event Properties” view.

Click an event property to display "PROPERTY DETAILS".

In the "PROPERTY DETAILS", click the Pencil icon at right side of the property to add or change the information in the "Display Name", "Description", and "Example Value" fields.

Tip

To quickly change display names or descriptions for events and custom events, or change display names, descriptions, and example values for event and user profile properties, hover over each field and enter the information.

Add or Change User Profile Property Details

To add or change user profile properties:

Select the “User Profile Properties” view.

Click a user profile property to display "PROPERTY DETAILS".

In the "PROPERTY DETAILS", click the Pencil icon at right side of the property to add or change the information in the "Display Name", "Description", and "Example Value" fields.

Adding Tags to Events

A tag is a label you assign to an event to help you organize and find it.

You can add tags to one or more events in the “Events” or “Custom Events” view.

To add tags to an event:

In the “Events” or “Custom Events” view, select one or more events. The “Tag” icon appears.

Click Tag to display the “Tag Selector” box.

Add or change tags to one or more events:

To add tags, enter the name of one or more tags in the “Tag Selector” box and click Save. As you add tags, they appear in a searchable list in the “Tag Selector” box.

To change tags assigned to an event, select one or more tags in the “Tag Selector” box, add or remove tags, and then click Save.

Deleting Custom Events in the Insights Reports

You can delete custom events in the Insights report.

To delete a custom event:

1. Select the custom event, and click the Pencil icon.

2. At the bottom, click the Trash icon to delete the custom event.

Dropping Events and Properties

In Lexicon, users can intercept and drop incoming events or properties. Mixpanel won’t store any new data for the event or property you select to drop.

When an event is dropped, all events of that type that have previously been ingested (before dropping it) will still show in the interface.

Only project owners can merge and drop events and properties.

Use Cases

Here are some standard use cases for dropping events and properties.

Sensitive data

If you accidentally send sensitive data, such as passwords or credit card information, you can drop the event or property with that data and prevent it from being stored in Mixpanel servers.

Cost and Time Efficiency

Being able to drop events and properties that are no longer useful directly from Lexicon is easier and more efficient than having to implement changes to your code base.

If your app is mobile, it's easier to drop events and properties in Lexicon to submitting your app again and waiting for users to update to the new version.

Better Organization

Events and properties that are no longer useful can cause a cluttered Mixpanel project. Dropping unnecessary events and properties optimizes your code for a clean and streamlined project implementation.

Note: It takes a few hours for Mixpanel to process the dropped event.

Warning

You cannot recover event data after you drop it.

Dropping Events

To drop an event in Lexicon:

Select an event to drop. The “Drop” icon appears.

Click Drop. A “Confirm dropping your event(s)” warning indicates you cannot recover the data associated with the event.

Click Drop. The status of the event indicates “Dropped”.

Dropping Properties

To drop a property in Lexicon:

Select a property to drop. The “Drop” icon appears.

Follow steps 2 - 3 in Dropping Events, noting that a “Confirm dropping your properties” warning appears instead of “Confirm dropping your event(s)”.

Undropping Events

You can undrop events and properties when you decide you need them again.

To undrop an event:

Select a dropped event. The “Status” column indicates if an event is dropped.

Click Undrop. The “Status” column no longer contains “Dropped”.

Undropping Properties

Select a dropped property. The “Status” column indicates if a property is dropped.

Click Undrop. The “Status” column no longer contains “Dropped”.

Filtering Events, Custom Events, Event Properties, and User Profile Properties

Lexicon provides several options for you to filter your events, custom events, event properties, and user profile properties.

You can filter by visible or hidden events, dropped events, merged events, tags, your defined events, autotracked events, and default Mixpanel events.

These filtering options help you arrive at the most useful data to analyze your performance.

Filter Events

In the "Events" view, you can filter by:

All Status:You can select: “Visible Events”, “Hidden Events”, “Dropped Events”, or “Merged Events”. Select “All Status” to filter by the entire status list.

All Tags:You can select one or more tags. Select “All Tags” to filter by the entire list of tags.

All Types:You can select: “Your Events”, “Autotracked Events”, or “default Mixpanel Events”. Select “All Types” to filter by the entire events list.

Filter Custom Events

In the "Custom Events" view, you can filter by one or more, or all tags.

Filter Event Properties

In the "Event Properties" view, you can filter by:

All Status:You can select: “Visible Properties”, “Hidden Properties”, “Dropped Properties”, or “Merged Properties. Select “All Status” to filter by the entire status list.

All Types:You can select: “Your Events”, “Autotracked Events”, or “default Mixpanel Events”. Select “All Types” to filter by the entire events list.

Filter User Profile Properties

In the “User Profile Properties” view, you can filter by:

All Status:You can select: “Visible Properties”, “Hidden Properties”, or “Merged Properties”. Select “All Status” to filter by the entire status list.

All Types:You can select: “Your Events”, “Autotracked Events”, or “default Mixpanel Events”. Select “All Types” to filter by the entire events list.

Hiding and Showing Events and Properties

Users can hide and show events and properties.

This feature helps you refine filtering options and maintain a clean, organized project implementation.

Hide Events and Properties

Owners and admins can hide data.

To hide an event or property:

Select one or more visible events, event properties, or user profile properties. The “Hide” icon appears. You can check the “Status” field to determine whether an event or property is visible or hidden.

Select Hide. A message appears to allow you to confirm hiding the event(s). After you select Hide, the event or property status changes to “Hidden”.

Show Events and Properties

To show an event or property:

Select one or more hidden events, event properties, or user profile properties. The “Unhide” icon appears. You can check the “Status” field to determine whether an event or property is visible or hidden.

Select Unhide. After you select Unhide, the event or property status changes to “Visible”.

Merging Events and Properties

In Lexicon, users can merge events and properties.

For example, suppose your iOS app sends an event named “Purchase”, and your Android app sends an event named “purchase item”. Both events have the same function,but you have to select each separately every time you build a report.

You could merge both events, “Purchase” and “purchase item” into a single event named “Purchase”. Now you no longer need to query each event separately. Mixpanel recognizes both “Purchase” and “purchase item” as a single event called "Purchase".

Being able to merge events can help streamline your implementation, reduce your costs by eliminating redundant events being sent to Mixpanel, and simplify report analysis because you’re only using optimal events and properties.

Note

You can access merged events and properties across all reports except Live View. The Live view report only shows data in raw format, which you can use for debugging.

Merging Events

To merge events:

Select the events to merge. The “Merge” icon appears.

Click Merge. The “Merge Events” window appears. It shows the events you selected and explains that merging the selected events combines them into a single event, which does not affect the raw data.

In the “MERGE SELECTED EVENTS INTO” section, specify which event Mixpanel should recognize as the newly merged event name.

Click Merge.The merged event appears and the “Status” column indicates “Merged”.

Unmerging Events

To unmerge events:

Select the merged event to unmerge. The “Unmerge” icon appears.

Click Unmerge. The merged event appears as the original two distinct events.

Merging Properties

To merge properties:

Select the properties to merge. The “Merge” icon appears.

Click Merge. The “Merge Properties” window appears. It shows the properties you selected and explains that merging the selected properties combines them into a single property, which does not affect the raw data.

In the “MERGE SELECTED PROPERTIES INTO” section, specify which property Mixpanel should recognize as the newly merged property name.

Click Merge.The merged property appears and the “Status” column indicates “Merged”.

Unmerging Properties

To unmerge properties:

Select the merged property to unmerge. The “Unmerge” icon appears.

Click Unmerge. The merged property appears as the original two distinct properties.

Using Tags in Insights Reports

The Insights report contains a list of tags.

When you select a tag, a list of events that share the same tag appears. You can then select the event you want.

Suppose your mobile gaming application has hundreds of events and you want to find events that are associated with game purchases.

If you’re new to the project, it could be time-consuming to search hundreds of events to find them. Using Lexicon, you can assign a tag to events that relate to a specific category.

For example, we’ll use a purchases tag for all events and properties that relate to purchasing, such as In-App Purchase or Booster Pack Purchased. The purchases tag makes the search much easier, because the purchase related events are listed under the purchase tag.

In addition to the previous example, tags are useful to identify specific events of interest for certain teams, distinguish events that are relevant to a specific product or service, or indicate events that are associated with certain key performance indicators.

Viewing Query Volumes for Events and Properties

In each view, you can see the total UI and API queries in the last 30 days for any of these data types and sort by it.

This data lets you easily discover the parts of your implementation that are most valuable and the parts that are not being used.You can use this information to determine which events and properties you should .

Event Properties and Super Properties are associated with specific Events (i.e., they describe those Events or the user that did the Event at that time). However, Profile Properties give you detail about a certain user overall. In other words, Profile Properties describe your users as they exist in this moment. Profile Properties includes both user profiles and group profiles.

For example, while an Event Property or Super Property tells you whether a user had a paid or free account over time when a user did specific actions, a Profile Property would simply show you currently if they are paid or free.

Because of this slight nuance between Event/Super and Profile Properties, you may find it helpful to track some of the same things both as Event/Super properties and as Profile Properties.

In general, Property values that may change over time and whose change is valuable data may be best tracked as both a Profile Property and a Super Property.

Reserved Properties for User Profiles

Mixpanel reserves certain property names for special use cases. These reserved properties are different from default collected properties, as they are not collected by default.

Avatar ($avatar) -Set this property to a url resource of a gif, jpg, jpeg, or png to update the profile picture in a profile. This property will override a profile picture pulled from Gravatar.

Email ($email) - The user's email address. You must set this property if you want to send users email from Mixpanel.

Phone ($phone) - The user's phone number. You must set this property if you want to send users SMS from Mixpanel. Note that a '+' needs to precede phone numbers. This is especially useful for international numbers. If the user does not import a phone number with the '+' sign in front of the number, the country code will be prefixed to the front of the number based on the $country_code property, resulting in a phone number with two country codes.

$distinct_id - The user's distinct_id. This property value should be identical to the distinct_id property attached to events so that you can connect events to user profiles.

$ios_devices - List of user's Apple Push Notification service device tokens for iOS push. Our iOS client library has methods to manage this property for you.

$android_devices - List of user's Google Cloud Messaging registration IDs for Android push. Our Android client library has methods to manage this property for you.

$first_name, $last_name, $name - User's first and last names, as well as a general name. These are primarily useful because we will use them, if available, in a few spots in our reports.

$transactions - A list with specially formatted JSON objects, one for each purchase or transaction associated with a specific profile. For more information about $transactions, see Tracking revenue in Mixpanel HTTP Tracking API.

Created ($created) - The time that the profile was created.

City ($city) - The city of the event sender, parsed from IP.

Region ($region) - The region (state or province) of the event sender, parsed from IP.

Country ($country_code) - The country of the event sender, parsed from IP.

Timezone - ($timezone) - The timezone of the event sender, parsed from IP. If set, messages can be scheduled to be sent based on a user's timezone.

Unsubscribed - ($unsubscribed) - If this property is set to any value, a user will be unsubscribed from Mixpanel email messages.

For a list of default properties collected by Mixpanel, see this article.

List Properties

A list property contains a list or array of several properties contained in one value.

Use list properties whenever you have more than one value for a given property. Here are a few examples of list properties:

All the Items purchased in a “Checkout Completed” event.

Multiple artists for a “Song Played” event.

Experiment groupings for A/B testing.

Genres of music in a listener’s preferences.

The list type properties limit is 2mb.

Property Limits for User Profile Properties

Mixpanel User Profiles can contain up to 2,000 properties each. Attempts to add more than 2,000 properties will fail. You can remove user profile properties using the $unset engage operation if you find yourself close to the 2,000 per profile limit.

The following limits on field size apply when inputting fields for properties in Mixpanel:

255 bytes for string properties

255 characters for each item in list properties

Mixpanel billing plans may be purchased via the pricing page.

Mixpanel accepts all major credit cards for payment on paid plans.

Update Billing Information

If you’re the project owner, update billing information by:

Clicking your initials in the upper righthand corner of Mixpanel and selecting your Organization name under Organization Settings.

Under the Overview tab, click theUpdatebutton next to Billing Info to update your credit card info.

Note: Only the billing owner will be able to update the account billing information.

In order to focus our engineering efforts on making Insights the most powerful exploratory tool, we deprecated Formulas on October 30, 2019. We've made it easy to re-create your existing Formulas reports in Insights, where you can take your analysis a step further.

Why is Formulas being retired?

Although Formulas is a great report to analyze ratios between events, it was not designed to answer complex queries beyond this use case. We built Insights as a more powerful and flexible report for customers to analyze their events, and go deep in exploring their data.

All Formulas functionality is now included in the Insights report. By focusing on fewer reports, Mixpanel can release new features faster and continue building out Insights to be the most powerful exploratory tool.

How do I use formulas in the Insights report?

For more information on how to use formulas in the Insights report, see the Build an Insights Report article.

dashboards

Why Insights and not Formulas?

The Insights report includes all of the same functionality as the Formulas report, and all analysis capabilities can be recreated in Insights. The Insights report has some features and performance capabilities that the Formulas report lacks.

The following Insights report features make the insights report the more powerful way to use formulas:

Apply formulas to more than two events

Create a formula to display a goal line on your chart

Compare multiple Formulas in one report

Breakdown Formula results by properties or cohorts

Apply cohorts to analyze how groups of users behave

Compare time ranges to see how trends & ratios are changing over time

Receive anomaly alerts with explanations, so you can act quickly

Flexible time ranges with options including: "today", "yesterday", "last x days", “since”, and “on”

Add formulas to

What will happen to the bookmarks I have in Formulas?

To make the transition from Formulas to Insights, you will have access to existing Formulas bookmarks through the bookmark URL, or in the “Applications” menu, but you should transition any important bookmarks to Insights before you are unable to access them.

Journeys Basics

Mixpanel’s Journeys allows you to create a sequence of messages that are sent based on cohorts or filters. You can decide which messages to deliver at each point in your user’s journey.

This article explains Journeys basics. Learn about how to build a journey here.

Journey Components

Mixpanel’s Journeys lets you build a series of Webhook, Email, SMS, and Push messages using entry criteria, cohort filters, and time delays.

Note

Journeys does not support in-app messages.

The journey table is where you can see all of your saved journeys, including active, inactive and draft journeys.

article

When you open a journey, you can add and arrange entry blocks, cohort filters, and message blocks. The journey settings toolbar includes draggable buttons to add Webhook, Email, SMS, Push, and Cohorts.

Entry Block

You must have an entry block to determine how and when users enter your journey. You can configure entry criteria based on an event. Users can only enter a journey once.

Message Blocks

Add a message block to your journey to include Webhook, Email, SMS, or Push messages. You can copy messages that have been created and saved in Messages.

Note

When you copy a message to a journey its contents are duplicated into a new message. Changes are limited to the copied journey, and do not impact the original message.

Cohort Filter

Add a cohort filter to split the path of your journey into users that are in and out of the selected cohort. For more information about cohorts see this article.

When you add a cohort filter, the journey splits into users that are in the cohort and users that are out of the cohort.

Time Delays

You can decide when your message is sent by adding a time delay to a message, or sending the message as soon as possible. The time delay is the minimum amount of time between when the user received the previous message, and when the next message is sent.

You can set a different time delay for each message in your journey. If a message block has multiple incoming connectors, then each incoming connector will have the same delay.

Journey Analytics and Tracking

You can track Journey events with Mixpanel to see if users who received a message went on to complete a certain key event. See this for details about what events you can track for each message type.

Testing a Journey

To test a Journey, you can send the journey to yourself by adding a cohort filter in the entry criteria. Set the cohort to target only your own email, phone number, or device to receive the messages as a test. Since users can only receive a journey once, you will need to create a separate journey each time you want to test the journey by sending it to yourself.

Flows identifies the most frequent paths taken by users from or to any event. Use Flows to understand how your users sequentially perform events in your product, and analyze drop-offs or unsuccessful behavior. This article explains the basics of the Flows report. To learn how to build a Flows report click here, and to interpret a Flows report here.

For marketers, this means finding out the steps users take leading up to a conversion, or where they actually go instead of converting. For product managers, this means seeing if users are actually completing onboarding, or pinpointing where they drop off. Drive conversion by identifying the optimal paths that lead users to convert, and seeing which events take users off that path.

There are two types of Flows charts you can view:

User Flows: a Sankey diagram in which the width of the lines is proportional to the flow quantity.

Top Paths: the top 50 paths your users took after the starting event or before the ending event. A path is defined as any sequence of up to five events. Top Paths is calculated based on unique users.

Navigate to Flows by selecting it from the Analysis bar.

Choose whether you would like to select the starting event or the ending event for your report by selecting from the options at the top of the query builder.

Forward Flows (starting with) - Understand the paths users take through your product from a single starting point to determine how they are using it.

Reverse Flows (ending with) - Understand the paths users take through your product to a single ending point to determine the effectiveness of your flows to that event. For example, you can use this to discover what users did right before making a purchase or converting in order to see what precipitated the customer’s choice to purchase.

Get a high level overview of the features in Flows with this short video:

The billing system for Mixpanel is changing to a Monthly Tracked User (MTU) system, rather than People and Engagement plans. This guide will help you understand this new system and why you should join it.

What is an MTU?

Monthly Tracked User (MTU) is a different way to calculate your billing based on the number of users that perform a qualifying event each month, rather than individual user profiles or events.

There are three MTU billing plans to choose from: Starter (our Free plan), Growth, and Enterprise. Refer to our pricing page for more information on the restrictions and benefits of each plan.

Note that the number of MTUs in your project may not match the number of user profiles in your project. User profiles are created in your implementation either by calling mixpanel.identify or mixpanel.people.set. These are cumulative over the lifetime of your project unless you delete them. The count of MTUs is based on the number of users that triggered at least one event in that month and are counted on a monthly basis.Therefore, you will not be charged for profiles that are not actively triggering events.

Monthly Tracked Users Calculation

MTUs are summed up across all projects under an organization.One MTU is equivalent to one distinct_id that performs at least one qualifying event per project. An organization is charged based on the total number of MTUs across all projects.

MTUs are calculated on a per-project basis. This means that if a user performs a qualifying event in multiple projects, they are counted once per project.

An MTU is a user that tracks at least one event within your projects, independent of whether you have created a profile for them or not. You may find that MTUs could be higher or lower than your user profiles.

MTUs are calculated on a monthly basis. Annual Enterprise plans average MTU utilization over a quarter to account for monthly fluctuation.

For example, say you have a 25,000 MTU plan:

Monthly plan (default for Starter and Growth plans):

You get 25,000 MTUs to use every month. Going over this amount results inla carte data ratecharges being billed to your account.

Quarterly averaging plan (default for Enterprise plans):

You get 3x your MTUs to use every quarter, or 75k MTUs per three month period. Therefore, you could have 50,000 MTUs in month 1, 25,000 in months 2 and 3, and you wouldn't get anyla carte data rate charges, as your average is 25,000 MTUs.

Events and data that are non-qualifying and excluded from the calculation:

Message Sent ($campaign_delivery)

Message Bounced ($campaign_bounced)

Message Marked Spam ($campaign_marked_spam)

Message Suppressed ($message_suppressed)

Message Unsubscribed ($unsubscribe)

Campaign Entered ($journey_entered)

$merge

$identify

$create_alias

Updates to user profiles

Also, note that Mixpanel events generated by messages do not count toward your total MTU calculation. However, Message Open events count towards MTU.

How does X event impact my MTU count?

To analyze how specific events impact your MTU count, create an Insights project like the following example :

blog post

La Carte Data Rate Alerts

The billing owner is sent an alert email if their account reaches the following percentages of their plan volume: 85\%, 100\%, 110\% and 120\%. The billing owner may receive multiple alerts in a month if their account reaches two or more of the thresholds mentioned above.Email addresses that are CC'd on invoices will also be CC'd onla carte data ratealerts.

If the billing owner logs into Mixpanel, they will see a popup if their account reaches the following percentages of their plan volume: 100\%, 110\% and 120\%.

Typically, MTU counts increase when you have an increase in users in your app. Occasionally, large update to your product or a marketing campaign can lead to an increase in tracked users.

Adding tracking to new parts of your product may also increase tracked users, as they are performing events you didn’t previously track.

There are also some scenarios in which MTU numbers may be higher than expected because a new anonymous user or distinct_id may be generated for a single user.

If you go over your prepaid amount, Mixpanel won't stop collecting your data. Once you've finished using your prepaid amount of MTUs you'll be charged the la carte rate (50\% above normal plan rates) for each additional user tracked that month.

Calculating YourLa Carte Data Rate

If a user triggers greater than 1,000 events in a month, the MTU tally doesn’t necessarily increase. MTU tallies are only adjusted if your average user sends more than 1,000 events per month. This is calculated as follows:

Number of events for a given month / Number of users tracked in the month

Estimate MTU Usage

If you haven't implemented tracking yet, you can estimate your current MTU usage by looking at your Monthly Active User (MAU) count. Your MTU and MAU counts should be similar, provided they account for anonymous users identically.

View MTU Usage

MTU calculates users including anonymous users without a registered account. This means that users who only visit your homepage are still tracked as an MTU. Users are only counted once per month, even if they perform multiple actions across devices.

If you are currently tracking data, you can see your MTU consumption in your Organization Settings.

Click on your name in the upper right corner of Mixpanel, and select your organization name under ORGANIZATION SETTINGS.

From here, billing owners and billing admins can see the current MTU tally for the organization by clicking on View MTU Usage.

This will show you a graph of your MTU usage over time, as well as a chart ofthe number of MTUs in each project of your organization, broken down by month, for the last 12 months. This feature is accessible by organization and billing admins. This information can be downloaded to a CSV file.

You can also view MTU tally per project by clicking on Projects in the left menu.

Why should I move from a People/Engagement plan to MTU?

There are many reasons to switch from your current People or Engagement plan to an MTU billing plan.

MTU Plans Scale with your Growth

This means that as you acquire more active users in your product, your MTU volume increases, allowing your Mixpanel costs to match your product’s use.

No More Deleting Inactive Profiles

With the current people plan, you are charged per profile, meaning that inactive users are still counted toward your billing. With MTU billing, you are only billed for the users actively using your product.

Access to More Features

Non-Enterprise customers get access to more features than on their original plan. This includes:

Cohorts

Flows

Unlimited custom events

Email dashboard digests

CSV download

Signal

Predict

Custom alerts

Unlimited saved reports

Add-On Packages

You can purchase add-on packages to access more advanced reports usually only included in the Enterprise plan.

The ability to send messages to users or configure mobile A/B tests is limited to paying customers on MTU plans (as a Messages & Experiments package must be purchased in order to use messages).

Paying users can purchase Data Pipelines as an add-on package.

Unlimited Seats for Paid Plans

Paid plans include Growth or Enterprise.

Benefits of MTU Model

To understand more about why Mixpanel made the decision to move to this new billing style, take a look at this .

Use Data Functions in Mixpanel reports to find the total, unique, average, median, min, max, DAU, WAU, MAU, P99, and P99 for a data set. Most of the following functions are only available in the Insights report. Functions available in the Funnels and Retention reports are indicated in the table below.

Select Data Functions

Data Functions compute aggregate values of your event and property data, including totals, uniques, and averages.

In Insights, you can change the data function by selecting the dropdown that displays Total beside the event selector. When you first create an Insights report, the query will default to total.

Retention

Add an Aggregation by clicking on the three dots and selecting Add aggregation from the drop-down list, then selecting a property. The property you select will be typecast to a numerical property for the calculation.

Click on Sum to view the data functions available.

In the Funnels report, you can toggle between totals or uniques, while queries can only be calculated using unique values.

Data Functions Table

Function

Event Calculation

Property Calculation

Total/Sum

Insights

Funnels

Total count of [event] performed

Total of [property value] across all events

Unique

Insights

Funnels

Retention

Count of unique users performing [event]

Unique count of [property value] across all events

Average

Insights

Average count of [event] performed across all users

Average [property value] across all events

Median

Insights

Median count (middle number) of [event] performed across all users

Median count (middle number) of [property values] across all events

Min

Insights

Minimum count of [events] across all users

Minimum of [property value] across all events

Max

Insights

Maximum count of [events] across all users

Maximum of [property value] across all events

P90

Insights

N/A

90th percentile of [property value] across all events

P99

Insights

N/A

99th percentile of [property value] across all events

DAU/WAU/MAU

Insights

Daily Active User (DAU), Weekly Active User (WAU), or Monthly Active User (MAU) count of users performing [event]

N/A

Daily, Weekly, and Monthly Active Users

Daily Active Users (DAU)

Select DAU to calculate the number of unique users in the previous day (24-hour) period that have performed the selected event.

Weekly Active Users (WAU)

Select WAU to calculate the number of unique users in the previous week (7-day) period that have performed the selected event.

Monthly Active Users (MAU)

Select MAU to calculate the number of unique users in the previous month (30-day) period that have performed the selected event.

Note on DAU, WAU, and MAU calculations

If you select the DAU, WAU, or MAU function for a date range that includes the current day, the query will take the end of the current day as the end of the query’s time segment (even though it’s in the future). For example, today is April 25th, and it’s 4:22 PM. If you make a query to show WAU and you select “current day” as your date range, the query will return the count of unique users between April 19 at 12:00:00 AM and April 25 at 11:59:59.

DAU, WAU, and MAU functions are currently in BETA for all users and are subject to change.

Mixpanel offers several options to delete user profiles from your project, depending on how many you want to delete and your level of technical expertise.

You might want to delete user profiles for a variety of reasons. For example, if you’ve accidentally imported a batch of profiles incorrectly, have an identity management issue that leads to profile duplication, or exceeded your profile quota and want to delete inactive profiles.

Important Note:

For whatever reason you choose to delete user profiles, rememberdeletion is PERMANENTand cannot be reverted. Delete with caution!

Delete a Single User Profile

To delete individual user profiles, navigate to Exploreunder "Users"to see a list of all your user profiles.

Learn more about the $delete update operation.

Select a profile from the list and click Deleteat the top of the profile.

It’s not possible to bulk delete through the Mixpanel UI. Mixpanel intentionally excluded this feature to prevent accidental bulk deletion.

Bulk Delete with Mixpanel-API Module

Mixpanel provides an API module to make it easy to delete your profiles. Get access to the API module here. For a quick jump directly to the People Delete section - you can head here.

Bulk Delete with Personal API Script

Deleting profiles in bulk can be done as a people update via the API.

Make a call to the /engage endpoint for a specific $distinct_id value.

Use the $delete update operation to eliminate a profile.

For example, if you want to delete the user profile with distinct_id 12345, you would send the following payload:

{

"$token": "yourMixpanelProjectToken",

"$distinct_id": "12345",

"$delete": ""

}

Profile Properties includes both user profiles and group profiles. However, Event Properties are bits of extra information that you send along with your Events which describe the details of that action. They are usually specific to the Event they’re describing and don’t apply universally to other Events.

Leveraging Event Properties allows you to conduct deeper analysis to better understand user behavior for a specific action.

While Event Properties generally describe the Event itself, they can also describe a user’s actions in relation to that specific Event.

For example, for a “Video Played” Event, you may want to include a Property that lets you know if the user firing that Event finished watching the entire video or played only part of the video.

Other examples of Events and Event Properties you might send with that Event:

Event: Page View; Property: Name of page viewed.

Event: Video Played; Properties: Length, Artist, Genre.

Event: Made Purchase; Properties: Item(s) purchased, Total, Did the user have a coupon or not.

Event: Leveled Up; Properties: Level, Time to level up, Hours user played before this level up.

How do I send Event Properties to Mixpanel?

Reserved Properties for Events

Distinct_id - A way to uniquely identify your users. You can set this to any value using the identify method. Some Mixpanel libraries assign a random value by default.

Ip - If distinct_id is not present, and the event contains a property named 'ip', the value of 'ip' will be used for uniqueness.

Token - The token used to associate data you send Mixpanel to your account and project.

time - A unix time epoch that is used to determine the time of an event. If no time property is provided, we will use the time the event arrives at our servers.

Length - Incompatible with Mixpanel's JavaScript library

Campaign_id - Used to build message funnels

City ($city) - The city of the event sender, parsed from IP.

Region ($region) - The region (state or province) of the event sender, parsed from IP.

Country (mp_country_code) - The country of the event sender, parsed from IP.

Bucket ($bucket and bucket) - A reserved property that is hidden from the Mixpanel interface, and will cause other events to not appear in the interface. Do not name any property bucket or $bucket.

Message_id (message_id) - A number data type reserved Property that is matched with Message names in the UI.

For a list of default properties collected by Mixpanel, see this article.

Super Properties for Events

Super Properties are a type of Event Property that you can register once to automatically attach to every Event you’re tracking. They are Event Properties that apply to all Events without having to manually include them in each mixpanel.track() call.

Because Super Properties send values associated with Events, they are useful for seeing Properties over time.

For example, you could register a Super Property with all of your Events that indicates whether they were done by a free or a paid user. Then, if a user changes from free to paid, you can see over time which Events led up to that conversion and which specific Events they did as each type of user.

Other examples of Super Properties you might send with every Event:

Organization that a user belongs to or rolls up into

Account age or signup date

Referring user ID or invited date

Because Super Properties are stored in the user’s cookie or in local storage, you’ll want to be relatively discerning about what you register as a Super Property so that site or app performance is not compromised. What should I do if my cookies become too large?

How do I implement Super Properties?

Incremental Super Properties for Events

Incremental super properties are a way to create a tally to count the number of times a user has performed a specific action in your app. For example, if you have an e-commerce site and want to track how many times a user has viewed an item, how many items they’ve added to their cart, or how many purchases they’ve made.

For more information about how to implement incremental super properties, see this article.

List Properties

A list property contains a list or array of several properties contained in one value.

Use list properties whenever you have more than one value for a given property. Here are a few examples of list properties:

All the Items purchased in a “Checkout Completed” event.

Multiple artists for a “Song Played” event.

Experiment groupings for A/B testing.

Genres of music in a listener’s preferences.

The list type properties limit is 2mb.

Property Limits for Event Properties

There are technically no limits on the number of Event properties you can send to Mixpanel. However, the maximum number of properties you will be able to access in the Mixpanel UI drop-downs is 1500. Additionally there is a limit of 2000 properties per event so while you can have different events containing different properties, each event is limited to 2000 properties. These limits include Mixpanel default properties and Mixpanel special/reserved properties. It is important to note that if you find yourself above 1500 total event properties and/or 2000 properties per event, it is likely you will want revisit the naming of your properties as discussed in this article.

Keep in mind the number of Properties sent per Event does tie into the amount of data being used by the device sending data to Mixpanel. While this may not matter on a browser or on your server, it will impact the data consumption by your app on users’ mobile devices. Because of this, we recommend ensuring the Properties you send will never be uncapped and will always have a maximum length to avoid excess data consumption.

Field Size Character Limits for Event Properties

The following limits on field size apply when inputting fields for properties in Mixpanel:

255 bytes for string properties

255 characters for each item in list properties

Mixpanel's Insights report allows you to analyze your user data as a current snapshot or as a trend over time. This article explains how to build an Insights report. Learn about Insights report basics here. Learn about how to interpret an Insights report here.

Reset your query at any time by clicking the three dots on the top right of the report and selecting Reset from the drop-down.

here

Choose to explore either Events & Cohorts or Profiles. Events & Cohorts allows you to examine user behaviors, while Profiles allows you access profile data and visualize your users with filters and breakdowns based on their profile properties.

Explore Events & Cohorts

Click on Your Top Events and select the event you want to query from the drop-down list.

You can view up to 1,500 events in the events drop-down list.

The events drop down only shows events that were ingested within the last 30 days. To select events that have not been ingested in the last 30 days, type the name of the event in the search bar. You must know the exact name of the event you want to select because event names are case sensitive.

You can easily create a custom event off of an event by clicking the edit pencil icon. Learn more about building custom events here.

Analyze session metrics by selecting "Session Start" or "Session End" from the events list. Learn more about using Sessions in Insights here.

Add more events or cohorts to your query by clicking the Add event or Add cohort buttons.

Next, select the Data Function you want to use to calculate results by clicking on Total and selecting an option from the drop-down list.

Filter this event by clicking the icon and selecting Filter from the drop-down list. Choose an event or user profile property, or a billing account to filter the event by. You can enter multiple properties, separated by commas.

Breakdown this event further by clicking the icon, selecting Add aggregation, then selecting an event property, such as “Amount”. This will add up the value of this property for all of the times this event happened in this time range. All aggregate properties are typecast to numeric properties in order to calculate the sum of that property. For example, aggregate the property “Amount” under the event “Process Payment” to analyze revenue.

To duplicate or delete any events or properties in your query, select the icon and choose Duplicate or Delete from the drop-down list.

Formulas

Use Formulas to make calculations using simple arithmetic operators.

Mixpanel supports the following operators:

+ : Add

- : Subtract

* : Multiply

/ : Divide

() : Use parentheses to influence the order of operations

Note

Dig deeper and break down the formula by a property to see how your calculation compares across different segments. Similarly, apply a filter to a formula to narrow in on a specific segment of your data.

Adding a Formula

Click the Add Formula button. Each event in the query shows a letter next to it, which indicates its variable name. Use these letters in combination with the operators to calculate a more advanced query. For example, you can use the DAU, WAU, and MAU functions in Formulas to calculate the stickiness of your product:

Enter a name for the formula (optional), and click Apply Formula to see the formula output.

For example, you can calculate the ratio ofDAU to MAU using a formula. Build an Insights report with event A as "App Session" and select MAU. Select "App Session" with DAU for event B. Apply the formula B/A to show the ratio ofDAU to MAU in the report.

You can also use numbers as constants in a formula. Multiply a ratio by 100 to display as a percentage, for example. Divide a property value tracked in seconds by 3,600 to display the value in hours.

Date and Time Selector

Click the Last 30 Days button below the query builder and click Select a date range at the bottom of the list.

To view a range in hours, select a 1day range and then zoom in on a line in the chart to get the values by hour. To zoom in, click on the graph and drag to highlight a specific window of time. ClickReset zoom to return to the previous view.

Rolling Date Ranges

When selecting the date range for your report, it is possible to use a rolling date range. This means that the dates will adjust relative to the current day. This rolling range can be up to 90 days.

Click the Last 30 Days button below the query builder and click Select a date range at the bottom of the list. Choose Between from the drop-down list and check the box beside Rolling range.

Filter & Breakdown Results

To filter the results of your Insights query click the Filter button below the query builder and select an event property, user profile property, billing account, or cohort.

To breakdown your results click the Breakdown button and select an event property, user profile property, billing account, or cohort.

Custom events can be broken down by the property "Event Name".

The events drop down only shows events that were ingested within the last 30 days. To select events that have not been ingested in the last 30 days, type the name of the event in the Filter or Breakdown search bar. You must know the exact name of the event you want to select because event names are case sensitive.

To create a temporary cohort for the current report select Create cohort under the cohort filter or breakdown. A window will pop up where you can specify the restrictions of your cohort. Learn more about building a cohort .

Save a Report

To save a new report click on the Unsaved title at the top and enter a name at the top of the query builder, then click Save.

Deep links createanexperiencethatlinks users directlytothecontentthey desire.

Creatingaflexible deep link architecturein yourapplicationandusing toolslikeMixpanel’s Notifications allowsyour mobile teamtodrive user engagementtoprecise locations quicklyand effectively.

Intoday’s mobile ecosystem, movingbetweenapplicationsorwithin applicationscanbe friction-filledandleadtolow conversions. Forexample, when sendinganotificationtohaveyourusers tryanew feature, adeep linkcanpoint users preciselytotherelevant view.

Deep link in push notifications using this guide.

TheiOSandAndroid examplesareavailableinsample appshere: iOS, Android.

iOS (Objective-C)

IniOSyou needtofollowathree-step processtoset up deep linking.

Thefirsttwo stepswillrequire changestoyourXcode build. ExampleswillbeinObjective-C.

Registeracustom URLwithinXcode. Havingacustom URL scheme givesyourapplicationaname iOScanrecognize. Whenpresentedwith yourunique URL, iOSwillopenyourapplication.

UpdateourAppDelegate.mtolistenforadditional parametersontheURL. Whilestep1helps iOS knowtoopenyourapplication, step 2's AppDelegate alteration provides directionastowhatscreentheusershouldseeonapp open.

Deliveradeep linkthroughMixpanel in-app notifications. Thisisone effective waytomakeyournotifications harmonious.

Step1 Registeracustom URL

InyourXcode project, wewillneedtoregisteracustom URL identifier. Access yourinfo.plist filewithinyourSupporting Files. Addanew rowforURL Types. Expand Item0andcreateaURL identifier. Best practices assert namingyour domaininreverse: com.mixpanel.Deeplinkapp. You willnotneed toreferencethisURL identifier later.

UnderItem0 you canaddanew rowtocreateaURL scheme. Thisgivesyour applicationthespecific naming convention. Now, wheniOSispresentedwith yourregistered URL scheme, itknowstolaunchyourapplication.

‘Add Intent FiltersFor YourDeep Links’

InyouriOS simulator, testtheURL schemebyopening Safariandenteringinyour scheme. Yourapplicationshouldlaunch:

mixpanel://

Step2 Listenforcustom URLs

YourURL schemewillopenyourapplicationtoitshome screen. Next, you'll want todirectausertoaspecific view otherthanthehome screen.

Theformatofthese URLsarescheme, host, andpath: scheme://[host]/[path]. Thescheme launches theapplication, andthehostandthepath movetheusertoaseparate screen withintheapplication.

Update your AppDelegate’s default behaviortolisten forahostandapath. Addthefollowing codetoyourAppDelegate. Thisallows foradditional parameterstobe passedintoacustom URL:

-(BOOL)application:(UIApplication *)application

openURL:(NSURL *)url

sourceApplication:(NSString *)sourceApplication

annotation:(id)annotation

Nowweneedtoupdatethislistenertolookforaspecific hostandpath.

Belowshowsanifstatementthatdirectsausertothecorrect view controller givenamatch.

Ifmixpanel://deeplink/page1isclicked, itwilldirecttothePage1ViewController, aseparate screenfromthehome view.

Thiscode snippet alterstheprevious function:

-(BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {

if([[url host] isEqualToString:@"deeplink"]) {

if([[url path] isEqualToString:@"/page1"]) {

self.window.rootViewController = [[Page1ViewController alloc] init];

} else if ([[url path] isEqualToString:@"/page2"]) {

self.window.rootViewController = [[Page2ViewController alloc] init];

} else {

return NO;

}

} else {

return NO;

}

return YES;

}

Step3 Deliver deep linkthroughMixpanel

Finally, nowthatyourapplicationisset uptolistenforspecific information, let’s sendthatinformationoverthroughMixpanel!

Mixpanel linkwillbe: mixpanel://deeplink/page1.

Anyuserwhohasourapplicationon theirphonewillbe directedto ‘page1’ attachedtothePage1ViewController.

Android Java

InAndroid, thedeep link setup requires creatinganintent filtertoregisteraURL scheme. Uponthecreationofanintent filter, we’ll utilizethedata providedbythe intenttodeterminewhichscreentorender.

Registering URIwithAction, data, category

Threeelementswithinanintentareaction, data, andcategory.

Action - describeswhattheuseristryingtodo.

Data - describesthespecific URI thatwasclickedon.

Category - allowsanintent filtertobe accessiblefromeithera web browseroranimplicit intentbyincludingBROWSABLEandDEFAULT.

For more, feel freetoreadtheAndroid documentationunder.

You will now need to wraptheseelementsinanintent filterwithinyourAndroid Manifest.

Below, you’ll seeMixpanel utilizes thedata elementtoregisteraURL scheme mpdeeplink:// and addedahost called ‘newcontent’.

Now, when given mpdeeplink://newcontentpage, yourAndroid Manifestispreparedtoexecute anaction.

Handlingthe Intent

Androidhasinstantiatedanactivityinrespecttotheintent filteryouhaveset up.

Now, you canset upanintent handlertoappropriately directtheusertothe screen associatedwiththeprovided schemeandhost.

Theintent data is retrieved withinonCreate, and you canuse ‘Uri data’ tocreateanactivity.

Thebelow activity showsanalertandtracksanevent:

public class NewContentActivity extends Activity {

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);\

if (getIntent().getAction() == Intent.ACTION_VIEW) {

Uri data = getIntent().getData();

if (data != null) {

// show an alert with the "custom" param

new AlertDialog.Builder(this)

.setTitle("Welcome to New Content!")

.setMessage("Found custom param: " +data.getQueryParameter("custom"))

.setPositiveButton(android.R.string.yes, new DialogInterface.OnClickListener() {

public void onClick(DialogInterface dialog, int which) {

dialog.dismiss();

}

})

.setIcon(android.R.drawable.ic_dialog_alert)

.show();

}

}

// send a Mixpanel event

MixpanelAPI mMixpanel = MixpanelAPI.getInstance(this, MainActivity.MIXPANEL_API_TOKEN);

mMixpanel.track("in app activity event", null);

mMixpanel.flush();

}

}

Deliver ThroughMixpanel In-App Messages

Once you’ve createdanactivityforyourusers, testitwiththeMixpanel web app. Utilizethe ‘Touch Actions’ fieldinthein-app message creation buildertofillin yourcustom URL.

This article describes the support policy for Mixpanel users.

Mixpanel endeavors to provide the right information to the right user at the right time.

Resources

To ensure users get the information they want quickly, Mixpanel Support provides access to these resources:

Mixpanel Community

Crowdsource Mixpanel solutions and submit product ideas

Mixpanel Help Center

Best practices, user guides, and frequently asked questions

Developer Documentation

API integration tutorials, JQL help, and export information

Mixpanel Status Page

Updates on Mixpanel incidents to view or subscribe

Ticket Submission

The speed of the support team’s response time depends on your support plan and the severity level of your question.

If you’re on a paid plan, you can submit a ticket through the webform for any issue regardless of severity.

If you're on our free plan, you can submit a ticket through the webform for critical issues only.For any non-critical issues, visit our Community and Help Center.

Severity Levels

Critical

Persistent, widespread issues with no reasonable workaround available, such as system unavailability or significant performance degradation.

Official SDKs are persistently not operating in accordance with the documentation. Also includes issues accessing your account.

Significant

Integration troubleshooting, investigating data integrity issues, message configuration, and other inquiries for non-critical technical issues.

Other

Requests for information on product capabilities, building and analyzing reports, and best practices.

Regardless of the support plan, these issues are critical for all users:

I don't have the features I'm paying for

Unable to access Mixpanel

Login issues

Data delays

Request a plan change or a refund

GDPR compliance requests

Contact

For information about chat, 24-hour coverage, response time SLAs, and more, contact [email protected].

Mixpanel’s Funnels allows you to examine how end-users perform events in a series. This article explains Funnels report basics.Learn about how to build a Funnels report in this article.Learn about how to interpret a Funnels report in this article.

Funnels

Funnelscalculate and display the amount of users that convert from one event to another.This allows you to identify where your users drop off, what segments convert the most, and other important facets of the user journey.

Loose Ordering

Your customers must complete the steps you designate in your funnel in loose order. Loose order means that a customer can engage in other actions in between funnel steps, as long as they complete all the funnel steps in order. Let's start with an example where the funnel has steps: A, B, C, D, E and go through a few cases:

The customer does steps A -> B -> C -> D -> E in exact order. Mixpanel counts this as a conversion.

The customer does steps A -> B ->F-> C -> D -> E. Mixpanel counts this as a conversion. This is an example of loose ordering.

The customer does steps A -> B -> C -> E. Mixpanel will not count this as a full conversion, and the customer will not appear in the funnel after step C. The customer's completion of step E is excluded from the funnel because step D did not occur.

The Retention report in Mixpanel is designed to create a normalized, actionable metric to assess user engagement over a specified period of time. Users are broken into buckets based on when they first completed an action, and then subsequent buckets based on when they came back and performed either the same action or a different action.

Click here to learn more about how to build a Retention report. Click here to learn more about how to interpret a Retention report.

Retention calculations are based on unique users, not total event count.

You can select either Recurring, First Time, or Frequency from the drop-down list at the top left of the query builder. Each of these reports uses the same methods of calculation but allows you to specify which event and property combination performed is creating the user buckets and measuring your user retention.

Access the Retention Report

To view the Retention report select Retention from the Analysis section of Mixpanel.

Recurring Retention

Recurring Retention allows you to specify a single event and see the retention of users coming back to perform this same event over time. This report tells you how often users come back and perform the same events.

First Time Retention

First Time Retention allows you to specify one event to create the user bucket you are measuring, and another event to measure the retention on. Similar to recurring retention, you also have the option to choose “anything” as the event. This report is useful for tracking users who performed a specific event (such as sign-up), and how often they came back to do some other action on your site.

This report retrieves the first instance of the bucketing event in the defined time range, but it doesn’t take into account whether it’s the first time of all-time a user has done a certain action. For example, if you select “Add payment method” as your bucketing event, the user buckets will include all users who did the event “Add payment method” during the report time frame, not the first time in that user’s lifecycle.

Frequency Retention

Frequency Retention allows you to specify an event and see how often a user performed that same event in the future. Whereas the above retention calculations will return the number of users who performed an event, frequency will actually calculate the number of times each user who came back performed the event. This allows you to see how "active" your users are over the course of a given time period.

Using the frequency report will allow you to see how many hours in a day, days in a week, or days in a month your retained users are performing a specific event. As with the other reports, you also have the option to choose “Anything” to see generally how often users are performing events.

Power User Curve

TheFrequency report shows cumulative numbers in the report by default, but you can choose to select NON-CUMULATIVE from the top of the report chart. Non-cumulative numbers will give you a Power User Curve of your users’ frequency retention over time. For example, a userwill count in the 1 hour, 2 hour, 3 hour, 4 hour and 5 hour columns if the user completes an event each hour in a cumulative frequency report broken down by day. With non-cumulative frequency, this user would only count in the 5 hour columns in a frequency report broken down by day.

What should I be tracking? What are other companies in my space tracking? These are common questions you might ask when you think about your analytics.

There is no single set of metrics that works for everyone. Businesses and products are all unique and have different goals; even departments in the same company may have different ideas of success from one another. With those differences in mind, we’ve crafted a framework to help you find the right metrics for your product.

Here, we will use this framework to help you define your metrics and clarify the relationship among them so each team understands how their metrics connect to the overall product performance.

Types of Metrics

Most companies have a variety of metrics they use to measure overall product performance. In this group of metrics there is often one that is slightly more important than the others. We refer to your most important metric as the focus metric. The subsequent metrics that other teams or individuals spend their time on that help drive the focus metric are called Level 1 and Level 2 metrics.

Focus Metric - what matters most to your business

Focusing on a single metric can be limiting so we suggest a flexible framing with a focus metric, a metric that works with other key performance indicators (KPIs).

Focus metrics should be a top priority, not the sole priority, and you should not accomplish KPI improvement at the expense of harming other KPIs.

We usually recommend choosing a focus metric tied to active usage, such as Weekly (WAU) or Monthly (MAU) Active Users. These metrics do a good job summing up trends in other metrics, like acquisition, and retention by showing whether more people are using the product over time.

To know whether you have a useful focus metric, ask yourself this:“If we improve this number, will the product’s long-term performance improve?”

Level 1 Metrics

Level 1 (L1) metrics should either directly contribute to the focus metrics or act as a check to ensure the product is growing in a healthy direction. For example, if a product’s focus metric is WAU, a good L1 metric related would be 7-day retention. If users are being retained within 7 days, WAU will be on an upwards trend.

Level 2 Metrics

Level 2 metrics help contribute to the L1 metrics, and achieving these metrics ultimately help the company’s overall health and performance. You can add as many levels of metrics as you’d like, as long as each level is related and or acts as a check to the others.

Ensuring the metrics being added are done with purpose is paramount to a successful analytics strategy. Too many layers of metrics can create confusion, leading to scenarios where everyone has different ideas about where to spend their time to make the product successful.

Organizing your Metrics

Once set up, there should be an upwards relationship between your Level 1, Level 2 and focus metric, like the example below.

How To Name Your Mixpanel Data

A Guide To Product Metrics

To see industry specific metric examples, download the full Guide To Product Metrics

Key Metric Categories

Users must show up in the product and perform actions to become active users. A user’s value is determined by the level of their engagement and whether they come back or stick long-term. Regardless of your product, there is a set of core categories that represent a typical user lifecycle: reach, activation, active usage, engagement and retention.

Reach

Reach is the total number of people who have used the product in recent time period. Reach represents the maximum amount of users who could reasonably become active, whether organically or through re-engagement campaigns.

For example, for consumer companies reach could be the number of paid accounts, or users who have made at least one purchase in the past three months.

Activation

Activation is a foundational step that primes a new user to become an active user.

Activation may be defined as completing the registration form, making a first purchase, viewing five videos, or making two deposits within a specific time period.

View the metrics a percentage of new users isolating it from natural user growth, to see if you’re more successful at activating users over time.

Active Users

Active users are people who have taken a key action and received value from your product within a recent time period. Value can be defined as one action, or a set of actions. For a music playing service, activation can be when a user plays a number of songs. However, value can be perceived when a playlist is created or shared.

The exact triggers or definitions of “active” should be tailored specifically to your product.

Engagement

Engagement accounts for frequency and pace of completing key actions.

Engagement could be defined as the number of key actions taken, minutes of video watched or number of transactions completed. Divide this by your active user count to measure the depth of engagement per user with your product. Otherwise, user growth might mislead you into thinking your product is more sticky than it is.

The exact trigger or definition of “engagement” should be tailored specifically to your product.

Retention

Retention is the metric that shows whether your product is sticky. When deciding a time frame for retention goals, pick a period that is long enough to capture the reasonable repeat cycle of your customers, yet short enough that teams can get feedback to iterate quickly. We generally recommend having 7-day retention as a leading indicator for 30 or 90-day retention.

Business-specific metrics

If you have a metric in mind that wasn’t listed but is important to your product, then make sure to include it in your framework. Those metrics are business-specific metrics.

For example, a dating app would consider users who find a lasting relationship through the app and leave as a metric of “good churn”. While this involves losing users, it’s good for business because happy customers are more likely to spread the word and refer more friends.

Do-It Yourself Template

Setting up your framework is a crucial step, but only the beginning. Below is a blank template for you to apply the framework to your product. Fill out the blanks and either work your way down or define the L2 metrics to help determine your focus metric.

Next Steps

Once you've determined your goals and metrics, the next step is to set standards for your naming your events and properties. covers how to keep your data clean, concise and consistent.

Contents: [

Installing the Library

,

Initializing the Library

,

Opting Users Out of Tracking

,

Automatically Track Events

,

Sending Events

,

Timing Events

,

Super Properties

,

Group Analytics

,

Managing User Identity

,

Storing User Profiles

,

Tracking Revenue

,

Registering for Push Notifications

,

A/B Testing Experiments

,

A/B Developer Tweaks

,

Debugging and Logging

,

About ARC

][CocoaPods, Carthage, Manual installation, Opting Users Out of Tracking by Default, Delete Existing Data, Setting Super Properties Only Once, Super Properties Live in Local Storage, Add Group Keys

, Creating a Group Key, Creating Group Profiles, Setting Group Profile Properties, set, set once, unset, remove, union, delete, NOTE

, Combining Anonymous and Identifiable User Data, NOTE

, Call Reset at Logout, NOTE

, Setting Profile Properties, NOTE

, Incrementing Numeric Properties, Other Types of Profile Updates, Push Notifications Quick Start Guides, In-App Messages, Prerequisites, NOTE

, Notes on Experiment Delivery, Objective-C, Value Tweaks, Flow Control Tweaks, Binding Tweaks]

Visit the Dev Docs A better version of this page exists at https://developer.mixpanel.com/docs/ios.

Installing the Library

Use the Mixpanel Objective-C library with iOS, macOS, watchOS, and tvOS.

CocoaPods

The easiest way to get Mixpanel into your iOS project is to use CocoaPods.

If this is your first time using CocoaPods, Install CocoaPods using gem install cocoapods. Otherwise, continue to Step 3.

Run pod setup to create a local CocoaPods spec mirror.

Create a Podfile in your Xcode project directory by running pod init in your terminal, edit the Podfile generated and add the following line: pod 'Mixpanel'.

Run pod install in your Xcode project directory. CocoaPods should download and install the Mixpanel library, and create a new Xcode workspace. Open up this workspace in Xcode or typing open *.xcworkspace in your terminal.

Carthage

Mixpanel supports Carthage to package your dependencies as a framework. Include the following dependency in your Cartfile:

github "mixpanel/mixpanel-iphone"

github "mixpanel/mixpanel-iphone"

Check out the Carthage docs for more info.

Manual installation

You can also get the library by downloading the latest version from GitHub and copying it into your project. We have step-by-step instructions on how to manually install the Mixpanel library.

Initializing the Library

To start tracking with the Mixpanel iOS library, you must first initialize it with your project token. Find your project token by clicking your name in the upper righthand corner of your Mixpanel project and selecting Settings from the dropdown.

In most cases, it makes sense to do this in application:didfinishlaunchingwithoptions:.

To initialize the library, first add #import "Mixpanel/Mixpanel.h" and call sharedInstanceWithToken: with your project token as its argument. Once you've called this method once, you can access your instance throughout the rest of your application with sharedInstance.

[Mixpanel sharedInstanceWithToken:@"YOUR_API_TOKEN"];

[Mixpanel sharedInstanceWithToken:@"YOUR_API_TOKEN"];

Opting Users Out of Tracking

Client-side tracking of individual user data can be stopped or resumed by controlling a user’s opt-out/opt-in state. Opt-out methods and library configuration settings only affect data sent from a single library instance. Data sent from other sources to Mixpanel’s APIs will still be ingested regardless of whether the user is opted out locally.

The opt-out/opt-in state of a user is controlled by an opt-out flag that is stored in the local storage of the user’s device. If the value of the flag is true, then the user is opted-out and will not be tracked. If the opt-out flag is false, then the user is tracked. The flag is not set when the SDK is initialized, so the initial state is neither opted in nor opted out. Without the flag set, the user will be tracked by default.

To opt a user out of tracking locally, use the optOutTracking method. To resume tracking for an individual user, use optInTracking. Call hasOptedOutTracking to check user’s opt-out status locally. By default, an "$opt_in" event is sent every time that a user opts in.

// Opt a user out of data collection

Mixpanel *mixpanel = [Mixpanel sharedInstance];

[mixpanel optOutTracking];

// Check a user's opt-out status

// Returns true if user is opted out of tracking locally

BOOL hasOptedOutTracking = [mixpanel hasOptedOutTracking];

// Opt a user out of data collection

Mixpanel *mixpanel = [Mixpanel sharedInstance];

[mixpanel optOutTracking];

// Check a user's opt-out status

// Returns true if user is opted out of tracking locally

BOOL hasOptedOutTracking = [mixpanel hasOptedOutTracking];

Opting Users Out of Tracking by Default

Mixpanel’s tracking libraries will send user data by default. Explicitly initializing a default opt-out state of YES will opt-out all users by default, preventing data from sending unless a user’s opt-out state is set to NO.

// Initializing a default opt-out state of YES

// will prevent data from being collected by default

Mixpanel *mixpanel =

[Mixpanel sharedInstanceWithToken:@"YOUR_API_TOKEN"

optOutTrackingByDefault:YES];

// Initializing a default opt-out state of YES

// will prevent data from being collected by default

Mixpanel *mixpanel =

[Mixpanel sharedInstanceWithToken:@"YOUR_API_TOKEN"

optOutTrackingByDefault:YES];

Delete Existing Data

Opting users out of tracking will stop any future tracking. This does not automatically delete data that has already been collected. Mixpanel's deletion API can be used to delete existing data.

Automatically Track Events

After installing the library into your iOS app, Mixpanel will automatically collect common mobile events. You can enable/disable automatic collection in the Mixpanel settings menu. In addition, Mixpanel allows you to use our in-browser editor to add tracking on the fly.

Navigate to our editor by clicking the gear in the upper righthand corner of your Mixpanel project and selecting Codeless Tracking from the dropdown.

Sending Events

We recommend tracking only five to seven events in your application instead of tracking too many things to start. Ideally, you track users going through your initial user experience and one key metric that matters for your application (e.g. a video streaming service might choose "Watched Video" as a key metric).

Once you've initialized the library, you can track an event by calling track:properties: with the event name and properties.

Mixpanel *mixpanel = [Mixpanel sharedInstance];

[mixpanel track:@"Plan selected"

properties:@{ @"Plan": @"Premium" }];

Mixpanel *mixpanel = [Mixpanel sharedInstance];

[mixpanel track:@"Plan selected"

properties:@{ @"Plan": @"Premium" }];

Timing Events

You can track the time it took for an action to occur, such as an image upload or a comment post, using timeEvent:. This will mark the "start" of your action, which you can then finish with a track call. The time duration is then recorded in the "Duration" property.

Mixpanel *mixpanel = [Mixpanel sharedInstance];

[mixpanel timeEvent:@"Image Upload"];

[self uploadImageWithSuccessHandler:^{

[mixpanel track:@"Image Upload"];

}];

Mixpanel *mixpanel = [Mixpanel sharedInstance];

[mixpanel timeEvent:@"Image Upload"];

[self uploadImageWithSuccessHandler:^{

[mixpanel track:@"Image Upload"];

}];

Super Properties

It's very common to have certain properties that you want to include with each event you send. Generally, these are things you know about the user rather than about a specific eventfor example, the user's age, gender, or source.

To make things easier, you can register these properties as super properties. If you do, we will automatically include them with all tracked events. Super properties are saved to device storage, and will persist across invocations of your app. Mixpanel already stores some information as super properties by default; see a full list of Mixpanel default properties here.

To set super properties, call registerSuperProperties:

// Send a "Plan: Mega" property will be sent

// with all future track calls.

[mixpanel registerSuperProperties:@{@"Plan": @"Mega"}];

// Send a "Plan: Mega" property will be sent

// with all future track calls.

[mixpanel registerSuperProperties:@{@"Plan": @"Mega"}];

Going forward, whenever you track an event, super properties will be included as properties. For instance, if you call:

[mixpanel track:@"Signup" properties:@{

@"Source": @"Twitter"

}];

[mixpanel track:@"Signup" properties:@{

@"Source": @"Twitter"

}];

after making the above call to registerSuperProperties:, it is just like adding the properties directly:

[mixpanel track:@"Signup" properties:@{

@"Source": @"Twitter",

@"Plan": @"Mega"

}];

[mixpanel track:@"Signup" properties:@{

@"Source": @"Twitter",

@"Plan": @"Mega"

}];

Setting Super Properties Only Once

If you want to store a super property only once (often for things like ad campaign or source), you can use registerSuperPropertiesOnce:. This function behaves like registerSuperProperties: and has the same interface, but it doesn't override super properties you've already saved.

[mixpanel registerSuperPropertiesOnce:@{@"Source": @"ad-01"}];

[mixpanel registerSuperPropertiesOnce:@{@"Source": @"ad-01"}];

This means that it's safe to call registerSuperPropertiesOnce: with the same property on every app load, and it will only set it if the super property doesn't exist.

Super Properties Live in Local Storage

Our mobile libraries store your super properties in local storage. They will persist so long as the app is installed (between launches and updates). Uninstalling the app will remove that customers super properties.

Group Analytics

Add Group Keys

To start tracking groups data, add group keys in project settings. If you don't see group keys in your Project Settings, reach out to the Mixpanel Sales Team to purchase Group Analytics.

Mixpanel Group Analytics allows behavioral data analysis by selected groups, as opposed to individual users.

Grouping by identifiers other than the distinct_id will allow analysis at a company or group level when using Mixpanel analytics. Read this article to learn more about Group Analytics.

A group is identified by the group_key and group_id.

group_key is the property that connects event data for Group Analytics.

group_id is the identifier for a specific group.

If the property “company” is chosen for Group Analytics, “company” is the group_key, and “Mixpanel”, “Company A”, and “13254” are all potential group_id values.

A user can belong to multiple groups. All updates to a group operate on the group_key and group_id.

Creating a Group Key

Administer group keys through your Project Settings. Group keys are event properties. All events need to have a defined group key on them in order to be attributed to a group. Group keys are project specific, and the group key should be set up before group data is sent. Note that Mixpanel does not backfill historical data before the group key was implemented.

To administer group keys, navigate to your Project Settings. Click +Add Group Key under the GROUP KEYS section.

Enter an event property to attribute the group key to. You can also enter a display name for the group key. Click Save.

Creating Group Profiles

It is possible to create a Group profile that is similar to a user profile. You must call getGroup().set() to build a group profile. It is important to the group_key, group_id, and one property so that the profile is not empty.

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] set:@{@"h": @"yo”}]

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] set:@{@"h": @"yo”}]

Setting Group Profile Properties

You can add details to Groups by adding properties to them.

In order to update Group profile properties, you must specify the group that needs to be updated by calling getGroup():groupID().

The getGroup():groupID() method can be chained with other commands that edit properties specific to the group.

You can set the property $name to populate the name field at the top of the group profile.

These operations are similar to the corresponding operations for user profile property updates.

set

mixpanel.getGroup().set() updates or adds a property to a group.

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] set:@{@"h": @"yo”}]

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] set:@{@"h": @"yo”}]

set once

mixpanel.getGroup().setOnce() adds a property value to a group only if it has not been set before.

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] setOnce:@{@"h": @"just once”}]

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] setOnce:@{@"h": @"just once”}]

unset

mixpanel.getGroup().unset() unsets a specific property in the group.

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] unset:@"c"]

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] unset:@"c"]

remove

mixpanel.getGroup().remove() removes a specific value in a list property.

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] remove:@"c" value:@5]

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] remove:@"c" value:@5]

union

mixpanel.getGroup().union() adds the specified values to a list property and ensures that those values only appear once.

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] union:@"c" values:@[ @5, @4 ]]

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] union:@"c" values:@[ @5, @4 ]]

delete

mixpanel.getGroup().deleteGroup() deletes a group.

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] delete]

[[self.mixpanel getGroup:@"Company", groupID:@“Mixpanel”] delete]

Managing User Identity

The Mixpanel library will assign a default unique identifier (we call it a "distinct ID") to each unique user who installs your application. This distinct ID is saved to device storage so that it will persist across sessions.

If you choose, you can assign your own user IDs. This is particularly useful if a user is using your app on multiple devices or platforms (both web and mobile, for example). To assign your own distinct_ids, you can use identify:.

// Ensure all future events sent from

// the device will have the distinct_id 13793

[mixpanel identify:@"13793"];

// Ensure all future events sent from

// the device will have the distinct_id 13793

[mixpanel identify:@"13793"];

NOTE

Calling identify: with a new ID will change the distinctID stored on the device. Updates to user profiles are queued on the device until identify is called.

Combining Anonymous and Identifiable User Data

It's important to send the same distinct_id with each event that an individual user triggers. Events recorded with different distinct_ids will be treated in Mixpanel as if they were performed by different users.

There are times when it can be convenient to start referring to a user by a different identifier in your implementation. The most common case is after registration, when a user switches from being an anonymous user (with an anonymous distinct_id) to an authenticated user with an (authenticated id). In this case, you can create an Alias for the user to keep the distinct_id consistent. An alias is a string stored in a Mixpanel lookup table that is associated with an anonymous distinct_id. Once written, aliases are not editable. Any data sent to Mixpanel with an alias as the distinct_id will be remapped and written to disk using the alias's corresponding anonymous distinct_id. This allows you to start identifying a user by an authenticated id without changing the distinct_id that is ultimately written in Mixpanel.

// This makes the current ID (by default an auto-generated GUID)

// and '13793' interchangeable distinct ids (but not retroactively).

[mixpanel createAlias:@"13793"

forDistinctID:mixpanel.distinctId];

// To create a user profile, you must call identify

[mixpanel identify:mixpanel.distinctId];

// This makes the current ID (by default an auto-generated GUID)

// and '13793' interchangeable distinct ids (but not retroactively).

[mixpanel createAlias:@"13793"

forDistinctID:mixpanel.distinctId];

// To create a user profile, you must call identify

[mixpanel identify:mixpanel.distinctId];

The recommended usage pattern is to call both createAlias: and identify: (with the Mixpanel generated distinct_id, as shown in the example above) when the user signs up, and only identify: (with the aliased user ID) on future log ins. This will keep your signup funnels working correctly.

NOTE

If you use createAlias: we recommend only calling it once during the lifetime of the user.

Call Reset at Logout

Reset generates a new random distinct_id and clears super properties. Call reset to clear data attributed to a user when that user logs out. This allows you to handle multiple users on a single device. For more information about maintaining user identity, see the Identity Management: Best Practices article.

Generate a non-IFA distinct_id by setting the MIXPANEL_RANDOM_DISTINCT_ID pre-processor macro and calling reset on logout. Calling reset will only clear the existing distinct_id from the cookie (browser) or local storage (mobile). You can set the "MIXPANEL_RANDOM_DISTINCT_ID" pre-processor macro in your Preprocessor Macros on the Mixpanel framework target.

After you call reset, Mixpanel generates a new distinct_id. If the MIXPANEL_RANDOM_DISTINCT_ID preprocessor macro is set, the SDK will generate a random, persistent UUID that is not the IFA, to use as the distinct_id. The SDK will ensure that all distinct_ids will not be the IFA, and will use the UUID. Setting the MIXPANEL_RANDOM_DISTINCT_ID preprocessor macro and calling reset ensures that multiple users on the same device are not assigned the same alias.

Storing User Profiles

In addition to events, you can store user profiles in Mixpanel. Profiles are persistent sets of properties that describe a userthings like name, email address, and signup date.

You can use profiles to explore and segment users by who they are, rather than what they did. You can also use profiles to send messages, such as emails, SMS, or push notifications.

NOTE

Before you send profile updates, you must call identify:. This ensures that you only have actual registered users saved in the system.

Setting Profile Properties

You can set properties on a user profile with people.set:.

Updates to user profiles are queued on the device until is called.

// Sets user 13793's "Plan" attribute to "Premium"

[mixpanel.people set:@{@"Plan": @"Premium"}];

// Sets user 13793's "Plan" attribute to "Premium"

[mixpanel.people set:@{@"Plan": @"Premium"}];

This will set a "Plan" property, with a value "Premium", on user 13793's profile. If there isn't a profile with distinct_id 13793 in Mixpanel already, a new profile will be created. If user 13793 already has a property named "Plan" in their profile, the old value will be overwritten with "Premium".

NOTE

Pick your property names wisely. Feel free to use capitalization and spaces in between words.

There are a few limitations:

Your property names should not begin with $ or mp_. These properties are reserved for special properties sent by Mixpanel.

Your property names cannot begin or end with a space as they will automatically be trimmed.

Your property names and values cannot be longer than 255 characters. In practice they should be much shorter than that. Property names get cut off by our user interface at about 20 characters.

Click here to see a list of Mixpanel's reserved user profile properties.

Incrementing Numeric Properties

You can use people increment: to change the current value of numeric properties. This is useful when you want to keep a running tally of things, such as games played, messages sent, or points earned.

// Here we increment the user's point count by 500.

[mixpanel.people increment:@"point count" by:@500];

// Pass an NSDictionary to increment multiple properties

[mixpanel.people increment:@{

@"dollars spent": @17,

@"credits remaining": @-34

}];

// Here we increment the user's point count by 500.

[mixpanel.people increment:@"point count" by:@500];

// Pass an NSDictionary to increment multiple properties

[mixpanel.people increment:@{

@"dollars spent": @17,

@"credits remaining": @-34

}];

Other Types of Profile Updates

There are a few other types of profile updates. To learn more, please review the full MixpanelPeople API documentation.

Tracking Revenue

Mixpanel makes it easy to analyze the revenue you earn from individual customers. By associating charges with user profiles, you can compare revenue across different customer segments and calculate things like lifetime value.

You can track a single transaction with people trackCharge:. This call will add transactions to the individual user profile, which will also be reflected in the Mixpanel Revenue report.

// Tracks $100.77 in revenue for user 13793

[mixpanel.people trackCharge:@(100.77)];

// Refund this user $50

[mixpanel.people trackCharge:@-50];

// Tracks $25 in revenue for user 13793 on the 2nd of

// January

[mixpanel.people trackCharge:@25 withProperties:@{

@"$time": "2016-01-02T00:00:00"

}];

// Tracks $100.77 in revenue for user 13793

[mixpanel.people trackCharge:@(100.77)];

// Refund this user $50

[mixpanel.people trackCharge:@-50];

// Tracks $25 in revenue for user 13793 on the 2nd of

// January

[mixpanel.people trackCharge:@25 withProperties:@{

@"$time": "2016-01-02T00:00:00"

}];

Registering for Push Notifications

The Mixpanel library includes support for sending push notification device tokens to Mixpanel. Once you send a device token, you can use Mixpanel to send push notifications to your app.

You can send a device token to Mixpanel using people addPushDeviceToken:.

- (void)application:(UIApplication *)application

didRegisterForRemoteNotificationsWithDeviceToken:

(NSData *)deviceToken

{

Mixpanel *mixpanel = [Mixpanel sharedInstance];

// Make sure identify has been called before sending

// a device token.

[mixpanel identify:@"13793"];

// This sends the deviceToken to Mixpanel

[mixpanel.people addPushDeviceToken:deviceToken];

}

- (void)application:(UIApplication *)application

didRegisterForRemoteNotificationsWithDeviceToken:

(NSData *)deviceToken

{

Mixpanel *mixpanel = [Mixpanel sharedInstance];

// Make sure identify has been called before sending

// a device token.

[mixpanel identify:@"13793"];

// This sends the deviceToken to Mixpanel

[mixpanel.people addPushDeviceToken:deviceToken];

}

Push Notifications Quick Start Guides

There is a quick start guide for iOS push notifications available to help you get started with push notifications in your app. It includes instructions for provising your app to use the Apple Push Notification service (APNs), preparing your push SSL certificate from Apple and configuring your app for push notifications.

There is also a step by step guide to integrating Mixpanel push notifications with your app that covers uploading your push credentials to Mixpanel, registering your user's device token from your app, and handling inbound push notification messages.

In-App Messages

There is a quick start guide for iOS in-app messages to help you get integrated.

Make sure that you have already:

Included the latest version of the Mixpanel iOS library in your app

Made sure you are identifying your users in the app.

Created an in-app message on the Messages tab of the Mixpanel website

A/B Testing Experiments

Prerequisites

Getting started with A/B testing is quick and easy.

Make sure that you have already:

Included the latest version of the Mixpanel iOS library in your app (v2.5+)

Created an experiment on the A/B Testing tab of the Mixpanel website by connecting your app

To use the UI's visual experiment creator, please ensure that you're in the project appropriate to your app's current build (i.e., Production or Development). While not required, it's a good idea to connect your mobile device to WiFi while using the A/B designer.

Once you have created an experiment and, optionally, decided which users you wish to target, simply turn on the experiment to start serving your A/B test to customers.

NOTE

Planning to run an experiment on the initial view of your app ? It can take several seconds for experiments to be applied on first app open; as a result, we recommend against putting UX changes or developer Tweaks on the first view of your app. If you wish to A/B test on the initial app view you will need to take delivery latency into account. We recommend enabling the option checkForVariantsOnActive (to grab data when the app is opened) and joinExperimentsWithCallback method (to apply the variant data to the view).

Notes on Experiment Delivery

Mixpanel checks for any new experiments asynchronously on applicationDidBecomeActive. After the response is received, experiment changes and Tweaks are applied or removed where appropriate. To handle network availability, each experiment is cached on the device so they can be re-applied when the API call cannot be successfully made.

If you'd like more control over when this check for new experiments occurs, you can use the checkForVariantsOnActive flag and the joinExperiments or joinExperimentsWithCallback methods to download and apply experiments manually.

The $experiment_started event is fired when a given experiment (both changes and/or Tweaks) is first started on a device. The event will contain an $experiment_id property with the given experiment id which we encourage you to use within funnels, and our other reports.

A/B Developer Tweaks

For more complex changes that you want to A/B test, you can include small bits of code in your apps called Tweaks. Tweaks allow you to control variables in your app from your Mixpanel dashboard. For example, you can alter the difficulty of a game, choose different paths through the app, or change text. The possibilities are endless.

Objective-C

To use Tweaks in any Objective-C file in your app, you need to import one file.

#import "Mixpanel/MPTweakInline.h"

#import "Mixpanel/MPTweakInline.h"

Value Tweaks

A value Tweak allows you to assign a value to a variable that can be changed later. The simplest Tweak looks like this:

NSInteger numLives = MPTweakValue(@"number of lives", 5);

NSInteger numLives = MPTweakValue(@"number of lives", 5);

Once you add this line, you will see a Tweak called "number of lives" with a default value of 5 in the Mixpanel A/B test designer. You can then create an A/B test with a different value for "number of lives". For example, you could set up an experiment where 50\% of your users start a game with 5 lives, and 50\% start with 10 lives. When there are no experiments running, the value of numLives will simply be the default of 5.

Flow Control Tweaks

Value tweaks can also be used to control flow in your app.

if (MPTweakValue(@"show alternate view", NO)) {

// Show alternate view.

} else {

// Show original view

}

if (MPTweakValue(@"show alternate view", NO)) {

// Show alternate view.

} else {

// Show original view

}

By default, the alternate view will not show. But you can now set up an A/B test that flips this value to YES for a percentage of your users.

If you have more than 2 options, you could use a switch.

switch (MPTweakValue(@"Action to take", 1)) {

case 1:

// Do something

break;

case 2:

// Do something else

break;

case 3:

// Do a third thing

break;

}

switch (MPTweakValue(@"Action to take", 1)) {

case 1:

// Do something

break;

case 2:

// Do something else

break;

case 3:

// Do a third thing

break;

}

You can use Tweaks to assign values to UI elements too.

UILabel *label = [[UILabel alloc] init];

label.text = MPTweakValue(@"label text", @"Hello World");

label.hidden = MPTweakValue(@"label is hidden", NO);

UILabel *label = [[UILabel alloc] init];

label.text = MPTweakValue(@"label text", @"Hello World");

label.hidden = MPTweakValue(@"label is hidden", NO);

Binding Tweaks

When designing an A/B test in Mixpanel, MPTweakValue changes will only apply when the code block they are in is executed. For example if you have an MPTweakValue to assign text to a label on viewDidLoad, and you made changes to the Tweak in the A/B test designer, you would not see the changes apply until the next time viewDidLoad was called. If you would like to see your changes applied immediately when designing a test, you can use MPTweakBind to accomplish this.

UILabel *label = [[UILabel alloc] init];

MPTweakBind(label, text, @"label text", @"Hello World");

UILabel *label = [[UILabel alloc] init];

MPTweakBind(label, text, @"label text", @"Hello World");

The first 2 arguments are an object and a property. Whenever the Tweak is changed in the A/B test designer, you will immediately see the new value of the Tweak applied to the given object and property, in this case label.text.

Debugging and Logging

You can turn on Mixpanel logging by enabling the following flag in application:didfinishlaunchingwithoptions:.

[Mixpanel sharedInstance].enableLogging = YES;

[Mixpanel sharedInstance].enableLogging = YES;

Alternatively, you can add the following Preprocessor Macros in Build Settings:

MIXPANEL_DEBUG=1 - logs queueing and flushing of events to Mixpanel

MIXPANEL_ERROR=1 - logs any errors related to connections or malformed events

If you're using CocoaPods, you'll need to add this to the Pod target instead of your main app project's target:

You can also add this to your Podfile to ensure everyone on your team will always have logging enabled:

post_install do |installer|

installer.pods_project.targets.each do |target|

target.build_configurations.each do |config|

settings = config.build_settings['GCC_PREPROCESSOR_DEFINITIONS']

settings = ['$(inherited)'] if settings.nil?

if target.name == 'Pods-MyProject-Mixpanel'

settings << 'MIXPANEL_DEBUG=1'

settings << 'MIXPANEL_ERROR=1'

end

config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] = settings

end

end

end

post_install do |installer|

installer.pods_project.targets.each do |target|

target.build_configurations.each do |config|

settings = config.build_settings['GCC_PREPROCESSOR_DEFINITIONS']

settings = ['$(inherited)'] if settings.nil?

if target.name == 'Pods-MyProject-Mixpanel'

settings << 'MIXPANEL_DEBUG=1'

settings << 'MIXPANEL_ERROR=1'

end

config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] = settings

end

end

end

About ARC

As of version 2.2.0 the Mixpanel iOS library uses ARC.

If you are using Mixpanel in a project that does not have ARC enabled, you need to enable ARC for just the Mixpanel source files in your Xcode project settings. This is done by adding the -fobj-arc compiler flag to each Mixpanel file under Build Phases -> Compile Sources.

Contents: [

Creating a Webhook Campaign

,

Receiving Webhook POSTS

,

Testing Webhooks

][Targeting Users, Scheduling your Webhook Campaign, NOTE

]

Visit the Dev Docs A better version of this page exists at https://developer.mixpanel.com/docs/webhooks.

Mixpanel allows you to tie data to a specific user, creating a profile. This is where you store things like their email address, where they came from, or their age. Webhooks allow you to notify yourself whenever a user first matches your campaign criteria.

Webhook targeting can be based on properties in user profiles, or events that did or did not occur within the last 90 days. For example, if you set a Last login property, you can create an webhook that notifies you about users who haven't used your service for three weeks.

Creating a Webhook Campaign

Each webhook campaign requires a URL to post data to. To create a new webhook campaign, navigate to the Messages report and select Webhook from the "Create new message" dropdown. This will give you the following form:

Targeting Users

When you submit the form, it will ask you to define the targeting criteria for your message. You can use many combinations of profile properties when you're creating a real message.

Scheduling your Webhook Campaign

Once you've targeted your users, you just have to schedule the webhook campaign. There are two options for scheduling campaigns:

ASAP Messages: These messages go out to individual users as soon as they match the targeting criteria. It's common for users to go from "not matching" to "matching" - many messages include a time-based requirement such as "last login was greater than two weeks ago", or one based off of other profile properties that may change.

Scheduled Messages: These messages can be set to go out at a specified time, day of week, and interval. For example, you could set your message to go out at 9am PST every Wednesday. When the message runs, it finds all the users who match the criteria you have defined and sends it to them.

Receiving Webhook POSTS

A webhook is simply a remote HTTP endpoint that Mixpanel can POST data to when a new user matches the message criteria.

To receive a Mixpanel webhook, set up an endpoint on your web server exactly like you would for any other page that receives POST requests. We recommend you choose an endpoint that doesn't handle any other requests. Then specify this endpoint in Mixpanel during the message setup.

Mixpanel will send a POST request to the endpoint whenever the conditions of the message are satisfied. The POST request will be much like a standard POST request made from submitting an HTML form, with a content type of application/xwwwformurlencoded and a single parameter named users. The users parameter will contain a JSON list with data for up to 50 users. If there are more than 50 users that satisfy the message conditions, Mixpanel will batch these users up into sets of 50 and make a POST request for each batch.

Here's an example of the JSON we will send you:

[

{

"$distinct_id":"13b20239a29335",

"$properties":{

"$region":"California",

"$email":"[email protected]",

"$last_name":"Bovik",

"$created":"2012-11-20T15:26:16",

"$country_code":"US",

"$first_name":"Harry",

"Referring Domain":"news.ycombinator.com",

"$city":"Los Angeles",

"Last Seen":"2012-11-20T15:26:17",

"Referring URL":"http://news.ycombinator.com/",

"$last_seen":"2012-11-20T15:26:19"

}

},

{

"$distinct_id":"13a00df8730412",

"$properties":{

"$region":"California",

"$email":"[email protected]",

"$last_name":"Lytics",

"$created":"2012-11-20T15:25:38",

"$country_code":"US",

"$first_name":"Anna",

"Referring Domain":"www.quora.com",

"$city":"Mountain View",

"Last Seen":"2012-11-20T15:25:39",

"Referring URL":"http://www.quora.com/What-...",

"$last_seen":"2012-11-20T15:25:42"

}

}

]

[

{

"$distinct_id":"13b20239a29335",

"$properties":{

"$region":"California",

"$email":"[email protected]",

"$last_name":"Bovik",

"$created":"2012-11-20T15:26:16",

"$country_code":"US",

"$first_name":"Harry",

"Referring Domain":"news.ycombinator.com",

"$city":"Los Angeles",

"Last Seen":"2012-11-20T15:26:17",

"Referring URL":"http://news.ycombinator.com/",

"$last_seen":"2012-11-20T15:26:19"

}

},

{

"$distinct_id":"13a00df8730412",

"$properties":{

"$region":"California",

"$email":"[email protected]",

"$last_name":"Lytics",

"$created":"2012-11-20T15:25:38",

"$country_code":"US",

"$first_name":"Anna",

"Referring Domain":"www.quora.com",

"$city":"Mountain View",

"Last Seen":"2012-11-20T15:25:39",

"Referring URL":"http://www.quora.com/What-...",

"$last_seen":"2012-11-20T15:25:42"

}

}

]

NOTE

You must respond with a 200 OK HTTP response for Mixpanel to mark the users in the message as being successfully sent to the webhook. Otherwise, we will assume the webhook for the users in that POST request failed, and we will send them again in the next message attempt.

Testing Webhooks

When testing Mixpanel Webhooks through the Messages report, five profiles will be randomly selected from your project and delivered to the defined Webhook URL. You will want to make sure that your receiver does not inadvertently deliver these profiles as it would in production.

Contents: [

Prerequisites

,

Viewing Old Events

,

Send your Events

,

Batching Requests

][]

Visit the Dev Docs A better version of this page exists at https://developer.mixpanel.com/docs/importing-old-events.

Use the /import endpoint to get events into your Mixpanel project older than five days that you might want to include if you’re a new customer and previously collected data elsewhere.

Prerequisites

Every event must have a time property specifying a timestamp in the past.

You must already be using mixpanel.identify() or in some other way setting the distinct_id to keep track of your users within Mixpanel.

If you are not using mixpanel.identify() or a distinct_id and would like to import events, you can contact support for assistance.

Viewing Old Events

By default, Mixpanel’s Engagement report dropdown menus hide events that have not been fired within the last 30 days. So if you import data that's over 30 days old and there are no instances of that event within the last 30 days, the dropdown menus will not display that event name.

To have an imported event that’s older than 30 days show in the dropdowns, you can:

Fire a single instance of that event to bring it within the UI; OR

Force the event to show in the dropdown by adjusting the URL to:

https://mixpanel.com/report/YOURPROJECTNUMBER/segmentation/#action:segment,arb_event:'YOUREVENTNAME',bool_op:and,chart_analysis_type:linear,chart_type:line,from_date:-365,to_date:0,type:general,unit:month

https://mixpanel.com/report/YOURPROJECTNUMBER/segmentation/#action:segment,arb_event:'YOUREVENTNAME',bool_op:and,chart_analysis_type:linear,chart_type:line,from_date:-365,to_date:0,type:general,unit:month

Be sure to replace YOURPROJECTNUMBERand YOUREVENTNAME with the specific values for your project.

Send your Events

If you meet the prerequisites, you can write a one-off script to send your events to Mixpanel for all your users.

To do this, for every event in your database you would make an POST request that looks like this:

curl https://api.mixpanel.com/import \

-u YOUR_API_SECRET: \

-d data=eyJldmVudCI6ICIkc2lnbnVwIiwgInByb3BlcnRpZXMiOiB7ImRpc3RpbmN0X2lkIjogIjQ4MSIsICJ0aW1lIjogMTMyMTQ5OTM3MSwgInRva2VuIjogIjEzZmUzZGRjODZlYjZmOTBjNGVlN2QwZDQ3NTYzMTUwIn19 \

-d verbose=1

curl https://api.mixpanel.com/import \

-u YOUR_API_SECRET: \

-d data=eyJldmVudCI6ICIkc2lnbnVwIiwgInByb3BlcnRpZXMiOiB7ImRpc3RpbmN0X2lkIjogIjQ4MSIsICJ0aW1lIjogMTMyMTQ5OTM3MSwgInRva2VuIjogIjEzZmUzZGRjODZlYjZmOTBjNGVlN2QwZDQ3NTYzMTUwIn19 \

-d verbose=1

This request is very similar to our standard HTTP API. The data parameter is a Base64 encoded JSON array with the event you are importing ($signup) and the associated properties.

By decoding the Base64 data parameter from the above request, you can see the raw JSON:

{ "event": "$signup",

"properties": {"distinct_id": "481",

"time": 1321499371,

"token": "13fe3ddc86eb6f90c4ee7d0d47563150"}}

{ "event": "$signup",

"properties": {"distinct_id": "481",

"time": 1321499371,

"token": "13fe3ddc86eb6f90c4ee7d0d47563150"}}

Event = You can set this to any event, but $signup is particularly useful for retention analysis.

Distinct_id = The user ID you have been sending to Mixpanel up to this point for that user. In general, this is the value you pass into the identify method.

Time = A unix epoch style timestamp in UTC that tells Mixpanel when the event fired. This can be any time in the last 5 years. The above example, 1321499371, represents November 17th, 2011 at 3:09 AM GMT.

Token = The token property is your Mixpanel project token, which you can find by clicking your name in the upper righthand corner of your Mixpanel project and selecting Settings from the dropdown. Don’t confuse your API Secret with your project token!

Batching Requests

Using the /import endpoint, you can also batch requests to Mixpanel instead of sending one event per request. The endpoint will accept up to 50 messages in a single batch.

You can read more about batching requests to Mixpanel in our HTTP API documentation.

Contents: [

Controlling When to Show an In-App Message

,

Using Profile Properties

][In App Messages - Supported Library Versions

, Integration, NOTE

]

Visit the Dev Docs A better version of this page exists at https://developer.mixpanel.com/docs/android-inapp-messages.

Mixpanel enables you to create and send rich in-application messages to users browsing your website. If you are using our in-app messages product, there are three things you need to make sure of.

Include the latest version of the Mixpanel Android Library on your website.

Make sure you are identifying your users in your app.

Create an in-app message on the Messages tab of the Mixpanel website.

In App Messages - Supported Library Versions

In-app messages are supported in Android library versions 4.9.4+.

Integration

The Mixpanel Android library automatically checks for messages in the background, and will attempt to display them anytime an Activity is displayed. If you only wish to use mini in-app messages, then no extra integration is necessary.

If you wish to use takeover messages, then you must declare TakeoverInAppActivity in your AndroidManifest.xml file.

<activity android:name="com.mixpanel.android.takeoverinapp.TakeoverInAppActivity" android:theme="@style/com_mixpanel_android_TakeoverInAppActivityTheme"/>

<activity android:name="com.mixpanel.android.takeoverinapp.TakeoverInAppActivity" android:theme="@style/com_mixpanel_android_TakeoverInAppActivityTheme"/>

NOTE

For versions prior to 5.0.0 you should use com.mixpanel.android.surveys.SurveyActivity and @style/com_mixpanel_android_SurveyActivityTheme instead.

The specified theme is a general Mixpanel default, so feel free to substitute your own theme to better match the look and feel of your application.

Controlling When to Show an In-App Message

You may not want the messages to show everytime a new Activity is displayed. For example, if you have a game and only want to show a message when a user accomplishes a goal, you need to turn off the automatic showing of messages by adding the following option in the <application> section of your AndroidManifest.xml file.

<meta-data android:name="com.mixpanel.android.MPConfig.AutoShowMixpanelUpdates"

android:value="false" />

<meta-data android:name="com.mixpanel.android.MPConfig.AutoShowMixpanelUpdates"

android:value="false" />

To manually check if an in-app message is available, you may call MixpanelAPI.getPeople().getNotificationIfAvailable(). This method will return an InAppNotification object if the Mixpanel library has received an in-app message for the currently identified user, and null otherwise. You may then use this object to render your own in-app message.

You can also call MixpanelAPI.getPeople().showNotificationIfAvailable() to allow the Mixpanel library to show an in-app message for you.

Note that MixpanelAPI.getPeople().showNotificationIfAvailable() will not display a message if there is already a message showing, so it is safe to call this function at any location where you want to potentially display a message

Using Profile Properties

Just like emails, in-app messages will replace content wrapped in {{}}. For example, if you add a Location property to your user profiles, you can send messages like this:

Come and visit us at our {{ ${Location} }} office!

Come and visit us at our {{ ${Location} }} office!

A user with a profile property Location: Asheville will get the following message:

Come and visit us at our Asheville office!

Come and visit us at our Asheville office!

If some of your profiles have a value, but others don't, you can use a fallback value:

Come and visit us at our {{ ${Location} | fallback:"nearest" }} office!

Come and visit us at our {{ ${Location} | fallback:"nearest" }} office!

Profiles without a Location property will receive this message:

Come and visit us at our nearest office!

Come and visit us at our nearest office!

Contents: [

JavaScript Library

,

Installing the Library

,

Sending Events

,

Super Properties

,

Managing User Identity

,

Storing User Profiles

,

Tracking Revenue

,

Debugging and Logging

,

Scaling your Server-Side Tracking

][NOTE

, Super Properties Live in Local Storage, NOTE

, Setting Profile Properties, NOTE

, Incrementing Numeric Properties, Appending to List Properties, Other Types of Profile Updates, Message Consumers]

Visit the Dev Docs A better version of this page exists at https://developer.mixpanel.com/docs/php.

The Mixpanel PHP library is designed to be used for scripting, or in circumstances when a client can't or won't run client side scripts

JavaScript Library

Mixpanel also provides a powerful and easy to use client-side JavaScript library for web applications. This library offers platform-specific features and conveniences that can make Mixpanel implementations much simpler, and can scale naturally to an unlimited number of clients. The client-side JavaScript library is the preferred way to add Mixpanel to user-facing web applications.

Mixpanel also provides a client-side JavaScript library for web applications. This library offers platform-specific features and conveniences that can make Mixpanel implementations much simpler, and can scale naturally to an unlimited number of clients. The client-side JavaScript library is the preferred way to add Mixpanel to user-facing web applications.

Installing the Library

You can get the library using Composer by including the following in your project's composer.json requirements and running composer update:

"require": {

...

"mixpanel/mixpanel-php" : "2.*"

...

}

"require": {

...

"mixpanel/mixpanel-php" : "2.*"

...

}

If you're not using Composer for your package management, you can browse and download the library from GitHub at https://github.com/mixpanel/mixpanel-php.

Our library requires PHP 5.0 or greater.

Sending Events

Track events in the mixpanel-php library by using the track method on the Mixpanel class:

<?php

// import dependencies (using composer's autoload)

// if not using Composer, you'll want to require the

// lib/Mixpanel.php file here

require "vendor/autoload.php";

// get the Mixpanel class instance, replace with your

// project token

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// track an event

$mp->track("button clicked", array("label" => "sign-up"));

<?php

// import dependencies (using composer's autoload)

// if not using Composer, you'll want to require the

// lib/Mixpanel.php file here

require "vendor/autoload.php";

// get the Mixpanel class instance, replace with your

// project token

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// track an event

$mp->track("button clicked", array("label" => "sign-up"));

Mixpanel determines default geolocation data ($city, $region, mp_country_code) using the IP address on the incoming request. As all server-side calls will likely originate from the same IP (that is, the IP of your server), this can have the unintended effect of setting the location of all of your users to the location of your datacenter. Read about best practices for geolocation with server-side implementations.

Super Properties

Super properties are properties that get sent with every subsequently tracked event. This is very useful for associating properties such as "Ad Source" to every event. If I want to send an "Ad Source" of "Google" for every event I track, I can store it in my Mixpanel instance with the register method:

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// register the Ad Source super property

$mp->register("Ad Source", "Google");

// track an event with a property "Ad Source" = "Google"

$mp->track("button clicked");

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// register the Ad Source super property

$mp->register("Ad Source", "Google");

// track an event with a property "Ad Source" = "Google"

$mp->track("button clicked");

NOTE

In the PHP Library, registered Super Properties are only persisted for the life of the Mixpanel class instance. In general this will mean for the life of a single HTTP request.

Super Properties Live in Local Storage

Mixpanel's server-side libraries do not automatically append "super properties" to their events. You are more than welcome to roll your own system to append whatever properties you'd like to events for a given user. The most important thing to note when dealing with appending properties server side is that you must include a value for the (traditionally super) property "distinct_id" in order to use the events in most Mixpanel reports. The distinct_id property ties an event to a specific user.

Managing User Identity

In many cases you'll want to track multiple actions that a user takes over time. To do this, you'll need to provide a distinct id to the library- a unique identifier associated with the source of events (usually a user)

To associate a distinct id with the events that you send, call identify, which associates a user to subsequent tracked events.

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// identify the current request as user 12345

$mp->identify(12345);

// track an event associated to user 12345

$mp->track("Logged In");

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// identify the current request as user 12345

$mp->identify(12345);

// track an event associated to user 12345

$mp->track("Logged In");

NOTE

In the PHP Library, the value passed to identify is only persisted for the life of the Mixpanel instance. In general this will mean for the life of a single HTTP request.

It's important to send the same distinct_id with each event that an individual user triggers. Events recorded with different distinct_ids will be treated in Mixpanel as if they were performed by different users.

There are times when it can be convenient to start referring to a user by a different identifier in your implementation. The most common case is after registration, when a user switches from being an anonymous user (with an anonymous distinct_id) to an authenticated user with an (authenticated id). In this case, you can create an Alias for the user to keep the distinct_id consistent. An alias is a string stored in a Mixpanel lookup table that is associated with an anonymous distinct_id. Once written, aliases are not editable. Any data sent to Mixpanel with an alias as the distinct_id will be remapped and written to disk using the alias's corresponding anonymous distinct_id. This allows you to start identifying a user by an authenticated id without changing the distinct_id that is ultimately written in Mixpanel.

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// create an alias for user 12345 (note that this is done asynchronously). Any subsequent events with a distinct_id equal to "johndoe1" will be remapped to "12345".

$mp->createAlias("12345", "johndoe1");

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// create an alias for user 12345 (note that this is done asynchronously). Any subsequent events with a distinct_id equal to "johndoe1" will be remapped to "12345".

$mp->createAlias("12345", "johndoe1");

Storing User Profiles

In addition to events, you can send user profile updates to Mixpanel. Mixpanel can maintain a profile of each of your users, storing information you know about them. An update is a message that changes the properties of a user profile.

You can use profiles to explore and segment users by who they are, rather than what they did. You can also use profiles to send messages, such as emails, SMS, or push notifications.

Mixpanel determines default geolocation data ($city, $region, mp_country_code) using the IP address on the incoming request. As all server-side calls will likely originate from the same IP (that is, the IP of your server), this can have the unintended effect of setting the location of all of your users to the location of your datacenter. Read about best practices for geolocation with server-side implementations.

Setting Profile Properties

The Mixpanel class has a public property called people that exposes an instance of Producers_MixpanelPeople that you can use to make profile updates.

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// create or update a profile with First Name, Last Name,

// E-Mail Address, Phone Number, and Favorite Color

// without updating geolocation data or $last_seen

$mp->people->set(12345, array(

'$first_name' => "John",

'$last_name' => "Doe",

'$email' => "[email protected]",

'$phone' => "5555555555",

"Favorite Color" => "red"

), $ip = 0, $ignore_time = true);

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// create or update a profile with First Name, Last Name,

// E-Mail Address, Phone Number, and Favorite Color

// without updating geolocation data or $last_seen

$mp->people->set(12345, array(

'$first_name' => "John",

'$last_name' => "Doe",

'$email' => "[email protected]",

'$phone' => "5555555555",

"Favorite Color" => "red"

), $ip = 0, $ignore_time = true);

The call to people->set will set the value of properties on user 12345's profile. If there isn't a profile with distinct_id 12345 in Mixpanel already, a new profile will be created. If user 12345 already has has any of these properties set on their profile, the old value will be overwritten with the new ones.

NOTE

Pick your property names wisely. Once you've sent them to Mixpanel, there is no way to change them. Feel free to use capitalization and spaces in between words.

There are a few limitations:

Your property names should not begin with $ or mp_. These properties are reserved for special properties sent by Mixpanel.

Your property names cannot begin or end with a space as they will automatically be trimmed.

Your property names and values cannot be longer than 255 characters. In practice they should be much shorter than that. Property names get cut off by our user interface at about 20 characters.

Click here to see a list of Mixpanel's reserved user profile properties.

Incrementing Numeric Properties

You can change the current value of numeric properties using people->increment. This is useful when you want to keep a running tally of things, such as games played, emails sent, or points earned.

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// increment user 12345's "login count" by one

$mp->people->increment(12345, "login count", 1);

// Use negative numbers to subtract- reduce

// "credits remaining" by 10

$mp->people->increment(12345, "credits remaining", -10);

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// increment user 12345's "login count" by one

$mp->people->increment(12345, "login count", 1);

// Use negative numbers to subtract- reduce

// "credits remaining" by 10

$mp->people->increment(12345, "credits remaining", -10);

Appending to List Properties

Use people->append to add an item to an existing list-valued property. The values you send with the append will be added to the end of the list for each named property. If the property doesn't exist, it will be created with a one element list as its value.

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// append "Apples" to user 12345's "favorites"

$mp->people->append(12345, "favorites", "Apples");

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// append "Apples" to user 12345's "favorites"

$mp->people->append(12345, "favorites", "Apples");

Other Types of Profile Updates

There are a few other types of profile updates. They're exposed as public methods of Producers_MixpanelPeople.

Tracking Revenue

Mixpanel makes it easy to analyze the revenue you make from individual customers. By associating charges with user profiles, you can compare revenue across different customer segments and calculate things like lifetime value.

You can track a single transaction with the trackCharge method on the Mixpanel->people object. Sending a message created with trackCharge will add transactions to the individual user profile, which will be reflected in the Mixpanel Revenue report.

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// track a purchase or charge of $9.99 for user 12345

// where the transaction happened just now

$mp->people->trackCharge(12345, "9.99");

// track a purchase or charge of $20 for user 12345

// where the transaction happened on June 01, 2013 at 5pm EST

$mp->people->trackCharge(12345, "20.00", strtotime("01 Jun 2013 5:00:00 PM EST"));

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");

// track a purchase or charge of $9.99 for user 12345

// where the transaction happened just now

$mp->people->trackCharge(12345, "9.99");

// track a purchase or charge of $20 for user 12345

// where the transaction happened on June 01, 2013 at 5pm EST

$mp->people->trackCharge(12345, "20.00", strtotime("01 Jun 2013 5:00:00 PM EST"));

Debugging and Logging

You can turn on Mixpanel logging by enabling the "debug" flag in your initialization:

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN", array("debug" => true));

<?php

require "vendor/autoload.php";

$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN", array("debug" => true));

Scaling your Server-Side Tracking

Message Consumers

The PHP library stores all events and profile updates in an in-memory queue, that is flushed automatically when the instance of Mixpanel is destroyed, or when the queue reaches a configurable threshold size (by default, 1000 items). You can also force the instance to send on demand by calling flush.

At flush time, the messages are processed by an implementation of the ConsumerStrategies_AbstractConsumer class that determines how the messages will be written. The default settings use ConsumerStrategies_CurlConsumer, which uses cURL to write the messages over SSL to Mixpanel.

As your application scales, you may want to separate the IO for communicating with Mixpanel out of the processes that observe your events. You can write your events and updates to a file or a distributed queue by writing your own custom consumer.

To create a custom consumer, you'll want to extend ConsumerStrategies_AbstractConsumer and implement the persist method. Then you'll want to register it with the Mixpanel class and specify it for use.

<?php

// Here's a simple consumer that just writes the events to

// send out to the client.

class MyLoggingConsumer extends ConsumerStrategies_AbstractConsumer {

public function persist($batch) {

echo "<pre>";

echo "Would send batch:\n";

echo json_encode($batch) . "\n";

echo "</pre>"

return true;

}

}

$mp = new Mixpanel("MIXPANEL_PROJECT_TOKEN", array(

// Provide the name of your consumer class to the Mixpanel constructor

"consumers" => array("logger" => "MyLoggingConsumer"),

// Now tell the Mixpanel instance to use your class

"consumer" => "logger"

));

// This event will be sent to the client in a <pre> tag

$mp->track("test_event", array("color" => "blue"));

<?php

// Here's a simple consumer that just writes the events to

// send out to the client.

class MyLoggingConsumer extends ConsumerStrategies_AbstractConsumer {

public function persist($batch) {

echo "<pre>";

echo "Would send batch:\n";

echo json_encode($batch) . "\n";

echo "</pre>"

return true;

}

}

$mp = new Mixpanel("MIXPANEL_PROJECT_TOKEN", array(

// Provide the name of your consumer class to the Mixpanel constructor

"consumers" => array("logger" => "MyLoggingConsumer"),

// Now tell the Mixpanel instance to use your class

"consumer" => "logger"

));

// This event will be sent to the client in a <pre> tag

$mp->track("test_event", array("color" => "blue"));

Contents: [

Installing the Library - Android Studio / Gradle

,

Initializing the Library

,

Opting Users Out of Tracking

,

Sending Events

,

Timing Events

,

Super Properties

,

Group Analytics

,

Managing User Identity

,

Storing User Profiles

,

Tracking Revenue

,

Push Notifications Guide

,

In-App Messages

,

A/B Testing

,

A/B Developer Tweaks

,

Automatic Referrer Tracking

,

App Links Tracking

,

Debugging and Logging

][Step 1 - Add the mixpanel-android library as a gradle dependency:, Step 2 - Add permissions to your AndroidManifest.xml:, Flushing Events, Opting Users Out of Tracking by Default, Delete Existing Data, Setting Super Properties Once and Only Once, Super Properties Live in Local Storage, Add Group Keys

, Creating a Group Key, Adding Users to a Group, Creating Group Profiles, Setting Group Profile Properties, set, set once, unset, remove, union, delete, NOTE

, Combining Anonymous and Identifiable User Data, NOTE

, Call Reset at Logout, Setting Profile Properties, NOTE

, Incrementing Numeric Properties, Appending to List Properties, Other Types of Profile Updates, Prerequisites, NOTE

, Creating Your First A/B Test, Notes on Experiment Delivery, Using Tweaks in Your Application, Requirements, NOTE

, Tracking In-bound App Links, Tracking Out-bound App lLnks]

Visit the Dev Docs A better version of this page exists at https://developer.mixpanel.com/docs/android.

Installing the Library - Android Studio / Gradle

Step 1 - Add the mixpanel-android library as a gradle dependency:

We publish builds of our library to the Maven central repository as an .aar file. This file contains all of the classes, resources, and configurations that you'll need to use the library. To install the library inside Android Studio, you can simply declare it as dependency in your build.gradle file.

dependencies {

implementation 'com.mixpanel.android:mixpanel-android:5.+'

}

dependencies {

implementation 'com.mixpanel.android:mixpanel-android:5.+'

}

Once you've updated your build.gradle file, you can force Android Studio to sync with your new configuration by clicking the Sync Project with Gradle Files icon at the top of the window.

This should download the aar dependency at which point you'll have access to the Mixpanel library API calls. If it cannot find the dependency, you should make sure you've specified mavenCentral() as a repository in your build.gradle.

Step 2 - Add permissions to your AndroidManifest.xml:

In order for the library to work you'll need to ensure that you're requesting the following permissions in your AndroidManifest.xml:

<!--

This permission is required to allow the application to send

events and properties to Mixpanel.

-->

<uses-permission

android:name="android.permission.INTERNET" />

<!--

This permission is optional but recommended so we can be smart

about when to send data.

-->

<uses-permission

android:name="android.permission.ACCESS_NETWORK_STATE" />

<!--

This permission is optional but recommended so events will

contain information about bluetooth state

-->

<uses-permission

android:name="android.permission.BLUETOOTH" />

<!--

This permission is required to allow the application to send

events and properties to Mixpanel.

-->

<uses-permission

android:name="android.permission.INTERNET" />

<!--

This permission is optional but recommended so we can be smart

about when to send data.

-->

<uses-permission

android:name="android.permission.ACCESS_NETWORK_STATE" />

<!--

This permission is optional but recommended so events will

contain information about bluetooth state

-->

<uses-permission

android:name="android.permission.BLUETOOTH" />

At this point, you're ready to use the Mixpanel Android library inside Android Studio.

Initializing the Library

Once you've set up your build system or IDE to use the Mixpanel library, you can initialize it in your code by calling MixpanelAPI.getInstance with your application context and your Mixpanel project token. You can find your token by clicking your name in the upper righthand corner of your Mixpanel project and selecting Settings from the dropdown.

public static final String MIXPANEL_TOKEN = "YOUR_TOKEN";

// Initialize the library with your

// Mixpanel project token, MIXPANEL_TOKEN, and a reference

// to your application context.

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

public static final String MIXPANEL_TOKEN = "YOUR_TOKEN";

// Initialize the library with your

// Mixpanel project token, MIXPANEL_TOKEN, and a reference

// to your application context.

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

After installing the library into your Android app, Mixpanel will automatically collect common mobile events. You can enable/ disable automatic collection through your project settings.

Flushing Events

To preserve battery life and customer bandwidth, the Mixpanel library doesn't send the events you record immediately. Instead, it sends batches to the Mixpanel servers periodically while your application is running. This means when your application shuts down, you need to inform the library to send whatever events are still unsent. You can do this by calling MixpanelAPI.flush in the onDestroy method of your main application activity.

@Override

protected void onDestroy() {

mixpanel.flush();

super.onDestroy();

}

@Override

protected void onDestroy() {

mixpanel.flush();

super.onDestroy();

}

When you call flush, the library attempts to send all of it's remaining messages. If you don't call flush, the messages will be sent the next time the application is opened.

Opting Users Out of Tracking

Client-side tracking of individual user data can be stopped or resumed by controlling a user’s opt-out/opt-in state. Opt-out methods and library configuration settings only affect data sent from a single library instance. Data sent from other sources to Mixpanel’s APIs will still be ingested regardless of whether the user is opted out locally.

The opt-out/opt-in state of a user is controlled by an opt-out flag that is stored in the local storage of the user’s device. If the value of the flag is true, then the user is opted-out and will not be tracked. If the opt-out flag is false, then the user is tracked. The flag is not set when the SDK is initialized, so the initial state is neither opted in nor opted out. Without the flag set, the user will be tracked by default.

To opt a user out of tracking locally, use the optOutTracking method. To resume tracking for an individual user, use optInTracking. Call hasOptedOutTracking to check user’s opt-out status locally. By default, an "$opt_in" event is sent every time that a user opts in.

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

// Opt a user out of data collection

mixpanel.optOutTracking();

// Check a user's opt-out status

// Returns true of user is opted out of tracking locally

Boolean hasOptedOutTracking = mixpanel.hasOptedOutTracking();

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

// Opt a user out of data collection

mixpanel.optOutTracking();

// Check a user's opt-out status

// Returns true of user is opted out of tracking locally

Boolean hasOptedOutTracking = mixpanel.hasOptedOutTracking();

Opting Users Out of Tracking by Default

Mixpanel’s tracking libraries will send user data by default. Explicitly setting a default opt-out state of true will opt-out all users by default, preventing data from sending unless a user’s opt-out state is set to false.

// Initializing a default opt-out state of true

// will prevent data from being collected by default

MixpanelAPI mixpanelOptOutDefault =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN, true);

// Initializing a default opt-out state of true

// will prevent data from being collected by default

MixpanelAPI mixpanelOptOutDefault =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN, true);

Delete Existing Data

Opting users out of tracking will stop any future tracking. This does not automatically delete data that has already been collected. Mixpanel's deletion API can be used to delete existing data.

Sending Events

Once you've initialized the library, you can track an event using MixpanelAPI.track with the event name and properties.

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

JSONObject props = new JSONObject();

props.put("Gender", "Female");

props.put("Plan", "Premium");

mixpanel.track("Plan Selected", props);

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

JSONObject props = new JSONObject();

props.put("Gender", "Female");

props.put("Plan", "Premium");

mixpanel.track("Plan Selected", props);

Timing Events

You can track the time it took for an action to occur, such as an image upload or a comment post, using timeEvent. This will mark the "start" of your action, which will be timed until you finish with a track call. The time duration is then recorded in the "Duration" property.

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

// start the timer for the event "Image Upload"

mixpanel.timeEvent("Image Upload");

// stop the timer if the imageUpload() method returns true

if(imageUpload()){

mixpanel.track("Image Upload");

}

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

// start the timer for the event "Image Upload"

mixpanel.timeEvent("Image Upload");

// stop the timer if the imageUpload() method returns true

if(imageUpload()){

mixpanel.track("Image Upload");

}

Super Properties

t's very common to have certain properties that you want to include with each event you send. Generally, these are things you know about the user rather than about a specific event - for example, the user's age, gender, source, or initial referrer.

To make things easier, you can register these properties as super properties. If you tell us just once that these properties are important, we will automatically include them with all events sent. Super properties are saved to device storage, and will persist across invocations of your app. Mixpanel already stores some information as super properties by default; see a full list of Mixpanel default properties here.

To set super properties, call MixpanelAPI.registerSuperProperties.

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

// Send a "User Type: Paid" property will be sent

// with all future track calls.

JSONObject props = new JSONObject();

props.put("User Type", "Paid");

mixpanel.registerSuperProperties(props);

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

// Send a "User Type: Paid" property will be sent

// with all future track calls.

JSONObject props = new JSONObject();

props.put("User Type", "Paid");

mixpanel.registerSuperProperties(props);

The next time you track an event, the super properties you just set will be included as properties.

Super properties are saved to device storage, and will persist between executions of your app.

Setting Super Properties Once and Only Once

If you want to store a super property only once (for example, a date of first login), you can use MixpanelAPI.registerSuperPropertiesOnce. registerSuperPropertiesOnce behaves like registerSuperProperties and has the same interface, but it doesn't override super properties you've already saved.

This means it's safe to call registerSuperPropertiesOnce with the same property multiple times, and it will only set properties if the super property doesn't exist.

Super Properties Live in Local Storage

Our mobile libraries store your super properties in local storage. They will persist so long as the app is installed (between launches and updates). Uninstalling the app will remove that customers super properties.

Group Analytics

Add Group Keys

To start tracking groups data, add group keys in project settings. If you don't see group keys in your Project Settings, reach out to the Mixpanel Sales Team to purchase Group Analytics.

Mixpanel Group Analytics allows behavioral data analysis by selected groups, as opposed to individual users.

Grouping by identifiers other than the distinct_id will allow analysis at a company or group level when using Mixpanel analytics. Read this article to learn more about Group Analytics.

A group is identified by the group_key and group_id.

group_key is the property that connects event data for Group Analytics.

group_id is the identifier for a specific group.

If the property “company” is chosen for Group Analytics, “company” is the group_key, and “Mixpanel”, “Company A”, and “13254” are all potential group_id values.

A user can belong to multiple groups. All updates to a group operate on the group_key and group_id.

Creating a Group Key

Administer group keys through your Project Settings. Group keys are event properties. All events need to have a defined group key on them in order to be attributed to a group. Group keys are project specific, and the group key should be set up before group data is sent. Note that Mixpanel does not backfill historical data before the group key was implemented.

To administer group keys, navigate to your Project Settings. Click +Add Group Key under the GROUP KEYS section.

Enter an event property to attribute the group key to. You can also enter a display name for the group key. Click Save.

Adding Users to a Group

Adding users to groups causes the group_key and group_id to send as a property key and value for all events triggered by that user on the device. You can add multiple values for a single user to the group_key list property.

Similar to a distinct_id, the group_key allows Mixpanel to group events by an identifier for analysis. A group_key, however, is a group level identifier and not a user level identifier like the distinct_id.

You can add users to groups by calling the setGroup() method.

mMixpanel.setGroup("group key", "group id");

mMixpanel.setGroup("group key", "group id");

You can call addGroup() to add any additional groups to an existing list.

mMixpanel.addGroup("group key", "group id");

mMixpanel.addGroup("group key", "group id");

You can call removeGroup() to remove any additional groups from an existing list.

mMixpanel.removeGroup("group key", "group id");

mMixpanel.removeGroup("group key", "group id");

Creating Group Profiles

It is possible to create a Group profile that is similar to a user profile. You must call getGroup().set() to build a group profile. It is important to the group_key, group_id, and one property so that the profile is not empty.

mMixpanel.getGroup("group key", "group id").set("SET NAME", "SET VALUE");

mMixpanel.getGroup("group key", "group id").set("SET NAME", "SET VALUE");

Setting Group Profile Properties

You can add details to Groups by adding properties to them.

In order to update Group profile properties, you must specify the group that needs to be updated by calling getGroup().set().

mMixpanel.getGroup("group key", "group id").set("SET NAME", "SET VALUE");

mMixpanel.getGroup("group key", "group id").setMap((new HashMap<>()).put("SET MAP INT", 1));

mMixpanel.getGroup("group key", "group id").set("SET NAME", "SET VALUE");

mMixpanel.getGroup("group key", "group id").setMap((new HashMap<>()).put("SET MAP INT", 1));

The getGroup() method can be chained with other commands that edit properties specific to the group.

You can set the property $name to populate the name field at the top of the group profile.

These operations are similar to the corresponding operations for user profile property updates.

set

mixpanel.getGroup().set() updates or adds a property to a group.

mMixpanel.getGroup("group key", "group id").set("SET NAME", "SET VALUE");

mMixpanel.getGroup("group key", "group id").setMap((new HashMap<>()).put("SET MAP INT", 1));

mMixpanel.getGroup("group key", "group id").set("SET NAME", "SET VALUE");

mMixpanel.getGroup("group key", "group id").setMap((new HashMap<>()).put("SET MAP INT", 1));

set once

mixpanel.getGroup().set_once() adds a property value to a group only if it has not been set before.

mMixpanel.getGroup("group key", "group id").setOnce("SET ONCE NAME", "SET ONCE VALUE");

mMixpanel.getGroup("group key", "group id").setOnceMap((new HashMap<>()).put("SET ONCE MAP STR", "SET ONCE MAP VALUE"));

mMixpanel.getGroup("group key", "group id").setOnce("SET ONCE NAME", "SET ONCE VALUE");

mMixpanel.getGroup("group key", "group id").setOnceMap((new HashMap<>()).put("SET ONCE MAP STR", "SET ONCE MAP VALUE"));

unset

mixpanel.getGroup().unset() unsets a specific property in the group.

mMixpanel.getGroup("group key", "group id").unset("UNSET NAME");

mMixpanel.getGroup("group key", "group id").unset("UNSET NAME");

remove

mixpanel.getGroup().remove() removes a specific value in a list property.

mMixpanel.getGroup("group key", "group id").remove("property name", "value to remove");

mMixpanel.getGroup("group key", "group id").remove("property name", "value to remove");

union

mixpanel.getGroup().union() adds the specified values to a list property and ensures that those values only appear once.

mMixpanel.getGroup("group key", "group id").union("UNION NAME", new JSONArray("[100]"));

mMixpanel.getGroup("group key", "group id").union("UNION NAME", new JSONArray("[100]"));

delete

mixpanel.getGroup().deleteGroup() deletes a group.

mMixpanel.getGroup("group key", "group id").deleteGroup();

mMixpanel.getGroup("group key", "group id").deleteGroup();

Managing User Identity

The Mixpanel library will assign a default unique identifier (we call it "distinct_id") to each install of your application. This distinct_id is saved in persistent device storage, and will be the same across executions of your app.

If you choose, you can assign your own user IDs. This is particularly useful if a user is accessing your app on multiple platforms (both web and mobile, for example). To assign your own distinct_ids, you can use MixpanelAPI.identify and MixpanelAPI.getPeople().identify. We strongly recommend using the same distinct id for both calls.

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

// Ensure all future events sent from

// the device will have the distinct_id 13793

mixpanel.identify("13793");

// Ensure all future user profile properties sent from

// the device will have the distinct_id 13793

mixpanel.getPeople().identify("13793");

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

// Ensure all future events sent from

// the device will have the distinct_id 13793

mixpanel.identify("13793");

// Ensure all future user profile properties sent from

// the device will have the distinct_id 13793

mixpanel.getPeople().identify("13793");

In general, if you use identify, you should call it as soon as the user logs in to your application. This will track all of their authenticated application usage to the correct user ID.

NOTE

Calling identify with a new ID will change the distinctID stored on the device. Updates to user profiles are queued on the device until getPeople().identify is called.

Combining Anonymous and Identifiable User Data

It's important to send the same distinct_id with each event that an individual user triggers. Events recorded with different distinct_ids will be treated in Mixpanel as if they were performed by different users.

There are times when it can be convenient to start referring to a user by a different identifier in your implementation. The most common case is after registration, when a user switches from being an anonymous user (with an anonymous distinct_id) to an authenticated user with an (authenticated id). In this case, you can create an alias for the user to keep the distinct_id consistent. An alias is a string stored in a Mixpanel lookup table that is associated with an anonymous distinct_id. Once written, aliases are not editable. Any data sent to Mixpanel with an alias as the distinct_id will be remapped and written to disk using the alias's corresponding anonymous distinct_id. This allows you to start identifying a user by an authenticated id without changing the distinct_id that is ultimately written in Mixpanel.

// This makes the current ID (by default an auto-generated GUID)

// and '13793' interchangeable distinct ids (but not retroactively).

mixpanel.alias("13793", null);

// To create a user profile, you must call getPeople().identify

mixpanel.getPeople().identify(mixpanel.getDistinctId());

// This makes the current ID (by default an auto-generated GUID)

// and '13793' interchangeable distinct ids (but not retroactively).

mixpanel.alias("13793", null);

// To create a user profile, you must call getPeople().identify

mixpanel.getPeople().identify(mixpanel.getDistinctId());

The recommended usage pattern is to call both alias and identify when the user signs up (as shown in the example above), and only identify (with the aliased user ID) on future log ins. This will keep your signup funnels working correctly.

NOTE

If you use alias we recommend only calling it once during the lifetime of the user.

Call Reset at Logout

Reset generates a new random distinct_id and clears super properties. Call reset to clear data attributed to a user when that user logs out. This allows you to handle multiple users on a single device. For more information about maintaining user identity, see the Identity Management: Best Practices article.

Storing User Profiles

In addition to events, you can store user profiles in Mixpanel's Behavioral Analytics product. Profiles are persistent sets of properties that describe a user - things like name, email address, and signup date. You can use profiles to explore and segment users by who they are, rather than what they did. You can also use profiles to send messages, such as emails, SMS, or push notifications.

Before you send profile updates, you must call getPeople().identify. The library uses a separate ID for User records, and you must set this value to send updates.

Setting Profile Properties

You can set properties on a user profile with MixpanelAPI.getPeople().set.

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

// identify must be called before

// user profile properties can be set

mixpanel.getPeople().identify("13793");

// Sets user 13793's "Plan" attribute to "Premium"

mixpanel.getPeople().set("Plan", "Premium");

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

// identify must be called before

// user profile properties can be set

mixpanel.getPeople().identify("13793");

// Sets user 13793's "Plan" attribute to "Premium"

mixpanel.getPeople().set("Plan", "Premium");

This will set a "Plan" property, with a value "Premium", on user 13793's profile. If there isn't a profile with distinct_id 13793 in Mixpanel already, a new profile will be created. If user 13793 already has a property named "Plan" in their profile, the old value will be overwritten with "Premium".

NOTE

Pick your property names wisely. Once you've sent them to Mixpanel, there is no way to change them. Feel free to use capitalization and spaces in between words.

There are a few limitations:

Your property names should not begin with $ or mp_. These properties are reserved for special properties sent by Mixpanel.

Your property names cannot begin or end with a space as they will automatically be trimmed.

Your property names and values cannot be longer than 255 characters. In practice they should be much shorter than that. Property names get cut off by our user interface at about 20 characters.

Click here to see a list of Mixpanel's reserved user profile properties.

Incrementing Numeric Properties

You can use MixpanelAPI.getPeople().increment to change the current value of numeric properties. This is useful when you want to keep a running tally of things, such as games played, messages sent, or points earned.

// Add 500 to the current value of

// "points earned" in Mixpanel

mixpanel.getPeople().increment("points earned", 500);

// Pass a Map to increment multiple properties

Map<String, Integer> properties =

new HashMap<String, Integer>();

properties.put("dollars spent", 17);

// Subtract by passing a negative value

properties.put("credits remaining", -34);

mixpanel.getPeople().increment(properties);

// Add 500 to the current value of

// "points earned" in Mixpanel

mixpanel.getPeople().increment("points earned", 500);

// Pass a Map to increment multiple properties

Map<String, Integer> properties =

new HashMap<String, Integer>();

properties.put("dollars spent", 17);

// Subtract by passing a negative value

properties.put("credits remaining", -34);

mixpanel.getPeople().increment(properties);

Appending to List Properties

getPeople.append() creates an update that adds an item to a list-valued property. The value you send with the append is added to the end of the list. If the property doesn't exist, it will be created with one element list as its value.

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

//Identify the user profile that is going to be updated

mixpanel.getPeople().identify("13793");

//Add the color green to the list property "Favorite Colors"

//A new list property is created if it doesn't already exist

mixpanel.getPeople().append("Favorite Colors", "Green")

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

//Identify the user profile that is going to be updated

mixpanel.getPeople().identify("13793");

//Add the color green to the list property "Favorite Colors"

//A new list property is created if it doesn't already exist

mixpanel.getPeople().append("Favorite Colors", "Green")

Other Types of Profile Updates

There are a few other types of profile updates. They can be accessed through the MixpanelPeople class, which is accessible via MixpanelAPI.getPeople().

Tracking Revenue

Mixpanel makes it easy to analyze the revenue you make from individual customers. By associating charges with User Analytics profiles, you can compare revenue across different customer segments and calculate customer lifetime value.

You can track a single transaction with MixpanelAPI.getPeople().trackCharge. This call will add transactions to the individual user profile, which will also be reflected in the Mixpanel Revenue report.

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

// Make getPeople() identify has been

// called before making revenue updates

mixpanel.getPeople().identify("13793");

// Tracks $100 in revenue for user 13793

mixpanel.getPeople().trackCharge(100, null);

// Refund this user 50 dollars

mixpanel.getPeople().trackCharge(-50, null);

// Tracks $25 in revenue for user 13793

// on the 2nd of january

JSONObject properties = new JSONObject()

properties.put("$time", "2012-01-02T00:00:00");

mixpanel.getPeople().trackCharge(25, properties);

MixpanelAPI mixpanel =

MixpanelAPI.getInstance(context, MIXPANEL_TOKEN);

// Make getPeople() identify has been

// called before making revenue updates

mixpanel.getPeople().identify("13793");

// Tracks $100 in revenue for user 13793

mixpanel.getPeople().trackCharge(100, null);

// Refund this user 50 dollars

mixpanel.getPeople().trackCharge(-50, null);

// Tracks $25 in revenue for user 13793

// on the 2nd of january

JSONObject properties = new JSONObject()

properties.put("$time", "2012-01-02T00:00:00");

mixpanel.getPeople().trackCharge(25, properties);

Push Notifications Guide

Mixpanel provides a quick-start guide for setting up push for your Android app that covers setting up your Google API project, locating your project number, uploading your Google API Project key to Mixpanel, and configuring your application to register for and receive push notifications.

In-App Messages

There is a quick start guide for Android in app messages to help you get integrated.

Make sure that you have already:

Included the latest version of the Mixpanel Android library in your app

Made sure you are identifying your users in the app.

Created an in-app message on the Messages tab of the Mixpanel website.

A/B Testing

Prerequisites

To use Mixpanel Android A/B testing, your app needs to be using version 4.6.0 or greater of the Mixpanel SDK. Make sure you are initializing the MixpanelAPI in your main activity using the project token that you wish to run tests in. See the quick start guide for installation steps.

NOTE

Planning to run an experiment on the initial view of your app ? It can take several seconds for experiments to be applied on first app open; as a result, we recommend against putting UX changes or developer Tweaks on the first view of your app. If you wish to A/B test on the initial app view you will need to take delivery latency into account. We recommend employing the addOnMixpanelUpdatesReceivedListener (to know when test data is available) and joinExperimentIfAvailable() method (to apply the variant data to the view).

Creating Your First A/B Test

Mixpanel A/B testing allows you to make changes to your app and deploy it to your users without a new release to the Google Play store. You can modify the look and feel of your app, change the copy, and even change the values of variables (using developer tweaks ). Then you can see which version performs better without making any changes to your tracking code. Once you've installed the Mixpanel Android SDK, running your first A/B test is simple.

Open the A/B testing tab and create a new experiment

Open your app and connect to Mixpanel using the flip gesture. If production devices prevent your test device from connecting, follow these steps.

3 .Use the visual editor to make the changes you want

Save and deploy your changes

Now the next time a user opens your app, they will receive the updated version. You can also use Mixpanel A/B testing to change the values of variables by taking advantage of developer tweaks.

Notes on Experiment Delivery

Mixpanel checks for any new experiments asynchronously each time your application is opened or resumed. After the response is received, experiment changes and tweaks are applied or removed where appropriate. To handle network availability, each experiment is cached on the device so they can be re-applied when the API call cannot be successfully made.

If you'd like more control over when this check for new experiments occurs, you can use the addOnMixpanelUpdatesReceivedListener listener and the joinExperimentIfAvailable method to download and apply experiments manually.

The $experiment_started event is fired when a given experiment (both changes and/or tweaks) is first started on a device. The event will contain an $experiment_id property with the given experiment id which we encourage use within funnels, and our other reports.

A/B Developer Tweaks

For more complex changes that you want to A/B test, you can send arbitrary data to your apps as part of A/B testing, through a mechanism called Tweaks. Tweaks allow you to control variables in your app directly from Mixpanel. For example, you can alter the difficulty of a game, choose different paths through the app, or change text. The possibilities are endless.

Using Tweaks in Your Application

You can declare a tweak using MixpanelAPI.booleanTweak, MixpanelAPI.stringTweak, MixpanelAPI.longTweak, MixpanelAPI.doubleTweak, and other static methods that declare a tweak name and set a default value. To add A/B testable logic to your app, you might do something like this:

package com.mixpanel.mygame;

import android.app.Activity;

import android.os.Bundle;

import com.mixpanel.android.mpmetrics.MixpanelAPI;

import com.mixpanel.android.mpmetrics.Tweak;

public class GameActivity extends Activity {

private static Tweak<Double> gameSpeed = MixpanelAPI.doubleTweak("Game speed", 1.0);

private static Tweak<Boolean> showAds = MixpanelAPI.booleanTweak("show ads",false);

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

runGame(gameSpeed.get()); // pass in game speed for this A/B test, defaulted //to 1.0

if (showAds.get()) { //do we want to show ads in this A/B test? default to //false

showAdbar();

}

public void runGame(Double speed) {

// ... logic to start a new game

}

public void showAdBar() {

// ... some logic that shows ads

}

}

package com.mixpanel.mygame;

import android.app.Activity;

import android.os.Bundle;

import com.mixpanel.android.mpmetrics.MixpanelAPI;

import com.mixpanel.android.mpmetrics.Tweak;

public class GameActivity extends Activity {

private static Tweak<Double> gameSpeed = MixpanelAPI.doubleTweak("Game speed", 1.0);

private static Tweak<Boolean> showAds = MixpanelAPI.booleanTweak("show ads",false);

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

runGame(gameSpeed.get()); // pass in game speed for this A/B test, defaulted //to 1.0

if (showAds.get()) { //do we want to show ads in this A/B test? default to //false

showAdbar();

}

public void runGame(Double speed) {

// ... logic to start a new game

}

public void showAdBar() {

// ... some logic that shows ads

}

}

When you create an A/B test, you will be able to change the value of any Tweak you create in your app!

Note that the class containing the Tweaks must be loaded for the Tweaks to appear in the A/B test builder.

Automatic Referrer Tracking

The Mixpanel library can automatically set super properties associated with how your users found your app in the Google Play Store. To enable this feature, just add the following tag to the <application> tag in your AndroidManifest.xml file:

<receiver

android:name="com.mixpanel.android.mpmetrics.InstallReferrerReceiver"

android:exported="true">

<intent-filter>

<action android:name="com.android.vending.INSTALL_REFERRER" />

</intent-filter>

</receiver>

<receiver

android:name="com.mixpanel.android.mpmetrics.InstallReferrerReceiver"

android:exported="true">

<intent-filter>

<action android:name="com.android.vending.INSTALL_REFERRER" />

</intent-filter>

</receiver>

Once you've updated your AndroidManifest.xml file, you will automatically send referrer and utm_campaign information along with every event you send to Mixpanel.

The Google Play Store will only send the INSTALL_REFERRER message to a single receiver, so if you have multiple receivers you'd like to use to process referrer information, you should take a look at this simple workaround for using multiple INSTALL_REFERRER receivers.

App Links Tracking

The Mixpanel library has built in support for tracking in-bound and out-bound App Links. App Links is a specification to help standardize deep-linking between apps as well as give you additional information about how users are getting to and from your own mobile app.

Requirements

In order for Mixpanel to track App Links, your app must statisfy the following dependencies:

Bolts Framework >= v1.1.2

Android Support Library v4.

NOTE

If your application does not meet these requirements, the Mixpanel library will log debug messages about App Links tracking not being enabled. This is NOT an error and can be safely ignored.

Tracking In-bound App Links

If a user comes to your app via an App Link, Mixpanel will automatically track a "$al_nav_in" event with meta information about where they came from.

Tracking Out-bound App lLnks

If you're linking to other applications using the Bolts framework, Mixpanel will track a $al_nav_out event with additional meta information about where the user is being linked to.

bolts.AppLinkNavigation.navigateInBackground(this,

"http://anotherapp.com/app/link");

bolts.AppLinkNavigation.navigateInBackground(this,

"http://anotherapp.com/app/link");

Debugging and Logging

Enabling Mixpanel debugging and logging allows you to see the debug output from the Mixpanel Android library. This may be useful in determining when track calls go out or in-app messages are fetched. To enable Mixpanel debugging and logging, you will want to add the following permission within your AndroidManifest.xml inside the <application> tag:

...

<application>

<meta-data

android:name="com.mixpanel.android.MPConfig.EnableDebugLogging"

android:value="true" />

...

</application>

...

...

<application>

<meta-data

android:name="com.mixpanel.android.MPConfig.EnableDebugLogging"

android:value="true" />

...

</application>

...

Contents: [

Enabling Google Cloud Messaging in your Firebase Console

,

Uploading Your Google API Key to Mixpanel

,

Setting up Your AndroidManifest.xml

,

Importing Device Tokens

,

Send a Push Notification

,

Learning More

][Adding Firebase to your Android Application, Configuring Cloud Messaging in Firebase]

Visit the Dev Docs A better version of this page exists at https://developer.mixpanel.com/docs/android-push-notifications.

This guide will show you how to configure an Android app to send and receive push notifications. You should first read the Android API reference.

In order to send Push Notifications, you must store Mixpanel User Profiles and successfully be distinguishing users using the distinct_id.

You should be comfortable getting access to the MixpanelAPI object using your Mixpanel API key and calling MixpanelAPI.getPeople().identify with a distinct_id to identify your users before sending push notifications.

Enabling Google Cloud Messaging in your Firebase Console

To use Mixpanel push notifications, you must have a Firebase project in your Firebase Console. If you do not already have one, you must create a new Firebase project.

Instructions on adding a new Firebase project can be found here.

Adding Firebase to your Android Application

Once you have created a new project, proceed to the project Overview page, and select the icon to add Firebase to your Android app.

When prompted, enter your application’s Package Name. This can be found in your AndroidManifest.xml file.

<!--The package name is the string equal to "package" below-->

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="mixpanel.example.com.sampleapp">

...

<!--The package name is the string equal to "package" below-->

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="mixpanel.example.com.sampleapp">

...

Select ADD APP after entering the name.

Firebase will then generate a google-services.json file that you must add to your application’s “app” directory.

Next, add the Google Play Services dependencies to your application's build.gradle files.

There is one build.gradle file at the "app" level and one at the "project" level. Add the dependencies to both.

Configuring Cloud Messaging in Firebase

After you’ve added your app to Firebase, you must configure the "Cloud Messaging" settings. Select the app options gear icon from the Firebase Console.

Select the Cloud Messaging tab in your Settings. Here, you can find your API Key to upload to Mixpanel along with the Sender ID (you’ll need this later to generate tokens).

Uploading Your Google API Key to Mixpanel

In order for Mixpanel to send Firebase Cloud Messaging notifications on your behalf, you will need to enter the Google API key generated from the last step into Mixpanel. To upload it, log in to your Mixpanel project, click the settings gear in the upper righthand corner of your Mixpanel project, and select the Mixpanel Project from the "Project settings" from the dropdown.

Click Messages from the project settings overview.

Enter "Android FCM API Server Key" line, and paste in your Google API key into the text field that appears. Click the Save button to confirm.

Setting up Your AndroidManifest.xml

You will need to edit your Android application's AndroidManifest.xml to properly declare the FCM receiver.

You will need to include the following block in your AndroidManifest.xml file:

<application>

...

<service

android:name="com.mixpanel.android.mpmetrics.MixpanelFCMMessagingService"

android:enabled="true"

android:exported="false">

<intent-filter>

<action android:name="com.google.firebase.MESSAGING_EVENT"/>

</intent-filter>

</service>

...

</application>

<application>

...

<service

android:name="com.mixpanel.android.mpmetrics.MixpanelFCMMessagingService"

android:enabled="true"

android:exported="false">

<intent-filter>

<action android:name="com.google.firebase.MESSAGING_EVENT"/>

</intent-filter>

</service>

...

</application>

Importing Device Tokens

If you already have your users' device tokens, you can import into Mixpanel by making API requests to the /engage endpoint and setting the special property $android_devices to a list of the user's Android device tokens in hex.

Your request should be formatted as a JSON dictionary, with $distinct_id and $token set as usual. $ip should be set to zero as to not update the users location incorrectly. $union should be set to a dictionary which has its $android_devices key pointing to an array of the users' device tokens in hex. A $union record operates on list properties and results in a list that contains only unique items (i.e., no duplicates). We use $union here, as opposed to $append so that the user's $android_devices list only contains one copy of each device ID.

Example:

{

"$distinct_id": "123456",

"$token": "36ada5b10da39a1347559321baf13063",

"$ignore_time": true,

"$ip": "0",

"$union": {

"$android_devices": ["2ffca4ad6599adc9b5202d15a5286d33c19547d472cd09de44219cda5ac30207"]

}

}

{

"$distinct_id": "123456",

"$token": "36ada5b10da39a1347559321baf13063",

"$ignore_time": true,

"$ip": "0",

"$union": {

"$android_devices": ["2ffca4ad6599adc9b5202d15a5286d33c19547d472cd09de44219cda5ac30207"]

}

}

After base64 encoding, the above would be sent as this request:

http://api.mixpanel.com/engage/?data=ew0KICAgICIkZGlzdGluY3RfaWQi

OiAiMTIzNDU2IiwNCiAgICAiJHRva2VuIjogIjM2YWRhNWIxMGRhMzlhMTM0NzU1O

TMyMWJhZjEzMDYzIiwNCiAgICAiJGlnbm9yZV90aW1lIjogdHJ1ZSwNCiAgICAiJH

VuaW9uIjogew0KICAgICAgICAiJGlvc19kZXZpY2VzIjogWyIyZmZjYTRhZDY1OTl

hZGM5YjUyMDJkMTVhNTI4NmQzM2MxOTU0N2Q0NzJjZDA5ZGU0NDIxOWNkYTVhYzMw

MjA3Il0NCiAgICB9DQp9

Send a Push Notification

Once you have set up AndroidManifest.xml file you're ready to send a notification.

Install and run your application on an Android device (not the emulator, it can't receive messages). Make sure to run the app until the calls to MixpanelAPI.getPeople.identify has been run. For apps built according to our recommendations, these calls are in the onCreate method of your main application activity, so it is enough to simply open the app.

Press the back button to shut down your app. You should already be calling MixpanelAPI.flush() in the onDestroy method of your main application activity, so closing it should send all waiting messages to Mixpanel.

Now log in to your Mixpanel project and select Explore from the left-hand navigation. There should be a user in the list with an "Android Devices" property. Select the user and click Push Notification.

Compose your message, schedule it to send immediately, and click Send this message.

The message should show up on your device.

Learning More

Mixpanel has a short sample Android application on github that includes support for push notifications and demonstrates some of our recommended practices.

We also recommend you take a look at the complete Mixpanel Android API reference, which provides detailed information for all objects and methods available in the Mixpanel library.