The last 6 months, we have been extraordinarily busy with a major infrastructure upgrade that will make Clicky much faster and more resilient. This is by far the most major backend upgrade in our (almost) 10 year history. A lot of planning and testing has gone into this and we're excited to finally be under way with the database aspect. Our load balancers have already been on the new infrastructure for a month now, and web and tracking servers will follow up after the databases are done.

The database maintenance in late April was in prep for this migration, to make it as fast as possible. This weekend we will be doing 8 database servers - 6, 22, 28, 29, and 59-62. And each weekend thereafter we plan to do at least 20 more. We have 85 total database servers at the moment so we should be done or at least very close to it by the end of June.

Time-wise, migrations are similar to the database maintenance we do a few times a year. Most servers will be in the 4-10 hour range, but some of the bigger/oldest ones will take as long as 24 hours. As well, traffic processing unfortunately has to be halted during the migration. But these new servers scream and will catch back up to real time in no time at all once the migration is done.

We have gone out of our way to make this process as transparent as possible. When a db server is migrating, your affected sites' dashboards will show a message like this:




The message shows the time the migration started, and an ETA for when it will be done (both in your local timezone), based upon how many rows/second we know these go on average and how many rows total there are to migrate.

Once a server has been migrated, reports should load much faster than before. We are planning to increase the filtering/segmentation limits as well once this is all done, as those should have much less of an impact on real time processing.

We're also excited to be done with this because it means we can get back to the software side of things, which is our real passion.

Hope everyone has an amazing summer!

No posts for a few months so I figured I'd group a couple of things into a single post.

HTTP/2

Last summer we migrated to Nginx for load balancing and it's been fantastic. A few months later, Nginx released support for HTTP/2, which I've been salivating over ever since. We recently acquired some new servers that are much higher end than the ones we were using before. We migrated load balancing to these and took the opporunity to update Nginx to the latest and greatest while we were at it. This means we're now live on HTTP/2 across the board - our own load balancers, plus our CDN (Cloudflare).

From some tests we ran, the only other analytics service (that we like to compare ourselves to) that supports HTTP/2 is Google Analytics.

Sticky table headers

When you scroll down a report, our navigation tabs have "stuck" to the top of the screen for quite a while now. But the table headers in most of the reports we have would disappear. Not a big deal before, but since we added all that yummy segments data to the reports last April, there's a lot of colums to look at.

Today, we pushed up an update so the table headers will now stick to the bottom of the tabs when you scroll down, as you can see in the screenshot below.

This was tricky, because we use tables for these particular reports. (Don't give us heck about using tables here, this is exactly what they were designed for and is pretty much the only place they're used on our site). You can't just add position:fixed to a table row element, so instead we worked out a solution where we clone the table and remove everything but the first row, and stick that to the top, right below the tabs. It works great!

Tracking code queue encoding issues fixed

When we released heatmaps in Oct 2012, we made a change to our tracking code to queue up certain types of beacons to make them more accurate (javascript events and goals) and more efficient (heatmaps).

The queue is stored in a cookie in JSON format, which is URL encoded, then decoded when the cookie is read. The bug was that there was an extra URL decode in there, which badly broke JSON-parsing when a URL or title had "quote" characters in them. What made it difficult to find and fix was that other areas of the tracking code, I had inadvertently worked around this bug, thinking it was just a feature of browsers that they always decoded cookies when reading them. Alas no, it was just my own damn fault.

This was a very uncommon bug to come across, but for the few people who emailed us about it over the years, it was really nasty. A fatal JSON parse would basically kill javascript entirely which could severely break a site with our code on it. Thankfully this is all fixed now.

White label iframe auto-sizing

This is only of interest to our white label customers since, for security reasons, we don't allow Clicky itself to be included within an iframe - unless it's a white label.

Why do we let white labels use iframes? Because it's simply the best way to integrate the analytics reports into a company's existing site, making it completely seamless. The problem is that you have to manually declare an iframe's width and height, and as someone clicks around pages, the actual height of each page is going to change. Since some of our reports can get pretty tall, the best solution was to just set a ridiculously large height on the iframe so that it would never have to scroll internally.

Good news! Now we have added messaging support to pass a message to the parent document with the height of the iframe document as each new page loads. Full details are here.

etc

There have been a ton of minor tweaks and bug fixes pushed up in the last 3 months as well. Sometimes there's a longer period of time between blog posts than there used to be. Don't worry, we're not slacking. We generally only post when there's a major new feature to talk about. There's lot of things going on behind the scenes at any given time that aren't necessarily of interest to our customers, but these things take away precious time, time that we wish we could spend 100% of writing code.

Some of the most requested features we get are to filter out all traffic from specific organizations, and filter out all traffic from specific countries (or only log traffic from specific countries, for "hyper local" sites). For the countries thing, we used to link people to an old blog post that showed how to do this, however it stopped working a year or two ago when Maxmind killed their javascript API.

