Posts Tagged ‘tracking code’
Cookies and pinging support coming soon to our tracking code
We’re working on another update to our tracking code that’s going to add two much needed features: cookies, and pinging support. We have to make some backend changes also to support this, so we expect it to be about 2 weeks before it’s ready. Here’s what these features will do for us:
Mmm… cookie
Cookies will let us track unique visitors more accurately. Currently we just do this based on IP address, which works well most of the time. But if you have a bunch of people all behind the same router all accessing the same site at the same time, Clicky currently sees this as one visitor. This is rarely a problem for most of you, but some of you have sites that are accessed mainly by intranets, so it’s more of an issue. Cookies will also let us finally track new vs returning visitors.
Cookies will be enabled by default. Most of you couldn’t care less, but we do have some government sites using our service and we have been contacted more than once to ask about cookies, because it’s illegal to have a government site that sets third party cookies without a signoff from the Secretary of Defense – no joke. So if you want to disable cookies in your tracking, implement this code as soon as possible. We’re going to email everyone who has a .gov site in their account and point them to this post so we can be sure that everyone sees it.
Pinging
Pinging support will let us provide much more accurate time on site figures for your visitors. Right now we just rely on a time out period to say ok, this person is gone. With pinging, we’ll actually know when they’re gone. Spy will be much more accurate in terms of how many visitors are actually on your site literally right now. This will also let us track how long someone is on your page for the last page view of their session. In particular, people who only have 1 action will no longer all be shown as 10 seconds – we’ll actually know how long they were online.
We’re also going to adjust our bounce rate calculation so not everyone with just one page view will be counted as a bounce. While a lot of people who only have one page view are not engaged with your site, this isn’t always the case. If you have a long article linked from Digg for example, 50% of the people may actually read the whole thing and be on your site for 5-10 minutes. Right now, all of these people would be shown as bounces, but once this feature is implemented we’ll probably classify anyone who is on your site for more than 30 seconds as an engaged user, and they won’t be a bounce.
Woopra recently poked fun at us on their blog for not having pinging support, but we agree with them – this feature is needed, and we will have it very soon. It’s been a planned feature for a very long time, so we’re glad it’s finally in the works.
Update on new tracking code
We’ve had a couple of reports from users that their traffic had gone noticeably down in the last day, coincidentally enough starting around the same time we released our new tracking code.
To be clear, most sites didn’t have any problems, and their users are unconsciously thanking them for a faster loading experience. However, one thing became clear – the sites that were noticing a large effect also happened to be site that aren’t exactly the fastest loading sites in the world.
As mentioned in our last post, the new method waits until the onload event has fired to track the page view. This doesn’t happen until all javascript, images, and css are downloaded and parsed and your browser’s loading bar disappears. (Safari does things a bit differently but that’s not important here). So if your site has a bunch of third party widgets on it, or say 5000 images, or is hosted somewhere on an overloaded server or slow connection, the time for onload to fire can be as long as 10-20 seconds.
To address this, we’ve made a change to the code. Unless you have specifically defined the new clicky_custom.delay property, the tracking code will register an onload event as well as a timeout of 3 seconds to log the page view anyways. These won’t both happen – whichever one fires first goes laughing all the way to the bank, and the other one goes crying home to mommy.
We think this is a good tradeoff. If your site loads in a decent amount of time, we’ll wait for the onload event. But if it’s slow, then we’ll log a page view after waiting for 3 seconds to help ensure that we log as many of your visitors as possible.
If you want to override this either/or behavior, just specify the delay manually. Its value can be either onload, in which case it will ONLY fire onload, or the number of milliseconds you want it to wait (0 = no delay).
Tracking code changes for a better user experience
We’ve just released a change to our tracking code that will help ensure the best user experience possible on your web site. You don’t have to change anything on your site, the changes are in the code itself that is loaded via the script element.
Previously, as soon as our tracking code loaded, it would connect to our tracking servers to log the page view. The problem here is that if things aren’t running under perfect conditions, that could interfere with the overall loading speed of your web site – especially if parts of your site depend on the onload javascript event.
We have changed the default behavior so that the initial page view is not logged until the onload event has fired. For users on very slow connections, or who browse between pages very quickly, this may result in slightly less accurate tracking. But we’ve been testing it all day on a few of our own sites (including getclicky.com) and there are no discernable differences in our numbers, so this should work well for everyone.
Of course, if you prefer the old behavior, you can change it via the new clicky_custom.delay parameter. Set it to the number of milliseconds you want the delay to be – 0 will result in no delay at all, emulating the old behavior. We recommend keeping it to the default setting however, unless it causes any problems with your tracking (and if it does, let us know).
The tracking code should be the very last thing in your HTML anyways, so changing the default to onload shouldn’t change the accuracy – it will just let your site’s onload events fire before we log data.
What about asynchronous javascript?
Google recently introduced asynchronous tracking for Google Analytics. Ultimately we’d like Clicky to have this option as well, but it’s not as easy as it sounds and we can’t make it the default behavior like we did with this change.
The main reason for that is because our tracking code has a number of javascript functions you can call after you include it in your HTML, and you’re assuming that those functions are already loaded and ready. By changing to asynchronous, we’ll have to create some kind of queue object for you to pass data to while you’re waiting for the tracking code to actually be loaded (because you’ll have no idea when that will actually happen). This will require a large rewrite of the tracking code, as well as a lot of documentation on the differences between the two methods.
The change we made today though should make a noticeable difference on your site. Logging data to our servers is generally much slower than downloading the tracking code, so this change makes a much bigger difference overall. Yes, the tracking code itself still must be downloaded before your onload event fires, but since we now use a global tracking code URL for all users, and we’re tracking almost 180,000 sites, chances are fairly good that a user arriving at your site already has our tracking code cached in their web browser. And even if they don’t, that will only affect their first page view. Every subsequent page view will benefit greatly from this change.
Of course, because they may have the old version cached already for up to 7 days, it will be 7 days before every single user on your site will be affected by this change. But in all likelihood, most of them will have it within 48 hours.
New tracking code format; please update your site if possible
We’ve recently changed the format of the tracking code you paste onto your site to take advantage of cross-site caching. Here is an example of what it used to look like (Javascript portion only):
[script src=http://static.getclicky.com/123.js][/script]
In this example, 123 would be the site ID for this site in our database. This is all fine and dandy, but the problem is that the URL is unique for each site that has our tracking code on it, even though the actual javascript code that is being downloaded is the exact same. So if someone browses to 10 different sites in a day that all have Clicky on them, they would be downloading 10 copies of the same code, instead of 1.
As of a few weeks ago, we changed the format to this:
[script src=http://static.getclicky.com/js][/script]
[script]clicky.init( 123 );[/script]
As you can see, the URL of the tracking code is now the exact same for every site that someone would visit with Clicky on it. We just added a seperate function call to set the site ID within the script after it’s downloaded. Since any user’s browser would cache this script, it doesn’t have to redownload it. This means your site will load faster for anyone who has visited another site with Clicky on it in the last 7 days.
So, the point. If possible, please replace the existing tracking code on your site with a fresh copy (go to site prefs, then tracking code, to get a copy). As already mentioned, this will help speed up your site for the average visitor, as well as reducing bandwidth usage on our end.
Of course, the old format still works, and will indefinitely. We don’t want to force you to do this, but if you have a few extra minutes, the web will be a better place. Thanks.
UPDATE: Yes, the new WP plugin has the new tracking code format. This only applies to people who manually paste the code on their site anyways, since using a plugin puts you at the mercy of the plugin developer.
Recent Comments