Archive for the ‘Clicky’ Category
We just added OS X push notification support to our alerts system. Push notifications at the OS level require
the latest version of OS X (Mavericks).
Here’s what an alert looks like. Click on an alert to be taken straight to the visitor session on Clicky.
To set this up, you need to use Safari on a Mac running Mavericks. Safari is only needed for the initial authorization of push notifications, so if you use a different browser normally, don’t panic.
Go to the alert setup page for any of your sites and click the link at the bottom:
You will be prompted to authorize Clicky to send push notifications to your Mac. Once you grant permission, the device (your Mac) will be attached at the user level so if/when you setup alerts for other sites, you will NOT need to go through the authorization process again, the device will already be available to you during the alert setup process.
You can name each Mac after you add it so if you have multiple Macs and you want to get alerts on all of them, you will know which one is which, in case you want to remove any of them later. This includes sub-user accounts; when managing alerts, you will see a list of all devices that belong to all users with access (on Clicky) to the site in question.
If you use the HTML5 History API on your site, good news! Clicky now automatically supports it.
This type of navigation typically only reloads a small portion of your page to inject new content, which means our tracking code (previously) would not be executed again since that part of the page would be static — unless you manually added calls to clicky.log or clicky.pageview when you executed history.pushState or history.replaceState.
Clicky will now automatically track calls to both pushState and replaceState, as well as listen for the window.onpopstate event that occurs when a visitor clicks back or forward in their browser.
If for some reason you need to disable this new functionality, for example you were already logging calls manually, you can do so with the new clicky_custom.history_disable option.
Long term, we want to replace our own custom hashbang-ish navigation that we use on clicky.com with the History API. This automatic support of logging these methods will be a good motivator.
What a crazy couple of days it’s been for web site owners around the world.
Clicky was not affected by the Heartbleed security issue. The versions of OpenSSL running on our public servers and load balancers were not any of the ones that were vulnerable. To make doubly sure, we ran tests on all of our public IPs, and they were all reported safe.
If you’re going through all of the web sites you have accounts with and changing passwords or something of that nature, you can cross Clicky off the list.
We have a new trend comparison option that lets you compare reports and graphs vs the same date or date range from the previous year. For example, April 6 2014 vs April 6 2013, or April 1-6 2014 vs April 1-6 2013.
You can see this new option in the date menu for any graph:
You can also set this as your default trend option in your dashboard preferences. In this case, vs last year will always be the default graph comparison, but last year will also be used in to calculate the trends we report (the red/green percentages next to each number in most reports).
We wanted to let you all know about some of the bigger things we’ve been working on the last month that you may not have noticed. None of them felt major enough to warrant their own post, so we were waiting until we had a nice collection of goodies.
HTML5 audio, and automatic HTML5 video/audio tracking
Embedded actions in the visitors report
This new preference, disabled by default, adds some additional detail into the standard visitors report. Now you will no longer need to click through to see the actions (page views, etc) of each visitor. The first five actions will be displayed right beneath each visitor, with a link below them to see full session details if there are more than five actions.
Note that this will slow down the loading of the visitors report by a somewhat noticeable measure since we have to query for a lot more data, but, it’s pretty nice if that’s what you’re into.
Here’s what it looks like:
Here’s where you enable this new preference:
Tracking code verification
We released this feature a bit prematurely, not expecting too many people to notice it right away, but we got bombarded with emails immediately saying the verification doesn’t work! Whoops. There were a few bugs that we got quickly fixed.
This is a nice feature to check out if you think you got the code or a plugin installed but you’re not getting any stats. This will verify for you that the code is at least installed on the site. You can access this feature on your tracking code page:
The cookie system we have been using since October 2012 to authenticate yourself when you’re on your own web site (which then auto-ignores your visits and loads the on-site analytics widget)… was a bit less than ideal.
The biggest problem was that we used a single cookie for two different features (widget and auto-ignore). On top of that, the cookie was always set, and it would stay set (for a year) even if you clicked the logout button. The reason we wanted it to stay set was so that your visits would always be auto-ignored, but it was a bit of a security issue in terms of the same cookie being used to authenticate on-site analytics. The chances of anyone ever seeing anything via the widget that they shouldn’t have were microscopic (it would only happen on a shared machine and only if you logged into both Clicky and your web site, and someone after you looked at your history and also visited your web site), but that’s no excuse.
So, we’ve changed several things here. There are now two unique cookies for each feature: one for the widget and one for auto-ignore. When you logout, the widget cookie is deleted, but the auto-ignore cookie stays set so your own visits will continue to be ignored. Last, the expiration time of the widget cookie was shortened to 90 days (from 1 year previously).
That about wraps it up for now, but there’s plenty more in the pipeline!
We just launched our new mobile site, in development the last couple of months. The old one was built with iUI, hot for the time (2008) but crusty by today’s standards.
jQuery mobile (JQM) was our framework of choice. Since it has all those fancy events, we wanted to track those too. Automatically, of course. With JQM growing in popularity, we decided we’d build a plugin that pairs with our tracking code to track these events automatically, and then release the plugin for everyone to use once we were done. And, we’re done.
A screenshot of the new mobile site is below. It shows the main dashboard after selecting a site on the previous page. In the old site, you had to select a date range right after selecting a site, because of severe limitations of the framework we were using. Now there are actual menus (amazing, I know) which you can see in the top right: a shortcut to change the date, and the other ones brings up a side panel with more options.
You can graph trends just as you could before, although we’re not showing trends here other than right on the main dashboard (we couldn’t make trends fit in with the new style of reports). Instead, in a report such as traffic sources, click on the number itself; that will popup a graph and there are options to change the date range.
Let us know what you think.
When you create alerts for something like a goal and configure them to be sent via email or twitter direct messages (RIP), what you get is a short URL that will take you right to the visitor session details on Clicky. A handy, but manual, process.
We had a request today to allow the alert IDs to be passed straight to the analytics API so that automated processes could get more data about these visitors. We thought this was a great idea so hopped right on it, and this is now available.
Full details and some example code are in the docs, but briefly, if you extract the alert ID from the end of the URL then pass that to the API as alert_id=XXX, then we’ll look up the session ID (first verifying the session belongs to the site_id and sitekey you also pass in) and convert the request to be as if you had originally sent in a type=visitors-listsession_id=YYY request.
You need to know what you’re doing to implement automatic parsing of emails, but for the people who have the ability to do this, we think you will like this new feature quite a lot.
Here’s an example API request for an alert we have setup for our blog:
I never realized how much I would come to love Bing in the last year. I don’t use it, but now that Google is pretty much 100% secure search across the, almost all of the search phrases that we end up logging are from Bing. Yay for being able to tell what people searched for when coming to our site!
Earlier today I saw this announcement that Bing is now testing secure (HTTPS) searches.
It’s different than Google’s though, at least right now. For a small number of sites, it changes nothing. But for most sites, it’s much worse. Why?
On Google, when do a search over HTTPS, when you click the result it actually sends you through an intermediate, non-HTTPS page. For example if you go to https://google.com and search for Clicky and click the first result, the URL you actually go to is this:
http://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1ved=0CC4QFjAA url=http%3A%2F%2Fclicky.com%2Fei=5fvWUrbSIOiqyAHyr4Fo usg=AFQjCNFOPVnz4LaWTBeOHfeCOADfndg5BAsig2=vLGsm0mdBFXCn-4n_CQ11Qbvm=bv.59378465,d.aWccad=rja
And then you are redirected to our web site. You can see they hide the search paramter (q=) but because this intermediate page is handled with standard HTTP, at least we still know they came from Google. Better than a kick in the pants, right?
The problem with Bing’s new secure search is that there is no intermediate page. This means that unless your site uses forced HTTPS across the board, not only will no searches get logged, you won’t even know they came from Bing in the first place (because browsers don’t send referrers when going from HTTPS -> HTTP). Since there will be no referrer, they will get logged as direct visitors.
For those of you with forced HTTPS on your site, you will still be able to see the actual search phrases used. But since very few sites use forced HTTPS, this will impact the vast majority of web sites out there.
This hasn’t been technically released yet so things might change, but as they stand now, this is how it is. To be clear, it doesn’t appear Microsoft is doing this to hide data from web site owners like Google is intentionally doing, but rather, as a way to protect users from NSA spying. That’s a great reason for this change, I just really hope they also understand the negative impact this will have on most site owners and add some kind of way for us to detect that the visitor at least arrived from Bing. Hiding the search phrase is one thing, but hiding the source of traffic entirely is just really bad for site owners.
There is a small amount of hope they might make it so it works like Google: This change is really going to hurt Bing’s marketshare numbers as reported by various services, including us. For this reason alone, I think Microsoft will change things around. They don’t want to start seeing headlines about Bing’s marketshare plummeting to zero.
I wanted to add that all of this secure search stuff impacts all trackers, not just Clicky. And I also wanted to let you know that we have a plan to deal with this, at least when we know the source of traffic is a search engine. As far as I know, no other tracker does anything special with these secure searches. We want to be the first to offer a solution, so I’m not going to go into details now, but I think our proposed solution will work well for most of our customers. Stay tuned.
There’s been an authentication bug with the on-site analytics widget (OSA) for about a year. It only affected a small number of customers, so it was hard to track down. This was not a security bug, but rather, OSA would just simply not display for a small number of people.
While mucking around with heatmap updates earlier this week, I was also updating some of the OSA code and a lightbulb went off in my dang head as to the cause.
Here’s how OSA works. When you login to Clicky, a cookie is set for in.getclicky.com, which is our tracking domain. This cookie is used for authentication purposes. When you visit your own web site, the tracking code tracks your visit and sends that info to in.getclicky.com. If that cookie is set, then we check if it matches the owner of that site ID on our end. If so, then we call some code to display the OSA widget (and at the same time automatically ignore your own visit).
OSA was released when our domain was still getclicky.com. So at that time, browsers considered the cookie to be first party cookie because it was a sub-domain of the site you were already on. Life was good.
Two months after OSA was released, we acquired clicky.com. But we left *.getclicky.com as our tracking domains, so people wouldn’t have to change their tracking code and everything could just be transparent.
This change meant that setting a cookie for in.getclicky.com when logged on to clicky.com was now a third party cookie as far as browsers were concerned. So when we started getting emails about OSA not working, we assumed that the cause was third party cookies were disabled in their browser. And in lots of cases, this was the cause. But there were a few people who, no matter what they did, could not get the widget to work.
So that lightbulb I was talking about earlier… when in.getclicky.com tells our tracking code to execute the OSA widget, the widget is loaded from clicky.com, not in.getclicky.com. We hadn’t made any major updates to heatmaps or the widget since the domain change, until earlier this week when I was messing with that code, so I hadn’t really dived into that block of code for a while. Sure, I had looked at the code since it was written, but you can’t really get into the zen with existing code until you start playing with it.
The problem was that the third party cookie would authenticate you on the tracking domain, but unless you had checked the remember me box when logging in to clicky.com, you had no authentication to load the OSA widget from clicky.com, so it would just exit out. Most people use the remember me option so that’s why this only affected a small number of people.
What we’ve done is now when your beacon (with proper cookie) is sent to in.getclicky.com, before calling the OSA widget, we tell the tracking code what your sitekey is. The sitekey is used to authenticate requests with the API and other things. So now when OSA tries to load by sending a request to clicky.com for the data, it’s authenticated with the sitekey.
I’m always 100% of the time logged in to clicky.com with the remember me option set. Once I discovered this issue, I logged out and sure enough, OSA would not load for me anymore when I was on clicky.com, even though my cookie for in.getclicky.com was still set. Now after making this change, whaddaya know… It works! And it should work for you too if this was affecting you!
We had a customer request for being alerted by visits from certain organizations, whether generic in nature (the example given here was school), or something more specific.
Yeah we should have already had this. Took less than 30 minutes to add it. This will be extremely useful for those of you who use Clicky as a lead generation tool.
Another example would be, pretend you work at a newspaper and you have a feeling that a major competing newspaper is stealing your stories. Setup an alert to see when they visit, as shown in the screenshot below. (Not saying NYT does this of course, it’s just an example).
This will match both organization names and hostnames.