Facebook referrers update

A request we've had quite a bit is to show the actual page that a visitor has come from on Facebook. It's not that we were trying to hide it in the first place, it just didn't show anything beyond facebook.com. We decided to dig into this further today.

When you post a link on Facebook, whether it's in your feed or on a fan page, Facebook makes that link go through a redirect script first. There are several good reasons for this that I can think of that benefit both Facebook users and Facebook Inc., but we don't need to get into that right now. All that matters is any link that someone clicks on Facebook to an external site goes through their redirect script first.

Browsers normally keep referrers intact through redirects, but Facebook is doing something different. They are using Javascript to call document.location.replace() to send you on your merry way. This method works the same as if this intermediate page instead had a link to click on, and that link sent you to the external page: the end result being that this intermediate page "becomes" the referrer.

Out of curiosity, I wondered if you had Javascript disabled, since this intermediate page appeared to only use Javascript and no other method of redirect. Well, turns out with Javascript disabled, the links on Facebook actually point directly to the third party page. But... sigh... without Javascript, Clicky can't access the referrer at all.

So I hate to be the bearer of bad news, but it looks like what we have now for Facebook referrers is the best we're going to get. If you know of an analytics service that through some minor miracle actually gives you referrer data from profiles or fan pages, let us know, but I'm pretty sure it's impossible. Sorry!
8 comments |   May 20 2011 10:19am

The user experience and psychology of color [FIXED]

One of my most favorite articles ever written about Clicky is this one, which might seem entertaining at first glance, because it's basically ripping us a new one for a design decision I made almost 7 years ago (pre-Clicky) and that I have stuck with ever since. What decision is that? That whenever I want my software to give you any kind of feedback, whether good or bad, that it will be displayed in SKULL-MELTING BOLD RED.

Now of course, I know that people associate red with bad. For example, "You totally forgot to fill out a field! Nice going!". But I make web sites for a living, and while I consider my attention to detail to be off the charts, I have caught myself missing "messages" all the time that random web site X is trying to share with me, because the message doesn't BURN MY RETINA.

So what about Joe Sixpack? How many of these "messages" is he missing? Considering my background, I would guess he misses a lot more of them than me. And since these tend to be "important" things, the fewer he sees of them, the more confused he's going to be. And what does confusion lead to? Tech support! Now don't get me wrong... of course I'm absolutely not saying anything negative about anyone who emails us for support. But, the fewer emails we get, the more time we get to spend writing code, which is the ultimate dream of any software business. That's where the fun is!

So that's been my philosophy. It may not be right, but I wanted you to know the reasoning behind it. As we continue to grow, however, the amount of "#UI #FAIL" tweets and emails we get has increased substantially, and it has started to bother me. But the real tipping point... yes, the real tipping point was today, when one of our new developers, Alexander, was playing with his local install of Clicky, and he did something that trigged a "success" message that subsequently melted his skull. He said, "Success messages are red?". I gave him the spiel. He understood, but he emphasized how much his mood was spoiled. He was truly upset that Clicky was essentially yelling at him while at the same time it was congratulating him for successfully filling out a form.

I felt bad. I almost let him go home early! But then I decided enough is enough... it was time to fix this. So I spent the last 4 hours or so doing just that. This is the result (screenshot below). And based on the comments in the article I linked above, I took the time to make it color-blind friendly (using blue instead of green for "good" messages). There are still some areas of our site where I use red to make something stand out, e.g. a specific sentence in the middle of a paragraph in our help documentation, but otherwise you should find Clicky a much friendlier companion.

15 comments |   May 18 2011 10:17pm

User homepage totals

We've added a much requested feature to the user homepage: a row at the bottom summarizing your total numbers across all of your sites. This can add a bit of loading time to your user homepage though if you have a lot of sites registered, since it's showing today, yesterday, and the last 7 days. So if you don't need this feature and you feel this page loads too slow, you can disable it on your user home customization page.

