Safari ‘Top Sites’ Pollutes Google Analytics and Mixpanel

If you are the creator of a website or web application yourself, you might want to install the rack-preview gem for Ruby, or something similar. We discovered Safari Top Sites was polluting Splitwise’s Google Analytics and Mixpanel data.

A couple of weeks ago, while digging into our site analytics, we noticed something strange with Safari. We’d just launched Fat Rabbit and were really interested in making sure we measured all the useful  statistics around user growth and engagement. As we pulled out interesting details about website visits (using a combination of Google Analytics and Mixpanel), we started seeing an odd pattern – the average visit length on Safari was half that of our other browsers and the bounce rate was much higher.

Our first assumption was that we had released Fat Rabbit with some Safari specific rendering issues that were causing people to be, like, “Ew!” and abandon all hope of finding a great way to split expenses with their friends. Thankfully, that wasn’t the case. Our next guess was that it might be Google / Mixpanel lumping mobile Safari and desktop Safari traffic together. Nope, not that either.

We were at a loss. So, like any good engineering team we started Googling. It took us a while, but we finally found a post by Martin Sutherland that explained what we were seeing. Safari’s Top Site feature makes a request to all the sites it lists to accurately render their respective thumbnail. These requests show up as Safari traffic and are full page requests, including executing any Javascript on the page (that is, our analytics code). We were able to implement a fix that allowed us to filter these Top Sites requests out of our analytics reporting. It only took a few days of data to prove that Safari Top Sites had actually been causing the odd behavior.

So, how’d we fix it? We were happy to find the wonderful rack-preview gem. The gem allows us to ignore the Safari Top Sites requests for analytics purposes, but still serve up great content to be previewed.

If using Ruby gems isn’t your thing, all you have to do is look for the “X-purpose” HTTP header. If its value is “preview,” it’s a Top Sites request and you should treat it appropriately. Of course, you’ll still want to serve up a normal-looking version of your page so Top Sites users get a nice version.