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!

How to give a killer product talk

We’re not huge on listicles over here, but we’ve been told they’re engaging, and this article is all about engagement. Not in-app, but on-stage. There may come a day when you're invited to a sensibly lit room with sensibly adult beverages (such as Mixpanel’s Office Hours) to explain to a crowd of developers, product managers, data scientists, and tech enthusiasts how you built your product. And having a 20-minute mark to make your point, you’ll want to find the best way to communicate your biggest victories. We’re going to help with that. For the past few years, we’ve had the brightest minds in tech coming through on a (roughly) monthly basis to talk about how they used data to build awesome products. We’ve seen speakers from startups, mid-market companies, enterprise businesses, and incubators. They’ve called on all sorts of multimedia, sketches, and customer feedback, but the...

Here’s what happened when Mixpanel finally built an app

“You’re going to have to shut off your computer. We’re about to take off,” said the flight attendant. Sergio, an iOS engineer for Mixpanel, needed one more minute. He was about to push his code and solve a problem in the app that had been bugging the team for weeks. Getting this update over to the team before a major product review felt just as urgent as the plane taking off on time. Mixpanel was about to launch our app and there was no time to waste. Our users can relate to that feeling on a daily basis. Building an app, especially under a deadline, is a high-pressure job. And to be completely honest? We should’ve known this already. At Mixpanel , we do analytics to help mobile developers learn from their data so they can do their job well and build something great. But here’s the kicker. We have been helping app builders do their jobs without doing it ourselves – until...

The Zen of Tomasz Tunguz

Whoever can see through all fear will always be safe. – Tao Te Ching A whisper in a Manhattan barroom, an idle conversation at a Palo Alto coffee shop, and rumor mills start to churn. The internet streamlines and aggregates this gossip and soon, before it should be possible, markets are dipping and someone halfway around the world is panicking, and the panic builds until companies are shedding value and employees. The antidote to all of this gossip and speculation is, as it should be, data. That’s what gets Tomasz Tunguz up before everyone else in the Valley. It’s why everyone from entrepreneurs to investors flock to his blog. His data-driven insights and metrics offer sanity and clarity on the state of tech, and of SaaS in particular, and cut through the panic. But that doesn’t mean his chart-filled posts don’t also have a quietly beating heart to them as well. “T...

Julie Zhou's discipline of growth

“Oh my God. How do you do that?” This is the slack-jawed question for Julie Zhou when friends learn that, after turning off the lights at Yik Yak’s West Coast office, she hits the gym and pumps 240 lbs. of pure iron. But Julie is certifiably flyweight, weighing in at just over 100 lbs. How can she lift something at that scale? Her answer, as it turns out, is fairly rote and unexciting: “Every single week, you lift one amount. Next week, you add five more pounds. Then, you add five more.” And yet there may be a deceptive genius here. Deadlifter by night, Julie effects a similar magic in her work life. She helps startups get swole. General Assembly’s Introduction to Growth Hacking is a slightly more expensive (and extensive) version of Julie’s answer. At the helm of this class, she draws from her decade-long experience growing companies and teaches how strategic perse...

Danielle Morrill's guide to the galaxy

You can depend on Danielle Morrill, co-founder and CEO of Mattermark, to draw the line between what’s important and what’s industry bullshit. Notorious for her Tweetstorms – dropping the mic on a recent one with, “Yes, I’m ‘too aggressive’ and that’s why I get what I want” – Danielle talks like she acts: fast, often punctuated with four letter words that might make your grandmother blush. I witnessed her electric personality in full force when I met Danielle at Mattermark for this interview. I was surprised when she didn’t take me to one of those airy, glass-plated conference rooms that litter most “open plan” startup offices. Instead, she led me downstairs, walked up to a bookcase, and tugged on a copy of The Hitchhiker’s Guide to the Galaxy, opening the door to “The Secret Office.” “This room gives us major nerd cred,” she told me with a grin. It’s also where she presents j...

Introducing JQL: A Query Language for Analytics

Today, we are excited to announce the official release of JQL (JavaScript Query Language), a powerful new way to access your Mixpanel data. By letting you write queries using JavaScript, JQL is flexible enough to answer any question about your data while remaining familiar and intuitive. Although JQL is a general-purpose tool, it is designed to make it easy to express typical analytics queries about customer behavior. It has a functional programming design, centered around streaming primitives like map, groupBy and reduce. By composing these elements, it is easy to write queries that scan over user activity streams, compute aggregates, or slice and dice the dataset on multiple dimensions. The aim of this post is to explain the purpose of JQL, the motivations behind its design, and our plans for its future. Why create JQL? We created JQL so that our customers could query their...

Why tracking less got VSCO more

In a meeting room in the VSCO office, on the corner of Broadway in Oakland, Steven Tang and Matt Turner stood in front of a whiteboard that was covered in little neon colored squares. Each Post-it Note had a phrase scribbled across it: “Picture taken,” “Filter applied,” “Image saved.” There were tons of them, accounting for each and every event that VSCO was tracking in their photography app. Some were vital to evaluate the success of the app, but many weren’t. It was an illustration of a problem they already knew: their data had gotten out of control. Matt is a Product Manager at VSCO, an app that enables over 30 million active users to create, discover, and connect through images and words. He has been there for four years and is part of the core team driving growth and engagement. He is now responsible for metrics across the company. Steven is an iOS Engineer at VSCO an...

No good data goes unpunished

Every so often, an email will appear in the inbox of careers@bayesimpact.org: “I have a good job. I’m ostensibly successful. But I feel empty inside.” The recipient of these emails can relate. Eric Liu, Paul Duan, and Everett Wetchler founded Bayes Impact after their high-tech gigs had stopped answering meaningful questions. Since 2014, the nonprofit has recruited several full-time engineers and data scientists to its cause: solving the world’s most intractable problems through an ambitious mix of data science and software. "Not to knock anyone who gets a lot of satisfaction from working in a for-profit job,” Everett begins. “I worked for Google. I worked with wonderful, kind, brilliant people on fascinating scientific problems.” Although he sounds sincere, one can hear the but... to follow. He too came from a good job. He too was ostensibly successful. He too was feeling...

Data Loss Incident Update

This post is an update regarding the data loss incident we had a month ago . The purpose is to describe what we are doing to prevent similar failures in the future. Incident Recap On February 22, 2016, we had a data loss incident that resulted in 9% of our customers losing their events from February 22 or 23, 2016, depending on the customer’s time zone. For more than half of those affected, we lost less than 1% of events from that day. However, in many cases it was more, and in some cases, it was the entire day’s worth of events. It was our worst instance of data loss in four years and a very stressful, disruptive experience for our affected customers, the Mixpanel engineering team, and the rest of the company. The incident raised two fundamental questions. First, how did a bug get rolled out to all production data servers without being detected? Second, given that bugs will ha...