Best practices

A lot of our customers continuously ask for a meeting or phone call where they ask us for guidance in response to best practices. In this piece I am going to help detail some of the most common best practices we typically advise. Over time we’ll either add more or keep this article up to date.

The best way to get started

We always advise you instrumenting only 5 main metrics you care about. Sometimes just 5 events or actions. We advise this because we wish to prevent a severe amount of data overload as you push your instrumentation to live users and begin inviting all your co-workers. Our five metric rule also helps you stay focused on the most key metrics you have. We think you’ll see more value out of our service. You’ll also be able to start making decisions on that data faster as opposed to spending a lot of time on full blown instrumentation you may have done incorrectly or named badly.

We also advise potentially building only a single funnel you think you can improve.

We recommend Javascript for integration

Javascript is the most robust library we have towards integrating Mixpanel on your website. We also advise using our Javascript library from the URL we tell you to include it from as opposed to serving it on your own because we do update it often. Our Javascript has many features to make instrumentation as easy as possible.

For mobile, we advise using any backend library (Python, PHP, etc.) because you won’t have to re-ship your application for pending review every time you want new metrics data. We understand there are limitations to that in which case you must use our mobile libraries.

Make good use of properties

Properties are essentially extra information you can send along with event. For example, you might want to send the gender, age, or source of a particular user along with the event. This enables you to drill down on your data in very complex ways. It’s important to keep in mind that properties are entirely defined by you. We have customers that sometimes want to set the datacenter the user’s data is in. Don’t mash events with properties. For example, don’t do: mpq.track(“Act: Purchase, Gender: Male”). What you really want to do is: mpq.track(“Purchased”, {“gender”: “male”, “age”: 13}).

This makes Mixpanel’s UI and reporting significantly easier to understand.

Clear event and property naming

We advise using clear event and property names always. 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 nicer for everyone on your team. For example, don’t use send us a c_id which might be a video channel. Send us a property called “Channel” and send a plain-text representation as opposed to a raw numeric id.

Keep your development data separate from your production data

A common question is how do we delete some old development data while we were instrumenting. The answer here is you cannot. We advise all customers to create two projects. If our project was called “Mixpanel” then we would call one project “Mixpanel – Test” and the other “Mixpanel – Production.” 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 only on the amount of data you send us.

How do I track distinct users and what should I use?

We have a special property called distinct_id and you should set the value to something like a user_id. A common problem is what happens when you have a user who isn’t signed up yet and then eventually does. It would be nice to remap the unique identifier. Unfortunately, we don’t have this functionality quite yet. A solution we often recommend is to set a session id or your own generate unique id, store it persistently in your database, and then use that all the time even if the user signs up. This way you can map guest uses who then login or sign up.

A common problem we often see are customers accidentally sending distinct_ids that have the same value for all events. Our system doesn’t respond well to that and will automatically detect and stop recording data that looks like that.

If you are using our JS library, make sure you call .identify as early as possible (e.g. before you do any .track() calls) that way the user is attributed on the first event or page load.

Paid customers should be careful who the project owner is

If you’re a paid customer the person who created the project must pay for the project. You can email support@mixpanel.com if you wish to transfer your project to someone else in your organization. It’s always best to set the project owner to whomever is going to be in charge for paying for the account. At some point we may improve this. Please email us feedback of how you ideally wish it worked.

Varied projects

For complicated applications it sometimes is useful to split your application up into a variety of Mixpanel projects. Lets say you’re Fitbit.com, you may want to split your mobile metrics from your website metrics. If you’re Facebook, you may want to split up people interacting with the newsfeed from people interacting with groups/events. In games, it can be useful to do this moreso depending on the complexity of the game. The only tradeoff here is consolidation where you may want to compare metrics from mobile and web which can be less than ideal.

Data flexibility

Mixpanel is very flexible in that you don’t have to use it just for engagement metrics. You can use it for QAing (if metrics dip down) or performance things such as how long it takes a UI to render. Everything really maps to an event (a server connecting or a door shutting). Hacking our data model to do something different than expected is actually intended so use your imagination when you send events and properties.