OS X push notification alerts

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.
3 comments |   May 06 2014 4:04pm

HTML5 History API tracking

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.

Update, May 7: We've removed replaceState()from being auto-tracked, as its purpose is quite a bit different from pushState() and was causing some excess data to be tracked that shouldn't have been.
3 comments |   Apr 30 2014 4:15pm


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.
3 comments |   Apr 09 2014 9:46am

New trend option: 'vs last year'

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

1 comment |   Apr 06 2014 3:55pm

HTML5 audio, embedded actions, tracking code verification, and better cookies

We wanted to let you all know about some of the bigger things we've released in the last month that you may not have noticed, because we didn't post about any of them - until now!

HTML5 audio, and automatic HTML5 video/audio tracking

We've had support for HTML5 video tracking for a while, it simply required adding an additional javascript file to your code. This month we just added the ability to track audio as well. We combined video and audio together into their own report, now called "Media", since they are quite similar in terms of the metrics we track -- and it's unlikely that many sites will have a mix of both.

Even better, we made it so you no longer need to include the extra javascript file at all. When the tracking code detects any video or audio elements on your web site, it will now automatically inject the other javascript file into your page so we can track the video and audio files without you having to do anything. Don't worry, if you already had that file included manually, you don't need to delete it. It will work either way.

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

This is a nice feature to check out if you think you have the code or a plugin installed on your site but you're not getting any stats. There are multiple reasons why tracking may not be working, but this will help you narrow down the list at least. You can access this feature on your tracking code page:

Better cookies

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: 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!
7 comments |   Apr 01 2014 8:20pm

Next Page »

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