My first week at Mixpanel, or how I didn’t take down the Internet

During my first week at Mixpanel I was asked to design, implement and deploy a highly requested feature in our core javascript library.  I had just started as the new intern and I hit the ground running.  Our customers wanted a simple method to track link clicks without having to hassle with browser incompatibilities or fiddle with event models.  The new functionality would also lay the groundwork for future enhancements such as form integration.  I got to work right away.

The Design Process

When designing a new feature like this, I aim to create a simple interface.  I started the process by analyzing how a user currently implemented link tracking. The recommended pattern was the following:

This pattern has a couple of problems:

  1. It requires that the user knows to call preventDefault() on the event object
  2. It requires a selection library to be installed, in addition to our library
  3. It increases the time required to integrate with our library, and confuses some users

Next, I wrote up what I wanted the new interface to be:

I was careful to consider different ways a user might want to hook up link tracking, while also ensuring that we didn’t bloat the javascript with too many features.  Because of our goal to have a slim library, I evaluated the cost of each additional feature to determine how to get the most functionality from the least amount of code.

One major design choice was to not include a full featured dom querying library.  This choice meant that the interface would only be able to select by a single class/id without the help of jQuery/other selector engine.  To help me make this decision, I considered embedding a number of selection engines including SizzleJS, Qwery and the Essential Selector Library.  I then worked out the code required to implement a super simple selection engine (only selects by single class or single id):

Based on the minimal amount of code required to implement our own simple selection library, I decided to go that route and allow users to pass in jQuery objects if they wanted to select something more complex.



When writing code for a javascript library that is distributed across thousands of websites, cross-browser support is paramount.  Because of this I had to make a second major decision: how I would handle the click event.  After looking at event models in various browsers I decided to go with the traditional model.  The primary reason behind this conclusion is that it is supported across every browser that I tested against.  A very useful resource to use when dealing with the various javascript event models is the Introduction to Events chapter on

To implement the actual mpmetrics.track_links() method I wrote an argument based router.  The idea was to catch errors as early as possible, and fail gracefully.  The router parses the arguments variable, and proxies the arguments to one of two functions based on the first argument.  Javascript makes this pattern very elegant with language features such as apply().

Another way our library fails gracefully is by ensuring that we wait only 300 ms for the Mixpanel servers to respond.  In this way our user’s sites stay responsive even if our servers are having problems.  I chose 300 ms based on a browser benchmark I wrote to evaluate the response time for the mpmetrics.track() method.


101 Big Ones

Part of writing a new feature for a core library is testing.  This part is always tedious, but a necessary evil in the world of software development.  To ensure that the new features I added weren’t going to destroy the Internet I doubled the number of tests in our suite to a healthy 101.  Although this may seem drastic for a single feature, it was important to test the many new tricks I added to our library.  QUnit, our javascript testing framework of choice, provides a no-hassle solution to writing lots of tests and quickly debugging any errors that come up.  Using modules you can further refine your test suite with full support for setting up and tearing down the DOM environment.


101 tests passed


Go Time.

After a final code review with our lead front-end engineer, Tim Trefren, it was time to deploy.  Seconds after our deploy scripts finished, thousands of browsers around the world downloaded and ran my code, no Internet apocalypse in sight.  I never imagined that I would be pushing something of this magnitude out in my first week, let alone as an intern.  Mixpanel has welcomed me as a core member of the team from day one, putting just as much trust on me as everyone else.  I know that every day I come into the office I will be making a difference rather than just fixing bugs and writing tests.  For a rewarding internship contact me and help us change the world of analytics.

“Enjoy the little things, for one day you may look back and realize they were the big things.”
~Robert Brault

2 thoughts on “My first week at Mixpanel, or how I didn’t take down the Internet

  1. Great post!

    Is there a way to guarantee the tracking of the link with the asynchronous version of MixPanel? (i.e. mpq instead of mpmetrics)

  2. Is the click handler using event delegation? Seems like it would have been easier and more efficient to match the clicked element via conditional rather than trying to find the elements and apply click handlers to each.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.