Analytics Expert Blog

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).