Last weekend Diego Menchaca, founder of Teamscope and apparently also a big fan of our blog posts, proposed that I should write a blogpost about Mixpanel. “Most blog posts tell what to track on Mixpanel, but it would be great to know what’s your approach when defining events and properties.” We love Mixpanel at NEXT and use it with almost every startup we mentor, so here it goes Diego: Our first deep
Forest for the trees
One of the most important lessons for me has been not to track everything that is happening within an app or website. The less you track, the more focus you have on the events that you are tracking. It’s easy to see one tree grow, but when you look at a forrest, the individual trees all blend together. My advice is to track 5 or 6 events max. Remember, a metric is only a good metric when it changes how you behave.
What to track
I normally track only a couple of standard events. Session started for the beginning of each session, Signup and Login of course and the key activity. Everything else is less important when you start with Mixpanel in my opinion. With these events you can build your funnel for tracking your Activation rate and populate the Retention diagram.
Besides tracking events, I always enable the People profiles as well. I love the possibility to send push and email to users based on properties in their Mixpanel profile, especially because you won’t need your developers to play around and optimise your messaging. It is very easy to send an email the day after someone signs up or a push notification when a user has not been seen for 4 days.
But to correctly setup People tracking, you need to get two things right: identity and alias.
Identify and alias
Identi-what? Identify and Alias are two calls to Mixpanel to register your users and link them to your own user identification. It is something hard to wrap your head around and it is often done wrong. Please note that it is probably your developer that truly needs to understand this, but no harm is done trying to understand this yourself as well.
When a user signs up you call the alias function. This way you tell Mixpanel that the id Mixpanel assigned to the user is interchangeable with your own id. Next time you send an event, both your own id and the Mixpanel id is usable. Please note that Mixpanel can only alias 1 of your id’s to their Mixpanel id. If Mixpanel id abc is aliased to user id 1 and then after a while is also aliased to user id 2, the second call silently fails and things gets screwed up. Best way to prevent this is to correctly handle a logout scenario.
When a user logs in you call identify. You tell Mixpanel that the user is known to you and if the user has signed up and aliased after you implemented Mixpanel it gets linked to all the previous Mixpanel events. if the user is new to Mixpanel because she signed up before Mixpanel was implemented a new user is created. This also works when a user logs in on a new device or platform, after signing up somewhere else.
Naming events and properties
I always name events as human readable as possible. You can use spaces and special characters, so no need to have your developers come up with names like userActivationStep4, just call it Onboarding Step 4 Completed.
I set some super properties as well, properties that are send with every event. Set the platform on which the event happens: iOS, Android and Web. There is not a single property in Mixpanel that tracks the platform. On iOS you can see the SDK version, on Web the browser, but it is good to be able to segment on a single property. For example to filter your funnel. I also track if a customer is a paying customer, so I can see how paying customers act differently than non-paying customers, by setting a super property like Premium to true (or false).
How Cocoon tracks the Pirate Metrics in Mixpanel
Most articles and books about Analytics fail to become very practical and hands-on, so let’s try and give a concrete example on how a startup would track it’s Pirate Metrics in Mixpanel.
Cocoon is a platform that helps you find meaningful jobs at fast growing companies. It is a two-sides platform with both companies and job-seekers. When the job seeker likes a job and the company likes the job seeker, a match is made and it is possible to start a chat. To make this article not too complicated, I will only show you the job seeker side.
Cocoon’s funnel is the following (these are the actual event names I copied from Mixpanel):
- Viewed Login screen
- Login (Cocoon uses Linkedin as the sole way to register, so Login and Signup are the same)
* Event properties: Profile: Linkedin (just in case another network is added in the future)
* People properties: Job Ratings: 0, Logins: +1,
- Started onboarding
- Selected Skills
* People properties: skill_count: X, Skills: [list of selected skills]
- Ranked Skills
- Clicked start
* People properties: Completed onboarding: true, Onboarding Completed: date
- Rated Job (key activity)
* Event properties: Liked true/false
* People properties: Job Ratings +1
- Sent Message
Cocoon goes a bit further than just tracking the session start, signup and key activity, because they have an onboarding process they want to track and optimise. They kept their event dictionary very simple though and tracked as few events as possible. Just enough to follow a user from Login to the end of the funnel by tracking Sent Message. They do not yet have a referral program or automated way to pay, so they left out the last two R’s from the AARRR funnel. Retention is however something I like to explain a little bit more.
Retention is not an event unfortunately, so also not part of the funnel. At Cocoon we are are looking into ways to mark a user as retained on an individual level, except only as a ratio in the cohort diagram. If you have any ideas, please share them with us!
We wrote about Retention cohorts in a previous blogpost, so we won’t go into that again, but one of the nicer things of tracking Retention on Mixpanel is that you can really dig deeper to find the pain.
You can select the retention of users who signed up and then came back and did your key activity. Cocoon looks at the people that Logged in and then came back and did Rated Job. This way they can truly track people who Logged in in week 12 and came back in the following weeks and Rated Job again. If you only look at Recurring Rated Job, there is a sliding window of people who Rated Job in week 12, 13, 14 and 15 that come back in all the vertical rows, instead of only in week 12.
Another great feature of Mixpanel is the segmentation of retention:
Paul Veugen, founder of Human, told me about this feature a couple of weeks ago. He mentioned that he segments the retention of his users based on iOS App Version, except only time. I didn’t know it was possible with Mixpanel, so I want to share this with you as well.
These are in my opinion the basics of Mixpanel tracking. Track your basic 4 events and start optimising your solution based on these numbers. Focus on Retention and Activation first.
Let us know in the comments if there is anything else you want to know about Mixpanel!