Implementing Mixpanel: What You NEED to Know

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 <<

Matthew Berman

Matt helps 500's portfolio companies understand their analytics and get more people to their product by any means necessary. His best strategy so far has been carrier pigeons. When not helping startups, Matt can be found running after his dog on the beach while she chases birds (carrier pigeon recruitment?).

Never miss a beat

  • http://mixpanel.com/ Tim Trefren

    Matt – this is awesome. Thanks for the detailed writeup.

  • Owen McGab Enaohwo

    Matt Mixpanel vs KissMetrics which is easier to set up?

    • InstaPage

      Mixpanel hands down!

  • John Strom

    Mixpanel was good when we were first launching and had just raised some seed funding, but it simply doesn’t scale in terms of cost or granularity. There’s a reason Mixpanel is primarily a tool for tech start ups, not growth stage or mature companies.

    We switched to Snowplow (and Looker as a front end, which we already used from our early days) when our Mixpanel costs got too high to justify the diminishing benefit. Snowplow is free, open source, and we can marry sensory data with transactional data (Mixpanel data is silo’d and rolled up). Snowplow also works well with our existing data stack of Redshift + Looker… we will write a blog post about it eventually =)

    • yaliatsnowplow

      Hi John,

      Great to hear you’re using Snowplow. We’re working with the guys at Looker at the moment to find out ways to make it easier for people to integrate Looker and Snowplow – most of them are around providing some initial models for Snowplow data that people can then extend themselves to accommodate their own custom event dictionaries and business logic. If you can spare some time for a short call I’d love to find out about your implementation, and see if there are there’s best practice we can take from it and share with the rest of the community.

    • Guest

      Hi John!

      We were initially going to go with KissMetrics until I saw your comment, as we had a demo with Looker recently.

      Would you be open for a quick chat? I’d like to understand your experience with Mixpanel and how now it works with Snowplow.

      Please let me know! Thanks a ton

      Fab

      • InstaPage

        Do not go with KissMetrics. We used this for over a year and Mixpanel beats it in almost every way.

        • http://www.cloud66.com Philip Kallberg

          We’re looking at KissMetrics vs. Mixpanel at the moment – it’d be really useful if you could expand on these thoughts! I haven’t used them a lot but they look quite similar.

          • http://www.instapage.com/ Instapage

            Mixpanel is extremely straightforward and easy to use while still allowing you to do very custom things (like setting up super properties to see how small changes affect anything from video plays to upgrade rates). You can choose super targeted events that trigger email notifications to the users that meet that criteria only.

            Bottom line is, they are both very similar tools, however mixpanel is way easier to use. This allows you to more quickly and effectively reveal actionable data.

  • tommytcchan

    Great article Matt. I agree that server side is the way to go if you want to provide more control. Here at VenueSpot we track everything using the client side API before they sign up/login, and then we switch to the server side API afterwards. We link the two account using the alias method.