For more details and examples refer to our documentation on User Profiles.

Special Types of Properties

Global / Super Properties

These are event properties that you track with almost every (typically >80%) distinct event that you send. Unlike regular event properties, which only provide specific information to the event its associated to, global / super properties provide an overarching context on information about the user or their environment that you plan to analyze across different events. The value of a global / super property typical persists for a prolonged period and changes only due to certain user action or product functionality

Examples:

Mixpanel’s client-side SDKs provide a method that allows you to register / save the property in a cookie or local storage and auto-appends it in subsequent event tracking calls.

For more details and examples refer to our documentation on Super Properties.

Default Mixpanel Properties

These are event or user properties that Mixpanel auto-populate with a value if available, either through using our client-side SDKs or through information received when data is being ingested into our servers. These properties are typically useful when you are interested in general locations (Country, Region, City), device level information (OS, Browser, Model, App Version), or Marketing Attribution Parameters (UTM tags, Google / Facebook Click ID) but you do not wish to instrument code to manually track them.

Refer to the list of Default Properties and Tracking UTM Parameters for more information.

Reserved Mixpanel Properties

Mixpanel reserves certain property names for special use cases and system processing. Unlike default Mixpanel properties, which are auto-populated with a value, reserved properties may or may not be auto-populated. You would need to ensure that these properties are populated for the specific Mixpanel functions to work.

Examples:

Refer to the list of Reserved Event Properties and Reserved User Properties in our documentation for their usage.

Note: Both default and reserved Mixpanel properties are typically prefixed with mp_ or $ sign. It is a best practice to avoid naming your own properties with such prefixes to avoid confusion.

Property Data Types

Mixpanel supports five data types for properties: String, Numeric, Boolean, Date and List. You should choose the most suitable data type for your properties, since each type has a specific set of operations that enables richer analysis (eg numeric data types allows for aggregated).

A property’s default data type can be typecast to another data type in Mixpanel reports. However, it’s always an important best practice that you keep a property’s data type consistent during implementation to avoid any confusion.

Mixpanel also supports object and list of objects data types for specific use cases like in e-commerce. It is highly encourage that you use the five primary data types as they are fully supported in the Mixpanel UI.

For more details and examples refer to our documentation on Supported Dta Types.

Group Level Behaviors and Demographics

Note: read this section only if you have Group Analytics add-on.

Mixpanel’s core behavioral data analysis is at the individual user level; there are however, use cases where behavioral data needs to be analyzed at a customized group level (eg company, subscription, account). An add-on Group Analytics package available to customers on Growth and Enterprise plans enables this functionality.

image


Keep in mind that not every business necessarily has use cases that may require group level analysis; refer to our documentation on Group Analytics for more information.

More Resources

For more information about Mixpanel’s Data Model:

Creating a Tracking Plan

Now that you have an understanding of Mixpanel’s Data Model, let’s walk you through the steps and best practices on building your own Tracking Plan to define the events, profiles, and properties to help you track and measure your metrics and KPIs.


Link to User Journey Figma shown in video.

Tracking Plan Methodology

  1. Prioritize on the key user journeys that are pertinent to the metrics and KPIs you want to measure.

    For example, a sign up journey will be important when measuring metrics related to newly acquired user (part of Reach). If you used the RAE Framework, make sure you cover the journeys that will help you track and measure your Reach, Activation, and Engagement.


  1. Map the key actions within these journeys into events and capture event properties to provide additional information about the action. As you define your events, think about whether certain event properties should be global / super properties and user properties.

    If you have screenflows in tools like Figjam or Miro, use them to visualize the steps and actions in a user’s journey to define the events and properties. Here is an example of a User Journey in Figma.

    As you determine what user actions to track, you’ll want to strike the right balance to make sure events are not too broad nor too specific.

    image

Where events are too broad, you’d end up having to create filters for every single disparate action you want to measure. Conversely, where events are too narrow, you need to do a lot of work every time to compare the actions against one another.

In general, we advise customers to group together the same actions that users take across your site / platform, and group them to the level of the most commonly asked questions.

Consider the event Start Signup. Top questions we might want to answer with this:

Here’s an example of an implementation we don’t recommend.

bestpractices2

Here, the question you’d want to answer most is: Which signup platform drives the most sign ups? If our events are too narrow, e.g. homepage/start_signup/apple, we’d have to manually add every single event where the signup occurs in order to do a comparison. It’s much easier to capture it as the event Start Signup and use event properties to describe the different originating pages / screens and signup platforms:

bestpractices3

To get all signup starts via the ideal state structure, the user only needs to query the single signup event and apply the flow and platform breakdowns. Once that’s complete, the user can easily see that the homepage flow drives the most traffic with Apple out-performing other platforms across the board.

It is important to adhere to best practices when managing personal information (PI) that you might potentially capture in the properties you define. Refer to our Privacy documentation for details on how Mixpanel respects and protects people’s fundamental online privacy and data rights.

Having specific questions (eg hypothesis, influencing factors, current / target numbers) around the metrics you’re measuring also helps you decide on the events and properties to include. Think of the answers you want to arrived at, and how an action (event), an information of an action (event properties), or a recent state (user property) can help lead you to that answer.


  1. As you map your events and properties, it’s also important to ensure that you have factored identifying users in your product (eg website, app, devices).

    For instance, when a user goes from being anonymous, to completing the sign-up or registration process or simply logging in with a valid user account, you would want to properly identify the user with their user ID as the Distinct ID. This would ensure that events triggered across devices, while the user is anonymous, are tied to their events when they are logged in.

    If you are not specifically tracking a sign-up journey or login event, make sure you work with your developers to have them understand how identity management works in Mixpanel.


  1. Define and document your naming standards, approaches to data types and values in your properties, and how you should deal with nullable or not-applicable values; this will help ensure data quality and data trust over time.

    Here are guidelines to help you think through:


  1. Document your events and properties in a tracking plan, access and make a copy of the blank Tracking Plan template here. Keep your tracking plan as a living and shared document that is continuously updated with any implementation or product changes.

Examples of Tracking Plans by Verticals

Mixpanel provides the following templates for vertical-specific tracking plans:

FrameworkSend Your Data

Was this page useful?