Well, no fret! These types of filters, and more, are now officially supported directly from the new "Visitor tags and filters" site preference page.




These are all of the filters you can create from this new filter hub. And like the IP/UID filters of yore, every filter can either be site-specific, or apply globally to all sites in your account.

• IP/UID - This was what you used to do from this page (and nothing else). Filter out traffic based on IP address or UID (tracking cookie).
  
• Pages - Filter out page views that match specific patterns. This used to be part of the main site preferences page (hidden under "advanced"), but we wanted to centralize all filters, so it's here now, and with much better wildcard support than there used to be.
  
• Query parameters - Enter in query parameters you want stripped out from URLs (the main purpose of this filter type, to help normalize your content report), with the option to also ignore those page views completely if they contain these query parameters.
  
• Countries - Ignore all traffic from specific countries, or only log traffic from specific countries.
  
• Referring domains - Full wildcard support with this filter type. Two options here. Either ignore all traffic that comes from specific domains, or, log it and attach the referrer to the visitor but DON'T log the referrer to the top referrer (and related) reports. This second option is kind of weird but everything exists for a reason.
  
• Organizations - Filter out all traffic that we resolve to specific organizations/hostnames. Full wildcard support.

Clicky is the best service in the biz when it comes to filtering out robot activity and spam referrers. We are able to be so good at this because you guys let us know about new ones that pop up in your logs. So while this new filter system can be used to filter out bot/spam activity immediately for your own account, we still want you to let us know if any traffic in your logs is suspect, so we can update our global block list to benefit everyone. So don't let this make you lazy!

Back in June, we migrated to Nginx for load balancing, which has been fantastic. I've been wanting this for years and I was so happy when it finally happened.

We're using some older hardware we had lying around, the parts combined for each server cost barely $1,500 when originally purchased. Compare this to the $7,000 we paid for each of our old Kemp load balancers, not to mention the $1000+ support contracts per load balancer we needed for software upgrades and warranty exchanges (which we've had to do 3 times over the years. Of a total of 6 that we've owned, 3 of them have died and had to be replaced. 50% failure rate. Compared to the ~60 servers we've built over 9 years and only had 1 die, ever.) These sub-$2,000 machines can handle more than 3x the load of our $7,000 proprietary load balancers. 3x the performance for 1/4 the cost = 12x more for our money, plus no more support contracts.

Beyond expense and reliability issues, we also wanted to have really great SSL. The kind with SPDY HTTP/2 and an A+ rating. With Kemp, we had none of this.

The final step for an A+ was enabling HTTP Strict Transport Security, which took some consideration because there's really no going back. There were a number of things to double and triple check and some code to update, etc. But as of today, it's live. This feature tells a browser to always connect to a domain via HTTPS, even if a page/link tells it to do otherwise, ensuring all of your interactions with a web site are always secure.

Out of curiosity, I checked all of our competitors' SSL ratings. Only one of them has an A+, and surprisingly it's not Google. Otherwise it's a mix of A, B, and C. When we were on Kemp, we had a C, and now we're A+. From worst to first, oh yeah!

We just pushed some new updates for our alerts system.

First, webhooks. Basically this means we'll ping a URL that you give us everytime that alert is triggered, and you can do what you want with the data we pass through to it. Full details on this are on the alert set up page.

A while back we added push notifications for Safari on OS X. More recently, Google Chrome added push notification support, including on Android, which is killer. We don't have an app so the thought of finally having mobile push notifications was exciting.

We wanted to add support for Chrome notifications pronto, but the security behind push notifications is a flippin' nightmare to say the least.

Then we discovered Roost, which handles all that for us. So we signed up and implemented that into our site, which was much easier than doing Safari manually was. Roost supports Safari OS X, Chrome, and Chrome on Android, and Firefox is "coming soon". Two-thirds of you already access Clicky on Chrome or Safari, and when Firefox support comes out, we'll be looking at almost 90% coverage, so that's pretty great.

The only thing we don't like is that we weren't able to add audio support to these push notifications. Oh well!

So how do you set these up? On the alert set up page is a new checkbox for push notifications, along with a link to manage your push notification devices. Click that link to add your supported browser to your list of devices (if it's not supported, it will tell you). Then go back to the alert set up page and you can select which device(s) to push to for that alert.

Here's what the alerts look like in action. When you click on an alert, you will be taken to the visitor session on Clicky. Enjoy!






A few other things.

1) No iOS push notifications yet. Hopefully either Apple or Google will add them to the iOS versions of Safari or Chrome soon!

2) We killed the old Safari push notification system. That means you'll need to opt-in again on Safari to get alerts.

3) Push notifications work in the background, so even if your favorite browser isn't supported, you can still opt in using a supported browser to get push notifications on your device. When you click them though, it will open in the browser you opted in with (e.g. Chrome).