You can now change the default data type for each dashboard module, amongst other things

We've made a number of enhancements over the last few weeks that have gone unannounced, because none of them were particularly worthy of their own blog post. But now that we got a collection of items, we're going to write about them.

  • Change the default type for any dashboard module - When you customize your dashboard, most modules will now have an option called "default type". The options listed are the exact same things as the "tabs" you see for that module, when viewing your actual dashboard. Previously, the default type was always whatever was "first" in that list. But now, if you want the default to be something else (e.g. change "Links" to default to "newest unique" instead of just overall top incoming links), you can do that!

  • If your page titles change, we'll update them too - Previously, we only logged the page title for any unique URL for your site the very first time we logged that page. If you updated your page title structures (as an amazingly insane number of you do, apparently - we get emails about this every single week), Clicky would still show the old one. Alas, no more! If the title changes for any given unique URL on your site, we will update it too. The update won't always be immediate, though, but it should be within a week (assuming that the page has been visited and logged by Clicky since you last made the change).

  • Hourly graphs for today stop at the current hour - Say it's 10am and you're checking your hourly visitors graph. Used to be, every hour after 10am would be a zero - which it technically is, but we'd draw it that way too, so it made it look like your traffic just fell off a cliff. No more! If it's 10am, we'll only draw the graph (for today) up until 10am, which has a nice psychological impact.

  • More translations - We've added a bunch of new terms to translate. 100% of our stats reporting interface is now available for translation. If you want to help, click here!

  • Larger date ranges - All reports were limited to one year. We've increased this limit to 2 years. Segmentation (filtering) has always been limited to 31 days though because it's a fairly intensive process. But the update we released a few months ago dramatically increased the efficiency of the way visitors are stored. Because of this, we can now allow you to segment a larger range. The new limit is 90 days.

  • Disable pinging in our tracking code - We don't know why you'd ever want to do this, but we got requests for it, so we added it. By default, our tracking code periodically pings our tracking servers while a visitor is sitting on a single page, so we can get a more accurate figure for how much time they actually spent on your site. If for some reason you want to disable this (and we won't complain - it means less stress on our tracking servers!), you now have the option.

  • Complex IP range queries - In a single request, you can now request a list of visitors that match a specific range of IPs, or a specific IP, or both, or multiple of both. For example, you could use this to request all visitors from 65.0.0.0-75.255.255.255, plus 66.1.2.3., plus 2.3.4.0-2.3.4.255 - all in one request. This will be mainly of interest to those of who utilize our API, but regardless, to those of you who need something like this, we think you'll like it. You can find documentation for it here.

  • Time offset for visitors and actions in the API - You can now request a specific time fragment for type=visitors-list and type=actions-list in the API. This means if you have data up through say 12:30pm extracted, and it's now 1pm, you no longer have to "guess" how many items you need to extract so you can get all of the missing data from 12:30-1pm. Now you can just say time_offset=1800 (30 minutes) and you'll get only the data you need. You'll need to (probably) request limit=all as well, otherwise the default limit of 10 applies. We like this option a lot because it makes your life easier, and it puts significantly less stress on our API. So if you have an app that extracts visitors or actions lists, please update it to use this option.
15 comments |   Jun 14 2010 9:14pm

bit.ly integration

One of the best parts of owning a small company is being able to act fast. There's no red tape or clueless management to deal with - you want something done, BAM, it's done! A perfect example is when Google Chrome was released. Within several hours of the announcement, we added support for it to our web browser reporting. If I remember correctly, it took Google Analytics several weeks to get Chrome detection integrated, which we found amusing (ya know, since they're made by the same company and all).

Anyways, I was recently reading a story on TechCrunch about bit.ly, and it briefly mentioned at the bottom about how WebTrends (a fellow Portland analytics firm) announced a partnership with bit.ly to integrate bit.ly's analytics into their reports later this summer. I didn't know bit.ly had a stats API (because I use clicky.me, of course!), so I jumped on the opportunity. Two days later, it's part of Clicky.

bit.ly's existing API only provides very basic data unfortunately - the only thing you can access is the total number of clicks that your last 15 shortened URLs have had. I imagine this partnership with WebTrends will provide them with access to all of the analytics that bit.ly gives you for a link, when viewed on their web site (geographic data, referrers, etc - here's an example), which we don't think is fair really. Their API should be open to everyone, so we're a bit disappointed there.

But no matter. We think you'll still like this integration, and we've made it extremely easy to access the full bit.ly report for any of your links simply by clicking on the link. Try it out in our demo account.

How to set it up

This feature does require a Pro or higher account (upgrade here if necessary). For any site you want to add this to, just go to your site preferences main page, click "preferences" again (near the top), and then click the "advanced settings" link and enter your bit.ly username where requested.

Available reports

This is available under the "Links" report, by clicking the new bit.ly sub-tab. It has also been added to the "Short URLs" dashboard module, and to our iPhone web analytics. We wanted to add it the API too but there's a bug with accessing third party data via the API at the moment that we still need to fix.

Enjoy!



12 comments |   Jun 08 2010 3:59pm

Say goodbye to search analytics

Google just announced their new secure search beta, and DuckDuckGo announced similar measures. DDG's are a bit more thorough, but the end result is the same - the search term is not passed through the referrer, and hence no analytics tool (not even a good old log analyzer) will have any idea of what a visitor searched for to reach your site.

They both claim to do this in the name of privacy. Google's is a beta so it's off by default, and it doesn't explicitly say "privacy from webmasters", but that is part of the end result. DDG, on the other hand, explicitly mentions "not leaking your search terms", and this feature is enabled by default for all users - even over non-HTTPS connections. (Technical note: when you click a link on an HTTPS page, your browser does not send a referrer, which is why HTTPS search engines will result in "secret" searches that we can't see).

