Downtime today and tracking changes

Around 12pm PST, Clicky was 100% offline for about 30 minutes. This means there is a bit of missing data from everyone's stats today.

So what happened? Network activity was much higher than normal, enough to overload our load balancers and cause them to crash. Before that happened, we did notice the site seeming to get slower and slower over a few hours leading up to the crash, and load on our tracking servers (behind the load balancers) was almost twice what it normally is. We initially thought we may have been under attack because the network traffic was so much higher than normal, but this does not appear to be the case.

Someone on Twitter suggested it may be related to increased activity due to so called "Cyber Monday", a shopping holiday invented by the retail industry in 2005 to get you to spend more money. This seems plausible, however I would expect most of the extra browsing on the internet in general today to be on major site's like Amazon - sites that are way too big for us to track so we probably wouldn't be affected by it, in other words.

A similar thing happened back in April when we first added "pinging" support to our tracking code. Pinging is what lets us determine much more accurately than most services your bounce rate and time-on-site values, because our tracking code continually talks to our servers while a visitor sits on one page. Back then, we rolled out this feature over the weekend, but then when Monday rolled around, the extra spike in traffic from these pings was so high that the same thing happened - load balancers went boom. We were pinging too agressively, it seemed. Some quick detective work showed that the pings were accounting for 80% of the traffic we were now logging - a 400% increase, in other words, basically overnight. This was quite a bit higher than we had anticipated, so we made some changes to the code to basically cut in half how many pings our code sends - they now only account for about about 50% of our total incoming "hits".

The point is, making this changed saved our skin then, and today it has done the same thing. After we crashed, we quickly updated the tracking code to disable pinging and threw it on the CDN. Within minutes, the load balancers were happily chugging along again. This does mean for the time being, your bounce rate and time-on-site values will be back to non-awesome mode, but if it's a choice between that and Clicky offline, we choose the former.

This change is only temporary though. We're evaluating how to make it more efficient. One complaint people had when we first released the new pinging is that lots of people open tabs in the background and leave them there for a long time before actually viewing the page. So not only does this make your time-on-site values perhaps higher than they should be, it also leads to increased load on our end to track all these excess pings.

So right now, for our own stats, we're testing a new version of the tracking code that only starts tracking a page view and hence starts pinging when one of the following events occurs:
  • Mouse movement
  • Key press
  • Page scroll
  • Page coming into focus (when a tab is loaded in the background then displayed later, this will fire)

We think monitoring for these events before logging a page view and starting the pinging will lead to much more accurate traffic data, and quite a bit less load on our end. There may be some odd cases where none of the aforementioned events occur on a "valid" page view, but we'd guess they account for less than 1% of your traffic. Of course, if anyone has feedback or ideas on other events we should be listening for, we're all ears.

Ideally we'd always log a page view immediately when it is loaded "in focus" but Javascript does not provide a way to check the current focus status - only to detect events when the focus changes. This is an extremely frustrating limitation but we must live with it.


It turns out there is a new method with HTML5, document.hasFocus(), which is a way to determine on demand whether the current document is in focus. It is not yet supported in Opera, and Chrome always returns "true" even when it shouldn't (bug filed), but Firefox 3+, IE7+, and Safari 5 (at least, haven't tested in Safari 4) all support it properly. The test tracking code we are running on our blog and on has been updated to use this new method instead of relying on other events (mouse movement etc).

