The Global VC

Implementing Mixpanel: What You NEED to Know

Article image
500 Global Team

500 Global Team

PUBLISHED

2013.12.05

SHARE

FacebookTwitterLinkedinMail

TAGS

This post is part of the ongoing Distribution series. Every week the 500 Distribution Team highlights actionable resources for marketing your startup. Get even more tips by following @500Distribution on Twitter and subscribing to our email newsletter.

You might be overwhelmed by the sheer number of analytics platforms for startups. In my opinion, event-based analytics provide the most insight, unlike a platform like Google Analytics that focuses on usage metrics like pageviews and time on site. After testing out a few options, I’ve come to really like Mixpanel because it’s simple, fast, and has great documentation so you can get up and running quickly.

But even with great documentation, there are a few mistakes that first timers are likely to make. Here’s what you need to know to get started.

Client vs. Server Side Implementation

The first thing to know is the difference between a client side and server side implementation. With a client side implementation, you are sending events/properties to Mixpanel via javascript. The javascript gets triggered from your user’s computer, as opposed to a server side implementation which gets sent directly from your servers.

There aren’t many differences between the two types of implementation, but this is why I think server side is the way to go:

With client side implementation, many features of Mixpanel are built right into the javascript library. The idea of super properties (don’t worry, I’ll explain later), aliasing new users to existing or newly registered users, setting and creating distinct IDs –  all of this is just built in. But even with all of these features, I still choose to do server side implementations.

Doing everything server side is more manual, and this means you have more control over everything. You will need to code certain features yourself, but you’ll have a better understanding of how everything works. Lastly, you will notice that sending events and properties server side is more accurate. The vast majority of internet users have javascript enabled in their browser, but it’s still not 100%. I want control and accuracy, which is why I choose server side. The rest of this blog post will assume you are using a server side implementation.

Distinct IDs

Distinct IDs are the way all event based analytics platforms associate different events that occur on websites to the individual users who perform those events. Each user, whether signed in or not, should have a distinct ID. With a server side implementation, you will need to create and store distinct IDs for both brand new and existing users.

A distinct ID is any string of characters that can uniquely identify a user of your product. You will send the distinct ID along with each event to tell Mixpanel which events were performed by which users. Since we’re doing everything server side you will need to create this distinct ID yourself.

But what do you actually do with your distinct ID? When do you create a new one? What about existing users? Here’s how to create and assign distinct IDs for different users that come to your site.

The distinct ID for users can be stored in 2 places: in our database, or in a cookie on the user’s computer. We should always try to use the database version first, which requires that a user is registered and logged in.

When a user visits our website, we first need to check if they’re logged in. If they are, that means they are registered and can’t be a new user; if they aren’t, check if the user already has a cookie from our website. A user could already be registered but not logged in, and if that’s the case, they should already have a cookie from us.

If we determine that a user is brand new (not logged in and doesn’t have a cookie), we need to create a distinct ID for them.They aren’t registered yet, so we shouldn’t store their distinct ID in our database. That’s because we don’t have a good way to associate this user with a database record. Instead, we’ll create and store their distinct ID in a cookie on their computer. When they register, we’ll store their distinct ID in our database.

People vs. Events

Mixpanel breaks down analytics into two parts: people and events. Events are actions that happen on a website, such as a registration, purchase, or a click.  People are the customers that perform these events. In the screenshots of Mixpanel below, everything under “engagement” has to do with events, and everything under “people” is – obviously – people.

people events

Super Properties

Super properties are extremely powerful. Using them, you can set up persistent properties that are sent with every event to Mixpanel. Normally, properties are only sent once per event, but with super properties, we can set a property that gets sent with every future event a user takes. We use this feature to conduct split tests. When running a split test, it’s important to pay attention to two things: the outcome of the page the experiment is testing (of course) and how the different variants in the split test affect their actions going forward.

Super properties are one of the features that come built in the Javascript library. However, we need to build this feature ourselves when running a server-side implementation. To accomplish this, we need a function that stores any number of properties to a cookie for the user. Then we need to wrap the mixpanel.track() function with functionality that reads every super property from the cookie and sends them with the event. Lastly, set each super property to the user’s “people” property since we also might want to segment our users based on their super properties.

Conclusion

Mixpanel is a great tool, but it can be a little overwhelming to set up. Be sure to think through how you want to model your product using Mixpanel before you start coding. Even after implementing Mixpanel on 10+ products, I often require revisions after the first implementation. As with everything, analytics is an ongoing process. Understanding why things happen in your product is critical for every startup, so the time required to get analytics up and running is well worth it.

What’s Next?

If you enjoyed this post, first check out these additional resources for how you can up your game from the 500 Distribution team:

Then, sign up to get a daily bite-sized distro hack (and one awesome GIF) delivered to your inbox:

>> Subscribe to Distrosnack here <<

500 Global Team

500 Global Team