Being able to search over HTTPS is probably a good thing for people in countries with vast censorship, such as China. I can understand offering this as an option that people can use. But I really hope Google never considers making this the default, because that would be very irritating for web masters - we would have no idea what people were searching for to get to our site, which is arguably the #1 reason to run analytics in the first place.

My big problem is that DDG is hiding the search term from sites by default. That's not good for the internet at all, and I'm scared that Google may end up doing something similar (via HTTPS or not), and perhaps other search engines in the future.

Part of the problem is that this gives users a false sense of security. Yes, someone "snooping" your connection won't be able to tell what you're searching for, but the sites you click through to will probably have a good idea, based on your landing page - not to mention they can also see their IP address and every page they have ever viewed on my site, ever. And yet somehow, not knowing this visitor's specific search term is protecting their privacy? Please. The only thing it does is make the life of a web master a much bigger pain in the ass than it was before.

I'm taking time out of my amazing Hawaiian vacation to write this blog post because that's how much I care about this issue, and believe that it is not good for anyone. Of course, I wouldn't be surprised to learn that Google Analytics will somehow magically be able to track these "secure" searches. Wouldn't that be convenient for the likes of every other analytics service on the planet?

This all seems very familiar, doesn't it? Other search engines may start doing this too, but really, with 90% marketshare, Google is the only one that matters. So what can you do? Blog about it. Tweet. Complain. Let Google you know that you do not like this, and let DuckDuckGo and any other engine who does this in the future know the same.
47 comments |   May 22 2010 10:25am

New engagement reports

We have a couple of new reports for Pro and higher members. These break down your visitors' engagement levels to quite a bit of detail, both in terms of time on site as well as number of actions performed. The reports are quite self explanatory, as you can see from the screenshots below, so there's really not a whole lot to say here. We think these will be a big hit in particular with those of you who don't like our new bounce rate, because part of this report basically shows you the "old school" bounce rate: the number of visitors who had only 1 action.

