'GetClicky' no more!

You may have noticed that we're now live on clicky.com! Yay!

For 6 years, our brand has always been "Clicky". Excluding our domain name, nowhere on our site has the brand "GetClicky" ever been mentioned, other than some testimonials that we didn't edit. However, because of the old domain name, the majority people have always referred to us as "GetClicky". It didn't help that our Twitter handle was also @getclicky, but we wanted it to match our domain name (bad idea). It's always kind of driven us insane, but it's been an interesting lesson. If you can afford the right domain name, do yourself a favor and buy it as soon as possible. We paid a pretty freaking penny for clicky.com, but the second it was in our possession was just pure unadulterated joy.

We've had the @clicky Twitter handle from the beginning, but it was just a placeholder. We've now swapped @getclicky with @clicky so all of our followers and tweet history remains in place. Fun fact, Twitter does not offer an official method to do this - you have to actually relinquish your brand for a brief few seconds while you swap things around, which is extremely nerve racking to say the least. So @clicky became @clickyx, @getclicky became @clicky, and last @clickyx became @getclicky. Scary 20 seconds or so. Anyways, please note: If you tweet at us in the future, use @clicky, not @getclicky! But if you were already following us you will keep getting our tweets without having to do anything.

Any page viewed on getclicky.com is now redirected to clicky.com, with a little note at the top about updating your bookmarks. That note will go away in a few weeks, but for now we want as many people to notice the change as possible.

You do NOT need to update your tracking code, because getclicky.com isn't going anywhere. Your existing tracking code, along with any integrations you have with the API, widgets, or whatever via getclicky.com, all will continue to work. Going forward, getclicky.com will only be seen in the tracking code (we are using it indefinitely for tracking). And we'll continue to use it for email, for now at least, since that's a nightmare to change. So... clicky.com = web site domain, getclicky.com = tracking domain, email, and indefinite backwards compatibility.

This was not as easy as just acquiring clicky.com and pointing it to a new IP address. A service of our size and complexity, there's a LOT of things to deal with when changing your domain name. My checklist is ridiculous in length and I hope to go into it more in a later blog post.

There may be a few bugs lying around... we'll squash them tomorrow as they come to our attention.
32 comments |   Dec 19 2012 12:34am

On-site analytics update

Just pushed a much needed tracking update for sub-user accounts, so now they can use on-site analytics, and their traffic will now also be automatically ignored.

