Best practices - Mixpanel
Blog Post

Best practices

Suhail Doshi

This post is out of date

Read the updated version of this post here

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

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

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 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, 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.

Get the latest from Mixpanel
This field is required.