Best Practices -Updated-

Our hope here is to provide a more up to date outline of some of the best practices for quickly getting up and running with mixpanel.

The best way to get started

We advise you begin by instrumenting only a small handful of key metrics. We think you'll be amazed how much value you can get out of even just 5 events. By starting your implementation small, you can quickly separate signal from noise, and begin from day one with a manageable reporting environment that you can share with your co-workers. You'll also be able to start making decisions based on your data faster, allowing the tool to demonstrate its value before additional development time and effort are spent on a more elaborate implementation. Furthermore, a small implementation is also easier to fix if, for instance, after chatting on the phone with a Solutions Architect you decide you'd like to adopt a new system of organizing or naming your events and properties.

One easy way to start small is to envision a single funnel, measuring one of the most important processes on your site or in your app (sign-up, or purchase funnels are good choices). Try choosing the steps of that funnel as your first few events.

Make good use of properties

Properties are the place to articulate all the details associated with an event. Properties fall into two camps: event specific (like the revenue associated with a purchase event) and user specific (like demographic information about the user). The user specific data we call "super properties." For example, you might want to send the gender, age, or traffic source of a particular user along with their events. All the user specific data is stored in a cookie (on the web) or in a local object (on native mobile) and appended onto all subsequent events for that user. A rich set of event and user specific properties will allow added agility in reporting, since mixpanel lets you drill down and inspect the intersections of many different properties across all reporting. It's important to keep in mind that properties are entirely defined by you. Do your best to avoid storing details in event names that could be stored in properties. For example, don't do mixpanel.track("Facebook Share"). Do something like this: mixpanel.track("Share", {"Network": "Facebook"}). More on that here.

Employing this strategy makes Mixpanel's UI and reporting significantly more powerful and easier to understand.

Clear event and property naming

We advise always using clear, human readable event and property names. This makes your reports much easier for everyone on your team to understand. There's no reason you can't use spaces as opposed to underscores if you'd like. Naming things nicely makes reporting more navigable for everyone on your team. For example, don't use us a property name "c_id" for the id associated with a video channel if you don't have to. Why not send us a property called "Channel" and use a plain-text representation of the channel name as opposed to a raw numeric id?

As you continue to expand and improve you mixpanel implementation, keep track of the choices you've made about what to track with an implementation specification. You can can find a sample document to get started with here.

Keep your development data separate from your production data

A common question is "how do we delete some old development data we sent while we were instrumenting?" The answer, unfortunately here, is that you cannot. We advise all customers to create at least two projects. If our project was called "Mixpanel" then we would call one project "Mixpanel - Dev." and the other "Mixpanel - Prod." Use logic in your code to swap out the two project tokens for when you're developing and pushing to production. It costs you nothing extra to have multiple projects as we price based only on the amount of data you send us.

How do I track distinct users and what is this "distinct_id" thing?

One of the most important properties in mixpanel is distinct_id. Distinct_id is a property that is sent with every mixpanel event, and it is what we use to determine uniqueness across all reports. In JS or in the iOS/Android SDKs you can let mixpanel handle distinct_id for you, but you can also choose to control it yourself. You can set distinct_id using the identify method. You can grab distinct_id using mixpanel.get_property("distinct_id") in JS (or the equivalent in our mobile SDKs).

A common question is what to do when an anonymous piece of traffic traverses the signup funnel and then finally converts to a user. If you are setting the distinct_id yourself (to say your internal user id) so that if a registered user comes back on a new machine, or after clearing their cookies, you'd like to keep tracking them as the same user. You may then find yourself changing the distinct_id part way through a funnel, which will break your funnel! And unfortunately there is no way to change the distinct_id of an event that has already been sent to mixpanel. Oh no!

The best practice here is to allow mixpanel's JS library (or mobile SDK) to issue its own automatic distinct_id value to a user when they visit your site. Allow the user to send events from that distinct_id as they traverse the signup funnel. At the time of registration (if you are using mixpanel's JavaScript library v. 2.2 or later) then you can fire mixpanel.alias("whatever_you_aliasing_to") to alias that previous id to your newly issued internal id. From then on, when that user returns and authenticates, ensure that they have the id you just aliased by using mixpanel.register({"distinct_id": "whatever_you_aliased_to"}) or mixpanel.identify("whatever_you_aliased_to"). That way you ensure that the signup funnel does not break, and also that you continue to attribute all post authentication activity to that user, using the same id as originally used in the signup funnel. More on aliasing here.

