Three frequent Mixpanel funnel gotchas
The ones among you that know me well, also know that (a) I like data and (b) I like Mixpanel. Mixpanel is a pretty cool analytics tool1 and one of the wonderful features it adds are funnels. Funnels, essentially, help you to figure out to see, what the conversion rates are in a sequence of events and where users drop off, so you can identify improvement potentials.
They seem pretty intuitive to use, which they are, but there is some things which can be pretty confusing and you need to pay attention to, otherwise you might end up with some results that is very different from what you’d expect.
One of the most common issues that I see with funnels is someone doing something along the lines of the following. Let’s say you want to see how many people look at a specific post and then actually end up sharing that post. Your typical PM will build a funnel with something like the following events:
- Viewed post
- Clicked “share post”
- Shared post
Sounds reasonable, right? User looks at the post, initiates sharing and then actually performs the activity.
The problem here is, that if you do this, you don’t actually know that the user performed all of these actions on the same post. Something like the following might happen without you knowing:
- User views post A
- User clicks on “share post” on post A
- User abandons sharing
- User views post B
- User clicks on “share post” on post B
- User share post B
With the above setup, if you only look at the single user, your conversion rate is now going to be 100%. Does that sound right to you? Seems inaccurate to me.
The thing here is, Mixpanel can solve for this, you just need to do it. There is multiple things you need to do about the defaults here to address this.
#1: Counting users, not attempts
By default Mixpanel will not report the funnel based on how frequently it’s started, but on a per user base. Mixpanel will throw a cookie at the user and if the user performs the funnel start event (view post) multiple times, it will only count as 1.
Luckily this is super easy to change (if you know about it) and might give you some interesting insights into how frequently people attempt things multiple times before they actually finish them.
With this change done, you will now see the correct conversion rate of 50%.
#2: Correct event grouping
However, there is still something wrong. Both the time to conversion might be wrong as well as the ability to understand which posts are working well and which ones are not. Why? Because mixpanel will mix events together that don’t belong together. The conversion Mixpanel will see is from “View post A”, to “Click ‘share post’ on post A” to “User shares post B”, instead of looking at A and B separately.
This is probably one of the most frequent mistakes I see being made with funnels.
Luckily this is also super easy to fix, presuming you have the right setup going already. Mixpanel allows you to group events together based on a shared property. So if your engineering team did a good job in setting up the tracking, all of the above events will have an event property, that might be called Post_Id
and contains the ID of the post that the event is performed on.
If that’s not the case, you should pop off and tell them to do just that right now. 🙂
If it is already the case, you just need to find the option to set this up, which is hidden away in the “Advanced” menu and called “Holding property constant”. Here you can then select the event property with the post id. If it has not been implemented correctly by your team, you will see your funnel do super weird stuff (as in conversion will drop to 0).
With that now correctly set up, you can then see whether there is patterns to the posts that convert better and you will also get the correct times to completion as well as the correct conversion rates.
#3: Attribution touchpoints
The last thing that I see frequently go wrong is attribution. A lot of people will build their funnel and then go “okay, let’s throw some UTM breakdowns at this and see where people come from”. However, they don’t notice a rather important flag, which is the tiny, grey “last touch” above it.
Basically, by default, Mixpanel will base breakdowns based on event properties (vs. profile properties) on the last touch. Unfortunately, this is not always what you want. But what does that even mean? If you don’t change anything, Mixpanel will take the UTM parameter from the last event in the funnel (in our example the UTM parameter that was supplied when finishing the signup).
This might be interesting if you’re i.e. looking at figuring out what event pushed a user over the line to complete their purchases (if you are sending emails to remind people about abandoned baskets), but if you are looking at which ad campaigns are converting the best in your signup, it’s likely going to give you wrong results, worse: if you have a multi page signup with full page reloads it might not give you any at all.
Luckily, this one also is really easy to fix! You can just change the attribution using the dropdown. Just think about what you want to measure and you can make it happen.
-
Which also has great product direction. Kudos to the PMs at Mixpanel, they discontinued a bunch of features that did not align super well with the core focus of the product (e.g. around messaging) and refined a bunch of the core features (e.g. allowing to customise the periods for retention and much more). They also added a bunch of really cool stuff, like Signal, which is basically impossible to do yourself without a bunch of data scientists. I only wish they paid a little more attention to the JQL feature, which is SUPER useful when you really need to do something a bit more crazy. ↩