Tips for a Successful
Understanding Mixpanel's Quirks
Funnel property cascade
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.
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.
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.
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)
Some things, Mixpanel cannot do
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
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).
Dates, not booleans
Take care planning events
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.