Example screenshot is below of what this looks like. (For you mathematicians out there, the numbers don't add up because this is just a snippet of the top and bottom of my home page.) I also wanted to point out that the bounce rate is a weighted average, instead of just sumOfBounces/numberOfSites. Enjoy!

Update May 19: Due to popular demand, we changed it so this on top by default, instead of the bottom. If you want it on bottom instead, we added a new preference to put it down there, on your user prefs page. You can also turn it off entirely, as you could before, if you don't want it at all.

10 comments |   May 18 2011 3:17pm

Tracking code updates

A highly requested feature has been to be able to view the /stats/ page for all of your sites at once (e.g. sum them up), or to officially support multiple tracking codes on one site (which doubles the amount of traffic you log, but lets you have a "master" site_id that logs all traffic for all of your sites).

The former option is more appealing to us for bandwidth and storage reasons, but the latter is easier to do because it only involves changes to a single file instead of a huge rewrite of the internal code. Using multiple tracking codes did already work to some degree, but there were a lot of bugs because it was not originally designed to work like that.

Well, no more! Alexander, one of our new developers, undertook as his first project a fairly major rewrite of the tracking code to officially support having multiple copies on a single page. I would however like to reiterate that we don't really like supporting this, because it doubles storage and bandwidth requirements on our end for your account - but, we know this is important to a lot of you so here it is. Do keep in mind that if you do this, you may need to upgrade your account to a higher level to support the additional traffic you'll be logging.

The code has also been updated to allow for dynamic clicky_custom updates. This is mainly of importance for those of you doing fancy things with Javascript, but if it affected you, you will appreciate this. Previously, once a page was loaded, clicky_custom was "static" - any updates you made to it dynamically (e.g. if you refresh a page via Ajax) would not be reflected in future calls to our tracking servers until the page was fully reloaded. But now the code checks the current status of clicky_custom for every single request, so if anything has updated since the last full page refresh, that new data will be sent along to us. This probably only affected a few hundred of you at the most, but one of those who was affected was myself, and it was driving me mad. Being a customer of my own business has its benefits.

One last thing. If you're currently using the asynchronous tracking code, we have made some minor (but important) changes to the format of the code that you paste onto your site. If you are planning to use multiple asynchronous codes on a single page, you'll need to update to use the new format that you paste onto your site. Otherwise, you can leave the code as is.
6 comments |   May 13 2011 11:53am

HTTPS support for all of Clicky

Clicky has always had HTTPS support on the login and credit card pages (and of course for the tracking code on your site), but otherwise we weren't allowing it. You may be thinking we were trying to save on performance, but that's not the case - our load balancers have hardware HTTPS decoding so the penalty is negligible. No, the one major reason was because of Google.

The Google Maps javascript API that we were using (version 2) did not allow HTTPS without an enterprise account for the low low price of just $10,000/year. Including insecure items on a secure page isn't a big deal of course... unless you're an IE user, and 13% of our users are on IE. So it is in fact a big deal. We could always just exclude that feature for them, or only include it on the pages that require it, but those felt like cheap hacks. I wanted proper support for it.

One of the good things about working with other developers is they can tell you things you don't know! We just hired three new developers, and I've been learning all sorts of amazing things from them. For example, just today, Mike told me that Google Maps API was now on version 3, and one of the amazing new features was full HTTPS support for no cost - not to mention no more API keys! How did I not know about this?!

So, I spent the last few hours converting our code to their new API, and now we have proper HTTPS for all of Clicky. We do require a Pro or higher account for this, but if you have one, your connection to our web site is now fully encrypted!

The last 6 weeks we've spent opening an office, interviewing a bunch of people, hiring three of them, and getting everyone up to speed on how Clicky works. This has been completely overwhelming, but we're finally past all that and the future is looking bright. We went from just one developer, to four, so you can expect things to start moving a lot faster. Each one of them is already working on some great new features, all of which have been requested a million times and I can't wait to get them into your hands.

I'll write more about them and show off our new digs in a future post, but now, back to work!

Update May 19: We added a preference to disable this in your user preferences, if you don't want it or it's causing problems (e.g. firewall not allowing port 443). It's on by default for all Pro+ users otherwise, though.
13 comments |   May 11 2011 5:56pm

Next Page »

Copyright © 2018, Roxr Software Ltd     Blog home   |   Clicky home   |   RSS