What is the difference between Engagement data and People data?

The Engagement section of reporting pulls and renders event-based data. The People analytics section pulls and renders People data. Right now these two data types are totally separate from one another. That said, often data is sent to both. For instance, when registering a super property marking a user as paid=true, it makes sense to send both people data and event data. The libraries for sending event data can be found here, whereas those for sending people data can be found here.

We recommend Javascript for web integrations

Javascript is the most robust library we have for integrating Mixpanel into your website. You are of course welcome to host the JS library locally, or to modify it if you desire, but unless you have a good reason, we recommend using our snippit that pulls the full library asynchronously from our CDN. Our Javascript has many features to make instrumentation as easy as possible, and if you use our snippit, you will be able to tap into updates that we make to the library without changing your code at all (in most cases).

In some cases, sending events server side makes more sense. For these instances, we offer more functionally limited libraries in many server side languages (python, php, ruby, etc.).

The javascript library works well for mobile applications that consit of html5 views, but for native apps we advise using our native Android and iOS SDKs. Our mobile SDKs are mature, offer the same functional richness as the javascript library, and the strategy for implementation is similar.

Paid customers should be careful who the project owner is

If you're a paid customer, the user who "owns" (is the admin of) the project must also hold the billing information for the project. You can email support@mixpanel.com if you wish to transfer your project or billing info to a different mixpanel account.

Sending data to one project

If you have similar user behavior coming from multiple platforms (perhaps a Facebook game which also has a mobile version), we recommend you send all the data to one project and track the platform the data came from as a super property. That way you can look at one user's behavior across platforms, and choose whether or not to view all user activity on the same set of axes, or filter down to a particular platform. This is of course only recommended when the basic actions taken by users are similar enough to be described with the same set of event names (properties can be different).

Data flexibility

Mixpanel is very flexible and open ended tool. You can use it for anything from measuring how your users fair slaying digital monsters, to QAing a back- end fix, or monitoring and tweaking performance metrics such as how long it takes a UI to render. Anything that can be thought of as an "event" with "properties" can be tracked with mixpanel. Furthermore you can send us data from literally anything that can send an http request. Hacking our data model is not just expected but heartily encouraged. So use your imagination when you send events and properties. Don't let traditional ideas about web analytics limit the questions you can answer in a data driven way. And if you come up with a new or cool use for the tool drop us a line at support@mixpanel.com so we can brag about you!

Now you can hide events and properties

Keep stale event and property names out of your dropdowns. Mixpanel has long offered you the ability to hide events that you've decided are irrelevant or maybe just were typos from the very beginning. We’ve recently extended this functionality to let you also clean up the list of properties that you see when segmenting reports or creating custom events. Say your application tracked an an event called "ate" with integer property called "tomatos". Later you decided to fix the pluralization of this property name and renamed it "tomatoes". Even though you stopped sending events with the "tomatos" property, you'd still see entries for both “tomatos” and “tomatoes” in the dropdown list of properties on your segmentation report. By marking the property name "tomatos" as hidden , you can keep it from showing up in this dropdown and any other dropdown that lists properties. How to h...

XO Group democratizes data to build a better product

XO Group Inc., parent company of The Knot, The Nest, and The Bump, democratizes data across their data science, product, and marketing teams to build a better product. Planning a wedding, cohabiting with your significant other, or expecting a newborn? If so, chances are you’ve already discovered XO Group. With The Knot , The Nest , and The Bump , XO Group brands help make these important lifetime milestones stress-free and enjoyable. XO Group has always emphasized the importance of analytics to ensure their apps continually provide the best user experience. As a leading lifestyle brand, XO Group has a very savvy development team, but this did not necessarily make choosing an analytics strategy an easier decision. As XO Group grew, they found clunky commerce focused analytics tools were not agile enough to provide instant insight to the team. As XO Group continuously expa...

Community Tip: Session length tracking

This Community Tip will explore the utility of session length tracking and describe how to add this metric to your iOS, Android, or JavaScript app. Mixpanel's Engagement Analytics is designed as an event-driven tracking tool for drawing actionable insights from your users' engagement. Traditionally, businesses tracked session lengths as a proxy for user engagement. As you get started with your Mixpanel implementation, you will notice that Mixpanel does not include a default built-in session calculation. Instead, we encourage you to focus on the actions that constitute engaged usage of your application, site, or other web-connected widget. For most businesses, session length is not the best proxy for engagement, but for some, session length is the best proxy. This Community Tip will describe the implementation of session length tracking in our client-side libraries. Additionally, w...