This is available in a new dashboard module, as well as full reports with a bit more detail under the Visitors tab. We also added it to the iPhone web app. You can also get the data from the API. The docs have been updated with the new type values you will need to request.




7 comments |   May 11 2010 9:32pm

Why Clicky's new bounce rate is the best in the biz

The standard definition of a bounce is a visitor who only viewed one page on your web site. Your web site's bounce "rate" is the percentage of visitors who "bounced". This metric is supposed to give you a very generic estimate of your visitors' engagement level. If you have a high bounce rate, then your site is apparently very unengaging.

But are single-pageview visits really the best way to define engagement? In the age of blogs and social media, we don't think so.

Our new release added pinging support to our tracking code. This means that as a visitor to your site stays on a single page, they are still talking to our tracking servers, so we know they are still on your web site. This lets us determine how long a visitor is actually on your web site, even if they only have one pageview.

There is a significant difference between a visitor with one pageview who spends less than 30 seconds on your site, and a visitor with one pageview who spends 5 minutes on your site. But no other analytics service will tell you about this difference - no matter how long any single-pageview visitors are on your site, they are all considered bounces. We think this is horribly broken and misleading, so we decided to redefine what a bounce is.

How Clicky determines a bounce

A visitor who has only one pageview, and who is on your site for less than 30 seconds is what we now consider a bounce. So any visitor who has more than one pageview, or any visitor who has only one pageview but is on your site for at least 30 seconds, is now what we consider "engaged" / not a bounce.

Say you have a blog post that you have shared on a few social media networks like Facebook and Reddit, and you get 1000 visitors to it. Chances are that 95% of these visitors will only view the article that is being linked to - one pageview. Maybe half will read the whole article, half will read part of it, and a few will click through to your front page to see more. Any other analytics service would report a 95% bounce rate for these visitors. But a bounce is negative, so it makes it sound like only 5% of these visitors were engaged. But that's not true at all - half of them read the entire stinking article!

Since Clicky now sends pings, we can measure how long each visitor is actually online. For the example above, Clicky would report a bounce rate closer to 50% for these visitors. This is a much more accurate representation of how many of these visitors actually "bounced" from your site, versus how many actually stayed online long enough to read what you had to say. Because of this, we think we now have the best bounce rate metric in the industry.

Arguments against this change

We've had some feedback that this new measurement is no good either, because there are lots of people who used tabbed browsing and open a bunch of tabs in the background, then go and read them later. This is true, but this is also more of a "power user" tactic. As long as less than 50% of users are doing this (and we think it's probably more like 10%), then our bounce rate is a much more accurate representation of engagement.

Some people also suggested we make this a different metric altogether, such as "engagement rate". We considered this, but ultimately we decided that the term "bounce rate" is just defined incorrectly in the first place. This shouldn't be a new metric - this is the way bounces should be defined, period. This is why it's called "analytics" - your traffic data is "analyzed" to help you make sense of it. Reporting that 90% of your visitors only had one pageview doesn't really tell you anything, but reporting that 50% of your visitors had one pageview and were online less than 30 seconds does tell you a lot about your web site's traffic.

This doesn't mean we don't want to make it better though. We will probably add something that detects whether or not the page being viewed is "in focus" or not, and only do the pinging if it is actually being read. This will require a lot of testing, however. For example, a visitor opens a link to your site in the background, but doesn't actually read it until an hour later. If we don't ping until the page comes to the foreground, their session will have already expired so the pings won't register when they are processed on our end. Should we delay the page view log until the page comes to the foreground? That might work, but what if they move the window/tab to the background again and then come back to it another hour later? As you can see, it gets a bit complicated, so we're not going to change it until we have taken the time to determine the absolute best way to do it, and test the heck out of it.

We'd still like to hear your feedback on this change of course, and what you think would make it better. So have at it in the comments.
28 comments |   Apr 26 2010 5:43pm

Next Page »




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