Previously this was not possible because of the way our tracking servers were caching information about each site in memcached. After banging heads on keyboards for a while, we finally figured out a way to do it (it's more complicated than it sounds). So, now sub-users will have their traffic ignored automatically, and they will see the on-site analytics widget.

One caveat - the master account's preference for disabling on-site analytics on an account wide basis will override a sub-user's preference.

Making this change also addresses a bug that popped up after the four-week heatmap trial ended a few days ago. All sub-user accounts are created as "Pro", since Pro has always had access to every feature, and a Pro account was required to have sub-user accounts. But now that heatmaps require Pro Plus or higher, heatmap tracking broke for some of you if you had created another sub-user account and assigned them admin access to a site in your account. Their account features were overriding yours on the tracking servers for the sites they had admin access to. So this update fixes that. But we went ahead anyways and made sub-users account types mirror the master accounts - any time the master account type changes, the sub-users are updated accordingly, to address any future updates that might cause this scenario to come up again.
2 comments |   Nov 16 2012 2pm

Update on heatmaps

Heatmaps launched four weeks ago. As we said in that post, everyone would have it for four weeks, but then we would be requiring a Pro Platinum account to continue usage after that point. The reason for this is because the extra bandwidth and storage requirements for this data are significant, which has proven to be the case as we've monitored resource consumption since launch.

After listening to your feedback, we've decided to add a new plan (Pro Plus) with pricing in between Pro and Pro Platinum. It is the exact same as standard Pro, except that it includes heatmaps.

As of now, these changes are live. So if you are the standard Pro plan, you will need to upgrade to at least Pro Plus in order to keep heatmap tracking going forward.

Note to white label account holders: We've had a few of you ask about heatmaps for white label, we are including this feature with all account levels.
12 comments |   Nov 12 2012 2:28pm

Please do not place third party javascript in your HTML head.

There were a few bugs with our new heatmaps for people who were putting our tracking code in their HTML head tag, and there were an alarmingly large number of you doing so. Those bugs are fixed now, but that's beside the point of this little post.

Web browsers download page elements in the order that they are listed in your HTML - CSS, javascript, and images (mostly). If the domain that any of those are hosted on is offline or going slow, a web browser will "hang" for up to 60 seconds while it waits for the item to load, before moving on to the next item. (Asynchronous javascript is an exception but that's still not very common - although we do offer it an option - but again, that's not the point. And besides, if you're loading it asynchronously, you're not depending on it being available for immediate execution, so what would be the point of putting it in your HTML head?).

If you have third party javascript in your HTML head and that third party server goes offline, your web site is effectively dead because nothing else is going to load for up to 60 seconds. When I visit sites that hang like that, I immediately close them as I'm sure 99% of people do.

If the javascript was instead in the footer of your web site, the web browser would still hang trying to download the item, but most of your site would already be loaded in the visitor's web browser. In other words, your site would still be (mostly) usable while the engineers for the third party service go into panic mode.

Our CDN never really goes "offline" but there are obviously thousands of services out there that ask you to put their javascript on your web site. Any third party javascript code that's not critical to your web site working properly should never go in the HTML head. Tracking code, ad code, widgets, social plugins, etc - these are all non-critical and have no business up there. Help make the internet a better place and always put that code at the bottom of your web site, k?

The only valid exception here is if it's hosted by a major provider such as Google, and you rely on the functionality of that code as the page loads (which we do for Google's map API, but that's it). That is the only exception.

So... if you've got our code in your HTML head, please move it instead to the bottom of your HTML, right before the closing /body tag, as has always been recommended on the page where you grab your tracking code from.

Bonus pro-tip: For first party elements, your CSS file should always be the very first item in your HTML head. That way your site will always look "proper" as soon as possible, beacuse this will be the very first thing the browser downloads after the HTML itself.
3 comments |   Oct 17 2012 4:25pm


We've got two great new features launching today, after nearly 4 months of development: heatmaps, and on-site analytics.

Here's an example of a heatmap report, after the new tracking code has been live on our site for a couple of hours:

(Note: Everyone's user homepage is unique so some of the hot spots look weird here when conglomerated on a global scale. That's the nature of dynamic pages).

IMPORTANT! Heatmaps won't start logging anything until you specify your site's width and layout in your site preferences. You can see where to do that in this screenshot. And as with on-site analytics, you must have the newest tracking code in your browser, so clear your cache!

Over the years we've had a lot of requests for this feature and we're psyched to finally offer it to you. But once we started on it, the idea for on-site analytics was born soon thereafter, making this otherwise fairly-simple feature spiral out of control (in a good way). Hence nearly 4 months of development and testing!

Most services, to view heatmaps, you go to their site (e.g. getclicky.com) and go to your heatmap report, click a button for the page you want to view heatmaps for, and then your site is opened in an iframe, and then a heatmap overlay is loaded on top. That's unideal for a lot of reasons, but particularly the iframe (ugh). Loading a site in an iframe introduces a lot of potential problems, and a lot of sites have "frame busters" that would totally break this feature. So we took a different approach.

Ok, we won't deny you the "boring" way, going to your reports and clicking the appropriate link in the Content report:

What we do differently is that your page loads directly in a new window with a special parameter in the URL fragment, that our tracking code recognizes and automatically loads a heatmap dynamically on your site - without a frame, and without requiring being logged in to Clicky (i.e. you can share the URL). So that's good.

But we thought it would be so terrific if you could just be on your web site and say "I want a heatmap of this page, now" and just click a button on that page and see it immediately. So that's what we did, and hence made it part of the on-site analytics experience, as you can see to the right.

This was still not enough for us. Even though very few of our real-time competitors offer heatmaps, we didn't want to just make a "me too" feature. We believe most of the features we are releasing with our heatmaps are unlike anything that any other service offers.

First of all, beyond "per page" heatmaps, we also do "per session". For every single page view of every session we log for your site, we log a unique heatmap for that visitor. You can view session heatmaps by viewing a session, and next to each action, on the right-hand side, will be a heatmap icon to click if we have any heatmap data for that page/session combo. Click the icon to view all of their clicks on any given page:

Second, what would be analytics without segmentation? You can view "global" heatmaps (all clicks) for any page, or you segment them by a number of criteria. For example, only view clicks on a page for people who completed a specific goal, or only people who arrived via a specific search or campaign or referring domain or type of referrer (e.g. advertising), or any/every version of every split test you're running.

Here's an example of our homepage for users completing the "new user" goal. Unsurprising, the majority of the clicks are on the "register now" button:

The order of items in these reports is a bit different than what you see on our web site. We take the top 24 items ordered by "popularity", e.g. the top 24 goals completed today, then re-order them alphabetically. This is because we think you'll generally want to see the most popular segments but you'll also want to find them quickly - so instead of showing them in order of popularity, we grab the top ones and re-order them alphabetically so you can quickly narrow down what you're looking for in the interface.

To generate segmented heatmaps, we needed to add a new filter type to quickly find visitors with heatmap data attached. So we made this a general filter as well. In the main visitors report on Clicky, when you click "add a filter", you will see a new option callled "heatmaps". Click that to filter down your visitors to just people with heatmap data attached. This also works with the analytics API, by specifying "heatmap=1" in combination with type=visitors or type=segmentation requests. (We also added a filter for "online now", since we needed to be able to internally filter visitors who were online now in order to display in the widget. Via the API, use "online=1").

When viewing your visitors report, anyone with heatmap data attached will have a new icon next to them:

Not every visitor will have heatmap data though... We anticipate this type of data to take up a lot of space, so for now we only do it for a random 50% of your visitors. We will likely adjust this in the future as we see what kind of impact it has on our resources. For example, it is quite likely we'll increase the sampling rate for low traffic sites, maybe even do "all visitors", and for higher traffic sites, do less than 50%. But for now, just doing 50% was an easy safety measure and we'll analyze resource impact as time goes on.

Most heatmaps use server-side image generation to overlay on your site, which takes up a lot of resources on the service providing the heatmap - and is also quite slow. Earlier this year we discovered the excellent open-source heatmaps.js by Patrick Wied, and we knew that was just what we needed. This is a javascript library that generates the heatmap on the fly, using your web browser's resources, so it's fast and efficient. There are lots of features this library has that aren't yet documented, some of which we wanted to use (animated heatmaps for example) - but we didn't want to take the time to figure them out ourselves. We hope this library matures in the future and we'll take advantage of it when it does. But for now, for what we need, it does the job extremely well.

A difficult decision

This will be the first feature we offer that is not included in the standard Pro plan. The Pro plan has always had every feature we offer, so this was hard to do. But, the resources needed for this feature are quite significant, both in terms of bandwidth and storage, so we can't justify the standard Pro pricing for this feature.

We do want all of you to experience it first hand though, so for the first 4 weeks, all Pro or higher accounts will have this feature. After 4 weeks, a Pro Platinum or Custom plan will be required to keep the heatmap feature. On-site analytics will be standard with any Pro or higher account, though.

Data retention

As we said above, we anticipate this taking up a lot of storage space, so we built the database structure around monthly chunks that are auto-purged every 30 days. Initially, daily/session data will only be guaranteed for 30 days, but be available up to 60 days, and monthly data will only be guaranteed for 2 months, but available up to 3 months. It's hard to anticipate the exact impact this will have on our resources so we may (and hope to) expand this limit in the future, but for now, this is all we can guarantee.

Internet Explorer, may I count the ways in which I love thee?

Prior to IE8, IE does not have native JSON support, and even then, only when your site runs in standards mode. IE causing developers headaches is as sure as the sun rising in the east, regardless, the point is that IE users will not have heatmap data logged unless they are on at least version 8 and your site renders in standards mode. Good luck!
49 comments |   Oct 14 2012 8:51pm

Next Page »

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