Analytics Expert Blog

There’s been an authentication bug with the on-site analytics widget (OSA) for about a year. It only affected a small number of customers, so it was hard to track down. This was not a security bug, but rather, OSA would just simply not display for a small number of people.

While mucking around with heatmap updates earlier this week, I was also updating some of the OSA code and a lightbulb went off in my dang head as to the cause.

Here’s how OSA works. When you login to Clicky, a cookie is set for in.getclicky.com, which is our tracking domain. This cookie is used for authentication purposes. When you visit your own web site, the tracking code tracks your visit and sends that info to in.getclicky.com. If that cookie is set, then we check if it matches the owner of that site ID on our end. If so, then we call some code to display the OSA widget (and at the same time automatically ignore your own visit).

OSA was released when our domain was still getclicky.com. So at that time, browsers considered the cookie to be first party cookie because it was a sub-domain of the site you were already on. Life was good.

Two months after OSA was released, we acquired clicky.com. But we left *.getclicky.com as our tracking domains, so people wouldn’t have to change their tracking code and everything could just be transparent.

This change meant that setting a cookie for in.getclicky.com when logged on to clicky.com was now a third party cookie as far as browsers were concerned. So when we started getting emails about OSA not working, we assumed that the cause was third party cookies were disabled in their browser. And in lots of cases, this was the cause. But there were a few people who, no matter what they did, could not get the widget to work.

So that lightbulb I was talking about earlier… when in.getclicky.com tells our tracking code to execute the OSA widget, the widget is loaded from clicky.com, not in.getclicky.com. We hadn’t made any major updates to heatmaps or the widget since the domain change, until earlier this week when I was messing with that code, so I hadn’t really dived into that block of code for a while. Sure, I had looked at the code since it was written, but you can’t really get into the zen with existing code until you start playing with it.

The problem was that the third party cookie would authenticate you on the tracking domain, but unless you had checked the remember me box when logging in to clicky.com, you had no authentication to load the OSA widget from clicky.com, so it would just exit out. Most people use the remember me option so that’s why this only affected a small number of people.

What we’ve done is now when your beacon (with proper cookie) is sent to in.getclicky.com, before calling the OSA widget, we tell the tracking code what your sitekey is. The sitekey is used to authenticate requests with the API and other things. So now when OSA tries to load by sending a request to clicky.com for the data, it’s authenticated with the sitekey.

I’m always 100% of the time logged in to clicky.com with the remember me option set. Once I discovered this issue, I logged out and sure enough, OSA would not load for me anymore when I was on clicky.com, even though my cookie for in.getclicky.com was still set. Now after making this change, whaddaya know… It works! And it should work for you too if this was affecting you!