Join us for Office Hours with Cozi & learn how to evolve user experience

Come join us for Office Hours in San Francisco where Tara Pugh, Product Owner at Cozi, will take us through: Evolving user experience with small, data-driven steps — Thursday, June 25, 2015 What it's about For an evolving product, the path to achieving big things looks like this: make a series of small steps, each in the right direction. But where to focus? How do you know if you're headed the right way? Why not make giant leaps? Tara Pugh, Product Owner and user experience program manager at Cozi will describe an iterative, data-driven framework for product development. Tara will outline the approach Cozi uses to optimize important flows and touchpoints using Mixpanel and provide examples of tangible improvements to user experience across mobile, web, and email. Questions about your integration? Need help interpreting the story behind your data? Just want to talk analy...

Community Tip: Naming conventions to stay organized

This Community Tip will describe some useful naming conventions to organize events, properties, reports, and campaigns. Add prefixes to separate product components As your application matures, different teams may be accessing the same Mixpanel project to analyze completely different product and process-oriented user-behavior. This shared studying of a project can very well increase the complexity in reporting, as your Mixpanel implementation accommodates tracking of all products and processes within your application. This can lead to an increase in the number of events and properties deployed to capture key metrics and granularity of data. Using prefixes offers you and your team an invaluable way to distinguish different types of metrics for easy recognition and usage across your teams while maintaining a comprehensive and granular tracking scheme. Prefixes such as "Billing -" a...

Community Tip: Guide to Exporting Mixpanel Data

This Community Tip walks developers through the Mixpanel APIs for raw data and tips to set up an ETL (Extract, Transform and Load) configuration for both Event and People data. Exporting your Mixpanel data can serve a number of purposes whether you simply wish to use the data for raw analysis purposes, store a local copy in your own internal datastore, or pipe the data to another service. API Endpoints for raw Event and People data Mixpanel provides powerful processed API endpoints which provide the formatted Event data you see within the various Mixpanel reports like Segmentation, Funnels, and Retention. These endpoints query your raw data for insight analysis, but do not return the raw data you send to Mixpanel. The raw export API provides a full export of your raw project data so that you can utilize this data for purposes outside of Mixpanel. Instead of returning the nu...

Updated Live View: A more powerful tool to help you debug and integrate Mixpanel

Mixpanel's Live View report displays events coming into your Mixpanel project in real time. Live View is an extremely useful tool for testing changes to your implementation, debugging or QA testing, hypothesizing user stories before diving into deeper analyses, or confirming a hunch about product use. Look at the past actions of individual users By hovering over the icon to the left of the event name in the Live View report, you can see that we can view the profile activity for this user. Individual users are denoted by colored icons. Regardless of whether or not there is a People Profile associated with this user, you will be able to see their Activity Feed by clicking on this icon. Filtering by both events and properties By clicking on the Filter tab at the top left of Live View, you can select to filter your data by the event name or by the properties associated with th...

Community Tip: Personalizing Mixpanel Email Notifications

This Community Tip will explain how People Properties can be used within an email message to customize both the content and presentation. Use these tricks to add personalization and drive deeper creativity in your marketing or lifecycle emails. Mixpanel’s Notifications are specifically designed to give you a tool to engage with your users, and keep them coming back. A great way to ensure your users connect to the content is to tailor the notification, and message itself, with information useful to the person, and what he/she may need at a given point in the lifecycle of the product/service. To illustrate this, let’s imagine the following scenario: I have a mobile game, where you, an up-and-coming space cadet, are tasked with the quite unique and innovative concept of defending the earth against gnarly aliens! I want to set up a notification campaign that looks for people that hav...

Date property filters: Custom cohortize your events

Recent updates to date property filters allow enhanced segmentation and cohortization across all of Mixpanel's Engagement reports. Using date properties you can now create and analyze custom cohorts based entirely on important dates in your user lifecycle. New filters "on" and "between" When segmenting by a date property in Mixpanel reports, you will see two new filters, "on" and "between". These filters allow you to segment and cohortize your users into groups by date properties such as the date they signed up or a range of dates where users converted from free to paid. Using date filters in Mixpanel reports With these added abilities to cohortize users by their date properties, you can now more easily create cohorts of users and track their activity over time. For example, for an ecommerce site, you might wish to see how often users who were created 3 months ago return to ...