Relying on events led to about a 5% drop in visitors being tracked, so we knew this wouldn't work. Somehow, we discovered the hasFocus() method, which has VERY little discussion online. Most people must not know about it yet. But anyways, this is what our new test code does:

  • If the browser supports document.hasFocus()...
    • If the current document has focus at the time the tracking code is executed, a page view is logged immediately and pinging starts. (Since Chrome has a bug where this method always returns true even when it shouldn't, Chrome users will always be logged immediately. All other modern browsers, except Opera, will work properly).
    • If the current document does NOT have focus, we setup an event listener to wait for the "onfocus" event to fire, at which point the page view is logged and pinging starts. This will apply to anyone who opens a page on your site in a background tab or window - we won't log their visit until they actually start viewing your page. This will help alleviate the extra load of "pings" on our end, and will result in more accurate usage data of your web site since we won't log a visitor until they are actually viewing your web site.

  • If the browser does NOT support document.hasFocus()... (currently only Opera, and old, outdated browsers)
    • Page view is logged immediately
    • Pinging starts immediately
    • (This is the way it used to work by default anyways)

We think this way of doing things will work great, and if all goes well from our testing, we will deploy it to our CDN and it will become the new default tracking code.

By the way, pinging is still disabled in our public tracking code. Once this new code is tested and deployed, pinging still start again, and your bounce / time-on-site values will return to their normal state.
29 comments |   Nov 29 2010 6:10pm

ClickyTouch for iPhone

Steve Reynolds has spent the last few weeks developing a native iPhone application called ClickyTouch. It looks pretty dang slick and you can download it right here. Steve's description of the app:

Keep up to date throughout every view of your stats, with self refreshing data such as active users on your site, your bounce rate, average session time and overall comparison percentage versus this time yesterday. In as many cases as possible, data refreshes whilst you look at it! No refresh buttons here!

View the following data in a simple, beautiful summary screen:

Live Active Visitors, Bounce Rates, Time Average, Overall Visitors, Actions, Searches, Bookmarks, Links, Social Media, Goals and Campaigns

We use Android phones at Clicky so we haven't gotten a chance to play with it ourselves, but the beta testers we've seen talking about it on Twitter have all been quite enthusiastic. Let us know what you think.

Update: This is a third party app, not commissioned by Clicky. Hence, Steve is asking a reasonable fee of $2.99 USD for the app. However, all users are able to use it, whether they have a premium account with Clicky or not. Also, the app does ask for your username and password to automatically download and keep up-to-date the sites in your account. One user mentioned they don't want to share that information with a third party app, however we assure you that Steve is completely legit and is not the type of person who would do something evil with that information. He has been a very long time user of Clicky and just wants to spread the love!

49 comments |   Nov 05 2010 9:13am

Updates to the new Clicky

  • "Small site" mode is back. If your browser window is less than ~1100px wide, then the sidebar flips back to the top, kind of like the old Clicky, but a bit more space efficient because there are more tabs.
  • Those of you with more than about 20 sites, the site selection menu now tiles to the right so you can see more than the first 20. This has been a huge request that we didn't consider originally because we don't track that many sites ourselves.
  • The clock is back! In the top right corner. It's part of the "stats header" element though, which is not shown in "small site" mode to save space.
  • "Small site" Spy users - visitors online value is now shown again. That was a silly oversight.
  • Wordpress plugin - when viewing stats from your WP admin area, the layout was messed up because of the sidebar which we were hiding. Now that "small site" mode is back, however, it should work correctly again.
  • There were a few minor bugs with Ajax forms that have been fixed, and lots of other minor bug fixes.

Before bringing "small site" mode back (we disabled it right after official new Clicky release because of serious bugginess), we asked you to help us test the new code on No one reported any bugs with it so it should be good now!

Note that you may need to force refresh your browser window to get these changes.

We are planning one more fix later today - making the navigation tabs auto-update to the proper state when you click "back" or click a link that brings you to another page that should have another tab highlighted instead.
22 comments |   Oct 28 2010 1:38pm

Drop what you're doing and help us test!

When we originally released the new Clicky a few weeks ago, we had programmed in support for detecting small screens (1024 or less) and moving the sidebar to the top instead, so that you don't have to scroll sideways. However, there was apparently a serious bug with it and some of you were getting this forced small screen mode even if your browser window was large and in charge.

Well, we think we finally fixed it. However, since we never saw the bug in action ourselves, we need you to help us test this change before making it live. To help test, please visit and tell us if you see it (by leaving a comment here). Don't just test once though - after you login and view a few reports, completely close your browser and re-open it and see if it continues to happen. Maybe try making your browser window small so "small site" mode goes into action, then close that tab, make your screen full size again, then re-open We think that may have been part of the problem, the screen size wasn't being checked properly if next time you viewed the site it was small instead of large or vice versa.

Thanks for your help and in particular if you were one of the ones experiencing this problem with the initial release, your feedback is appreciated!

UPDATE: To clarify, we know that it always works if your browser window is actually small. What we're looking for here is to make sure that the code does not mistakenly put you into "small site" mode when your browser is at least 1100px wide.

UPDATE: Test is over! All seems well. Thanks for your help!
33 comments |   Oct 27 2010 4:02pm

Google ad clicks and ajax searches

Out of nowhere, everyone has been clambering for us to add support for referrers. Something must have changed on Google's end recently because these didn't used to be that common but they are now. Many people have told us that the original search is included in the referrer string and sent us examples. So we finally just added support for this. However, based on our limited testing, when clicking on ads on we don't see the "q" variable (that contains the search) in the string. So, we're guessing it's only there sometimes. What would cause it to be there or not is beyond us. Anyways, if the "q" variable is there, the search will now be displayed, and either way, the visitor will always be classified as "advertising" now.

Also, a few months ago, we wrote a post about Google and Ajax searches. We said when we saw these referrers we were just going to ignore them, because otherwise they showed up as normal "links" from and that was causing confusion - but you all hated that idea, so we disabled it. We've just updated it now so that it will no longer show up in your links report, and the visitor will be classified as a "search" in traffic sources. And the referrer will be manually changed to "" with no query in your visitors report. We wanted to add some link to click on to explain why the search was blank but decided against that.

And finally, we're frantically working to fix some outstanding bugs with the new Clicky that we were unable to fix last week because of travel plans, including the "small site" bug. We'll keep you updated.

Update: Some of you may see some [unknown] searches from Google. This was a bug when we first uploaded the new code but was fixed within about 20 minutes.
11 comments |   Oct 27 2010 12:39pm

Next Page »

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