Tips for a Successful
Mixpanel Integration

These tips grew out of an hour-long session with a Mixpanel support engineer, conversations with several other startups who have struggled with Mixpanel, and months of experience at Populr.

Understanding Mixpanel's Quirks

Funnel property cascade

Mixpanel funnels cascade properties back from the final event through to the first event. This can be confusing when analyzing data between two closely related funnels.

The plan change in the final step of this funnel, cascades back to the earlier steps

This funnel is identical, except that it omits the final step. Notice how "Overall" is the same, but the other numbers don't match up to those in the other funnel.

People record conflation

If multiple users use your app with the same browser, their data will be conflated into a single people record. This can lead to Mixpanel reporting users who signed up more than once, who reportedly performed hundreds of actions when they just created their account five minutes ago, and users going missing.

If you are testing Mixpanel data in development, use incognito, closing all incognito windows between test users. Otherwise, your different test users will get combined into a single people record.

Spencer Ellinor reports that the Mixpanel Javascript API has an undocumented mixpanel.cookie.clear() function. If you call that after signing users out, you can avoid this problem.

The Up-side of people record conflation:

Mixpanel's conflation of records just saved me a lot of trouble with a user support issue. A user who had unwittingly created two accounts was reporting that a page he had created was now missing. Using the email address associated with the support ticket, I was able to use Mixpanel to review the actions taken by that user. The email address associated with earlier events was different (thankfully I was sending the email address as a super property). I searched our database using the earlier email address and found the account with the "missing" page.

Two users conflated into one "People" record. Notice the two Signup! events.

Searching by property

Searching for a particular value may not yield any results, even though a match exists.

To get around this, search by "contains", not "equals". (Press "return" to show the results since the dropdown still may not have the desired results.)

Insight graphs

Insight graphs arbitrarily define the x-axis granularity. They also create a catch-all bucket that dumps huge ranges into the last bar, obscuring any inferences one could otherwise make from those data.

I this graph, the data being graphed are integers, but the graph mysteriously includes half-integers, all empty.

Mixpanel Integration Tips

General event names

Use a few general event names with properties you can use for segmentation. For example, instead of “Visited Homepage” and “Visited Sign-up Page”, we have a single event called “Visited” with a “Page” property.

Similarly for actions taken related to the subscriptions. We have a single "Subscription" event with different "Action" properties.

Keep super properties and people properties up to date

There are certain data that Mixpanel sends with every event. These are called “super properties”. Many of these properties are set by Mixpanel automatically when a user arrives at your site (eg: utm variables and referrer). However, Mixpanel just stores these as cookies. It doesn’t propagate super properties across devices. So if you have a user who comes to you from an Adwords campaign, and then comes back and signs in from a different device, some of that user’s events will have the utm variable, while others won’t! So for data like this, go ahead and store them in your the database. And then every time you identify a user, call mixpanel.register with those data. While you’re at it, include other useful information that is subject to change, like what plan a user is on.

Remember that event data is separate from people data. If you register with updated data about your user, it doesn't automatically get sent to that user's people record. However, Mixpanel makes it painless to keep people data up to date: People data is charged on a unique person basis. You can update individual person properties as much as you want at no extra cost. So go ahead: every time you send an event, update your people data, too.

This is a Ruby on Rails partial rendered into every layout on Populr. MixHelp is a class we wrote to help keep logic related to Mixpanel DRY.

Track refunds

track_charge can track negative amounts, too, so it can keep up to date with refunds and chargebacks.

We have a Mixpanel helper class that abstracts our Mixpanel logic. This class also turns all the Mixpanel calls into background jobs.

Don't rely on magic

Mixpanel isn’t magical. It can’t answer the question for us about what constitutes a user conversion or churn. You have to decide that. Once you do, send Conversion and Churn events to Mixpanel, and set Converted and Churned properties on your people.

We decided on the following definitions: A user is converted when we first receive payment from that user. A user churns when a converted user chooses to downgrade, deletes his account, or has a repeated card failure that causes an automatic account downgrade.

Here are some user properties we set related to conversion and churn that we can then explore in Mixpanel:

Converted (a date)
Churned (a date)
Conversion Delay (in days)
Paid Lifetime (in days)

Telling Mixpanel when conversion and churn happen. Note that we use Conversion! and Churn! simply because I messed up the data a few times and burned through other variants of those words.

Some things, Mixpanel cannot do

Even after deciding what conversion and churn mean for us, Mixpanel doesn’t actually compute churn, though it is useful for funnels, trends, and people analysis. But now that we have decided what they mean in the context of our app, we can compute churn ourselves (we used this for our definition of churn).

A new startup, Baremetrics, uses a company’s Stripe credentials to provide a fantastic dashboard with insight into all manner of financial related questions, including churn and ARPU.

Some things you have to do for yourself

If you find something valuable enough to store as a Mixpanel people property, store it on your user model, too. That way, you can perform your own computations for things that Mixpanel doesn't have an interface to compute (for example: churn). You can use Mixpanel as a database, but having the data in one's own database is more straightforward.

Tracking events from the back end

In many cases, people data will be updated from the back end server in response to events that do not correspond to actions taken by a user (eg: when a monthly charge is received). In these cases, it is important that the "last seen" people property not be updated. All of the people property API endpoints accept an $ignore_time property that will prevent "last seen" from changing.

When sending events from a server, set $ip = 0, otherwise the location of the user will be replaced in Mixpanel (thanks again to Spencer for this tip and for reminding me to mention $ignore_time).

This Ruby code relies on the mixpanel-ruby gem. Note that $ignore_time is sent in a separate hash/object from the properties being updated.

Dates, not booleans

Store dates rather than booleans (where it makes sense, such as when a user converted). It doesn't seem that there is much one can do with this now, but this tip came straight from a Mixpanel support engineer.

Take care planning events

You cannot delete Mixpanel events. If you realize you have a mistake, you need to come up with a new name. You can hide events from the interface, but they aren’t deleted. Mixpanel events are also hidden from the interface if they haven’t been received in 30 days.

Understand mixpanel.alias()

mixpanel.alias() is well documented, just be sure to understand the documentation.

Live with past mistakes

Don't migrate data from one project to another. If you need to clean up data, you can use a new project to test a migration, but perform the final migration back into the original project. After migrating, you can hide unwanted events, or just wait 30 days for old events to disappear from the dashboard automatically. The full explanation is rather tedious, and involves some unverified hypotheses, but you can read it here.

Corrections / Tips

If you have corrections or additional tips, please send them to

howdy@populr.me so we can update this page.

Follow this page using the button over there 

if you want to be kept up to date with corrections and new tips.

Tips for a SuccessfulMixpanel Integration