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!

Community Tip: List Properties

Today’s Community Post will cover the ins and outs of list properties. We’ll go over how to set list type properties and why you want to use them. What is a list property? Event properties are a great way to send Mixpanel a lot of detailed information about how users interact with your website/app. In addition to lots of awesome property datatypes (numbers, strings, booleans), we support list properties. List properties are as simple as the name sounds—it’s a property containing a list of information! List properties allow you to describe dimensions that contains more than one value. When would you want to use a list property? You would want to use list properties whenever you have more than one value for a given property. Some examples: Items purchased in a “Checkout completed” event Multiple artists for a “Song Played” event Experiment groupings for A/B ...

Community Tip : Addiction Best Practices

This Community Tip will illustrate how to interpret Mixpanel’s Addiction Report. We’ll walk through some best practices and methods for using the Addiction report to analyze your users’ behavior with an eye towards actionable insights. Our Retention report shows the portion of your customers or customer cohorts who engage with your application. Mixpanel’s Addiction Report takes it to the next level and analyzes the minimum number of hours or days your users engage with your app. How to interpret an Addiction Report The first column of the Addiction report displays the number of users in the cohort displayed on that row, just like our First Time and Recurring Retention reports. In the screenshot below, it means that 6,054 unique users fired an “App Open” event on February 1st. Each of the buckets (column headings) to the right indicate how many hours in day, days in a week, or day...

Updates to segmentation: See your top events & compare events too

We've made Segmentation a whole lot better, and we're excited to share all the updates we've made: See an overview of your top events We've made it possible to see an overview of the highest volume events that your users take in your app. It can help you see spikes in your data, and it's just a convenient way to get a snapshot of how things are going. Compare trends more easily Comparing two or more different events is now possible, so you can analyze the correlation between events. Just click the compare menu option after picking the first event. Plot your data in logarithmic scale It can often be tough to compare two trends if one event or segment dwarfs another or if your app takes off and creates a big spike in your metrics because the big differences in scale make it hard to see what's going on. With a logarithmic scale, you'll be able to compare and correlate...

Community Tip: Incremental Super Properties

This Community Tip will outline how to create incremental super properties using our JavaScript SDK, so you can keep a tally of how often a user takes specific actions on your site or in your app and then segment any event by count. What Makes A Super Property So Super? Before we dive in to incremental super properties let’s have a quick reminder of what super properties are. Super properties are client-side properties that are automatically attached to every event that a user sends to your Mixpanel project. They make working with Mixpanel data much more convenient because they act as global properties that are omnipresent in all your events (given that the cookie is not cleared). Some examples of information that you may want to attribute to every event are ad campaign, signup date, or paid account type, etc. It’s important to note that super properties are only for events , not...

Making one-time notifications better

Today we launched a major enhancement to our notifications dashboard that will give you more power over your one-time notifications. Previously a one-time notification meant sending a message to the wind. While useful for notifying, they couldn't be edited, cancelled, or analyzed after the fact. No longer - now one-time notifications are at your beck and call: The new notifications dashboard gives you a clear view of what one-time notifications are in flight and allows you to cancel them or even change their contents before they send. You can now view sent, opened, and conversion statistics for one-time and recurring notifications through the same analytics page: Our goal behind these changes is to better unify the notifications product and expand what you can do with it in the process. We give you better tools, you make better things happen. With that in mind, happy notifyi...

Formulas: Calculating with numeric values

When it comes to Mixpanel products, we’re all about constantly making improvements that our users have asked for. Regarding the formulas report, one thing we’ve had numerous requests for is the ability to add numeric values into a formula. Well Mixpanellers, ask and ye shall receive: The most basic and useful application of this is a formula where you would like to see percentage values rather than decimals. In our case, let’s look at a common event and take the number of mobile occurrences divided by total occurrences: As you can see, the x-axis values are calculated as decimals between 0 and 1. In order to transform the values in this chart into percentages, all we have to do is multiply the numerator by 100: And there you have it, a simple addition to formulas that greatly increases their flexibility. For more use cases and ideas, get in touch with our extremel...

How Fleksy Fell In Love With Data By Using Mixpanel

This is a guest blog post by Derek, Fleksy's Head of Product Marketing I have a confession: there was a time when data and I didn’t get along. I’m a brand marketing guy at heart, and my data-related technical skills are limited. Luckily, I have pretty good instincts. For years, I often viewed heavy data-diving as an aggravating drain on my time. Interpreting data? No problem. Manipulating it? Big problem. I would spend hours slicing data on Google Analytics, Flurry or other tools in every way possible, but more often than not I couldn’t find the key insight I really wanted. The only way I could extract meaningful insights was to task a database engineer/analyst to manipulate raw data to fit my needs. If I needed to make a quick decision, I had no choice but to trust my gut. At Fleksy, we’re building the fastest and most fun keyboard app in the world, and we’re iterating rap...

Community Tip: Tracking First-time Users

This community tip outlines how to track the first time a user visits your website or app so you can measure your metrics in terms of new versus existing users. First-Time Users First-time users are defined as any user who arrives at your website or app for the first time - you have never seen this user before. It is important to know who is a first time user versus a returning user in terms of measuring your metrics – 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? Answering these questions will give you valuable product insight not readily available by looking at all users simultaneously. By measuring first-time users you can get a granular view into what your users are doing when they have never used your website or app before. You may find user experience insights that yo...

Community Tip: Importing People Profiles from other email tools

This Community Tip will outline how to import your external mailing lists into Mixpanel People profiles . Are you a marketing guru that depends on a certain monkey-related e-mail tool or other email marketing service providers? Mixpanel makes it easy to import these users' email addresses, names, unsubscribe status, and other details as People properties into your Mixpanel project. You can then use these details as targeting criteria to group users and send them tailored messages to increase the likelihood of a response or downstream action. Impress your users by demonstrating how well you really know them! Most mailing tools allow you to export your users to a CSV. A little manipulation will optimize this CSV for importing into your Mixpanel project. No code required! 1) Add a $distinct_id column The first property that you will want to consider is $distinct_id . You can ass...