getclicky.com/blog

Database server migrations over the next couple of weeks

Mon, 26 Mar 2012 17:09:14 -0800

We're migrating to a new server infrastructure over the next couple of weeks, which means all of our database servers will be finding new homes. While any given database server is being migrated, traffic processing will be halted, but the server will still be online so you can view existing data. Once the files have been copied, it will need to be taken offline for 10-20 minutes while some rsync'ing magic finishes everything up, then it will be brought back online with its new hardware. At this point it will be anywhere from 30 - 120 minutes behind real time, and traffic processing will then resume.

Anything that interrupts traffic processing is something we'd always prefer to do on the weekend. However, we can only do 2-4 servers per day and we have almost 50 database servers, so that would severely slow down the process. So, we are going to be doing it on weekdays too, and expect it to take 2-3 weeks total. But it will be worth it!

Android Widget (beta)

Tue, 20 Mar 2012 11:50:58 -0800

We're releasing a beta of our Android widget today. It should work on any phone running Android 2.0 or higher.

There are three widgets to choose from, depending on your needs. You can setup one or more widgets for every site in your account. The widgets are very battery friendly, even when set to pull every 5 minutes. I've been testing it for several months now with very aggressive settings and it's had zero impact on my battery life.

Why a widget and not a full blown app? We don't believe our resources are best spent maintaining an app that tries to do (almost) everything our web site does. Apps are much costlier to write and keep up to date. We are constantly adding new features and reports and tracking new types of data, etc. A simple widget living on your desktop (still one of my favorite Android features) that lets you keep up with your basic stats with a quick glance, with a few more details available when you click the widget (as shown here), fits the bill perfectly for us.

Handy dandy installation guide

Since this is a beta, we're not releasing it through the official marketplace just yet. So you'll need to enable the option to install apps from unknown sources in order to install this on your phone.

- Android 4.0+, go to Settings -> Security -> Unknown sources (checkbox).
- Android 2.0+, go to Settings -> Applications -> Unknown sources (see a small guide here)
Download this file onto your phone!
Once completed, click the item in your notification bar (screenshot) and install.
Setup a widget! The first time you do this, it will prompt for your username and password but you'll only have to do that once.

Important note: Widgets don't have icons you click to open them up like standard apps do. Instead, you must install the widget onto your Android desktop before it can be used.

In Android 4.0+, there is a new dedicated widgets area in your app drawer, so go into there and long-press on the widget you want, then place it on the desktop. Older versions of Android, you'll need to long-press on your desktop until a menu pops up, then select widgets then find Clicky. There are three widgets to choose from.
Android 4.0 potential installation bug - sometimes, on Android 4.0, you have to install the downloaded file twice before it will show up in your widget drawer. This only happens on 4.0 and only sometimes, we're not sure what causes it yet, but if you don't see the widget after installing it, install it again and it will show up.

That's all there is to it. As mentioned above, you can add one or more widgets to your desktop for every site in your account, and data is pulled in a very battery friendly manner.

This is a beta so we want your feedback and bug reports. We hope to have an official release on the marketplace within 1 month!

blogspot tracking issue

Mon, 19 Mar 2012 12:40:30 -0800

[Update: This has been fixed!]

On Friday, Google appears to have made a change that's affecting tracking for blogspot.com hosted sites. A significant portion of our userbase is tracking blogspot.com sites so we want to get this figured out as fast as possible.

The issue is strange. The majority of people saying tracking broke, it's only affecting visitors from Germany. This raises a red flag to me, as I know Germany has strict privacy laws. Google may have agreed to block third party scripts from loading for people who visit blogspot.com sites and live in Germany. That's a stretch but... who knows.

Another possibility is that Google is forcing their dynamic view templates on visitors in certain countries now, either as a test or that's just the way it is. I know that it is not possible to track blogspot sites that use this new format, so that would explain it. However it seems strange Google would do such a thing, especially without publicly announcing it first. The last post on their blog was 3 weeks ago.

The frustrating thing is that everyone who has contacted us, I've gone to their site and verified the code is still installed. I click around on multiple pages, then view their visitor report on Clicky and verify every page I viewed was logged correctly. So everything seems fine. The code is there. I get tracked. But the stats for all of these sites are definitely way off compared to last week, so yes, something is wrong - but it's not on our end.

And of course, there's no way to contact Google about this, other than praying they see this post.

Does anyone know what is going on or have any ideas?

Filter visitors by time spent online

Fri, 16 Mar 2012 16:00:04 -0800

We've had the ability to filter by actions, e.g. exactly 10, or greater than 10, or less than 10, for quite a while now, but we didn't have the same things for time spent online. Also, we didn't have double boundary support, e.g. more than 10 AND less than 20, which means we couldn't link to these filters directly from our engagement reports, something that has always driven me crazy (and you too, based on the emails we've received).

All of this is now fixed. It also works with the API, and the docs have been updated.

Time online is specified in seconds. Formats for both parameters are specified as shown below, if you are manually typing one in to filter by, or using the API:

10 = exactly 10
>10 = more than 10
<10 = less than 10
10,20 = range of 10 through 20 (including 10 and 20)

Unique ID tags and filters (yes, finally)

Thu, 15 Mar 2012 14:36:39 -0800

The ability to tag visitors based on IP address is a very popular feature and something we've had for 5 years now, well before we ever started using cookies to better track unique visitors. When we added tracking cookies to the mix, we never updated the tagging system to support them. That was almost 2 years ago but as of today, we now finally support these cookies too.

When viewing the details of a visitor session, there used to be a name this visitor link next to their IP address. We've reworded this to just say tag, but there's now two of these links: one for the IP and one for the UID so you can click either one.

In site preferences, the sub-menu has been renamed from IP tags filters to Visitor tags filters, and in here you can manage all of them. When creating one from scratch, we determine if it's an IP or a UID based on the pattern of the string you enter. UID's are just numbers like 123456 so if that's what you enter, we'll use it for UID tagging or filtering. If however it's standard IP format (1.2.3.4) then it will be a normal IP tag/filter as has always been.

That may sound confusing but the good news is that the vast vast majority of you create tags and filters directly from the session details page, so you don't have to worry about the number you're actually entering, it's done for you automatically. It still works that way, so just keep doing what you're doing and all shall be good.

Track your Facebook storefront with Clicky and Zibaba

Wed, 07 Mar 2012 17:08:37 -0800

We have partnered with Zibaba to offer real time analytics to anyone who sells, or wants to sell, products or services through Facebook.

Zibaba lets you create an online store directly on your Facebook fan page. Visitors can buy, share, recommend, and like products, ask advice, and share discounts, generating buzz among their growing networks of Facebook friends. And now, thanks to Clicky, you can track it all in real time.

There numerous advantages to selling through Facebook. Facebook users spend a ridiculous amount of time online, and are 9x more likely to engage with online retailers, to name a few.

If you're interested, but not sure about selling on Facebook, Zibaba offers new users a 14 day trial period to test out the software for free. Sign up here!

Path analysis (beta release)

Tue, 06 Mar 2012 16:49:57 -0800

Almost 3 months in the oven, we are finally ready to release a BETA of our path analysis feature. We're releasing as beta because there are still a few quirks and we want your bugs reports and feedback on the interface and what you think it could do better. This is a Pro or higher feature, of course.

Part of what took so long was making it fast, because we know our visitor filtering isn't exactly the fastest thing in the world, especially for high traffic sites over large date ranges. But we are limiting this to a maximum range of 31 days at once for the time being, to make sure resource usage doesn't get too ridiculous, until we know how you are using it.

There are two different features in this release.

Simple path analysis

I like this one because it's quick and dirty and requires zero forethought. When viewing your Content or Events reports (planning to add downloads and outbounds later), you'll see an icon next to each item:

Click this icon (not the star, the other one!) to see an inline popup of the top 30 next and previous pages, for whatever date range you are viewing. If you're interested in seeing top next/previous pages for a page listed in there, click it and it will keep on going. Here's a good example for our upgrade page:

The top previous page is /user/. Makes sense as that's the starting point for most registered visitors, and there are links to upgrade right from that page.

Second previous page is /user/sites - this is where people register new sites on Clicky. If they're at or over their limits for how many sites they can track or how much traffic they're allowed, we prompt them to upgrade first.

Third previous page is /compare/, which is our competitor comparison matrix. From our upgrade page, we have a link to this comparison matrix, so people can compare our pricing and feature set, which we think will help win over more customers since most of our competitors are 400+% more expensive than us (ouch!). So how would this be a previous page? Well, after people look at it, they go back to the upgrade page! Well, some of them anyways :|

The next two aren't horribly relevant but the sixth one, /user/users is. That's where you add additional user accounts. If you're at your user limit or your account doesn't have access to that feature, then we say, hey, you gotta upgrade!

I could go on all day but the point is simply that seeing what pages are actually pushing people towards paying us for our service is extremely interesting. I of course had a hunch about these most popular paths since I designed the entire flow of our web site, but I didn't actually know. Now I do and it's great!

Real path analysis

This other aspect is much more powerful but takes longer to setup. That's to be expected of course, and if you take the time to do so it is pretty fantastic. In the future, we plan to group this together with goals for multi-step funnels. That's not making the initial cut though.

To reach this report, go to Content, then the Path Analysis sub-tab. It gives a brief overview of how to use it. Click the link at the top to start analyzing. Once you enter in some paths and click run analysis on the bottom right, it will analyze your input and return a report like the one below. This example is fairly simplistic but I don't want to showcase too many private details of our business here.

Until we integrate this into goals, you can use this as a kind of faux multi-funnel goal system, because you can save paths to quickly access them later.

Important note: In the screenshot above, see how the green arrow on the right has a little break in it? This represents infinite steps in between each path. In other words, it means the visitor didn't necessary go directly from the first page to the next, but after viewing the first they eventually viewed the second one. This is always the default when adding new paths in this interface. But if you only want to analyze direct path 1 -> path 2 flow, just click that arrow and it will become closed, representing a direct step:

After you make that change, you will have to click the Run Analysis button again. In fact, any change you make in this interface you will have to do that. The reason for this is if we were auto refreshing it with every change you made, it would take a lot longer to create exactly the report you want. So instead, we let you do all the steps you want first, and only process it when you tell us too. This is an important note because it works differently than all other reports on Clicky, which all react instantly to anything you click.

So, play around with it and let us know of any bugs you find or additional features you'd like. Barring any serious bugs, we're going to take at least a few weeks break from this because we could really use it. So we'd expect that the official release with some of your suggestions and hopefully all bug fixes would be out in about 1 month.

Database maintenance this weekend

Thu, 01 Mar 2012 13:33:23 -0800

Database servers 1-3, 6-10, and 14-33 will halt traffic processing for up to 10 hours this weekend while we perform some necessary maintenance. The servers will remain online so you will still have access to all of your data, there just won't be any new data processed for up to 10 hours. Most servers will be done much sooner than that, 10 hours is just the absolute max that any of them should take.

This process will start at about 10pm on Friday (USA PST), which is the same time that our normal database backups occur.

When each server finishes, it will begin processing its backlog of traffic that hasn't been processed yet. This means there will be an additional couple of hours for each server before it is caught up with real time again.

The purpose of this is in preparation for transitioning to our new infrastructure. We have invested heavily in new hardware over the last 6 months and we are finally (almost) ready to make it live. This is one of the last steps before we start.

To determine which database server a site is hosted on, take a look at the preferences page for that site.

Custom outbound link pattern matching, and iframe tracking

Wed, 15 Feb 2012 12:03:01 -0800

A lot of people seem to run plugins or custom code on their site that automatically convert links to internal redirects, so that you can count them internally. For example, instead of linking to http://getclicky.com/123 (affiliate link), you might link to http://yoursite.com/go/clicky instead. This page then redirects the person on to the real link.

The problem with this has been that our tracking code has no idea what's actually going to happen once someone clicks that link. Without actually following the link, it simply appears to be an internal link, so we ignore it by default. There have always been several ways to track these links (CSS tagging and manual data logging), however these methods required way too much pain on your end. We don't like pain.

So, we added a new customizable tracking variable today, called outbound_pattern. This allows you tell our tracking code, with just a few lines of code in one place, what your redirect URLs look like so that we can track clicks on them automatically. You can define it as a string, if there's only one pattern we should be looking for (should apply to most of you), or if you have multiple patterns, you can define more than one in an array.

The most common redirect URLs that I've seen are one of these three:

http://yoursite.com/go/clicky
http://yoursite.com/outbound/clicky
http://yoursite.com/aff/clicky

What you'll want to use as your custom outbound pattern is the the base part of these URLs, e.g. '/go/' or '/outbound/' or '/aff/'. You'll want to make sure whatever it is you use though is unique to your redirects, otherwise other links may start getting logged as well.

Single pattern example:
var clicky_custom = {};
clicky_custom.outbound_pattern = '/go/';

Multiple pattern example:
var clicky_custom = {};
clicky_custom.outbound_pattern = ['/go/', '/aff/'];

This code would go directly above your existing tracking code. And wrapped in HTML script tags of course.

If you're running WordPress, our plugin has been updated to support this new functionality as well.

iframe tracking

A while back, we tried to make tracking iframes better, in an automated way. This ended up causing some problems though so we killed it fast. Now we're bringing it back, but it's disabled by default so it will only process if that's what you want it to do.

Here's the problem. If the tracking code is installed in an iframe, we track the iframe, but in most cases your goal is to track the parent document instead. Otherwise the page URLs and page titles you see in our reports will be for the iframe itself, and we won't be able to log referrers.

So, if your goal is to track the parent document but can only put the code in an iframe or widget (e.g. with Apple's iWeb), set clicky_custom.iframe=1, so that our code will grab the parent's URL, title, and referrer.

99% of you that have the code in an iframe, your goal is to actually track the parent document. If this applies to you, set this variable, and you should be good to go.

Long term metrics, and other goodies

Wed, 01 Feb 2012 21:46:44 -0800

Our newest update is all about the long term, and it's one of the best things we've ever done. I'd recommend grabbing a fresh pair of pants before reading on because you're going to need them before you're done reading this.

It all started out innocently enough: A fairly simple update to goals that before I knew it had morphed into something else entirely. 80% of the stuff in this update was never planned, all of these ideas just starting coming to me as I kept working on it. Hmmm this would be sweet, oh this too, oh and this... Within days my bullet point todo list for this update was ridiculously long and ended up taking almost 3 weeks to complete. But that's the way it usually goes when I feel I'm on to something good.

New goal report

The main goal report still looks the same - until you click on a goal, that is. This new single goal report is awesome. Here's an example of one goal we track for new users registering with Clicky:

Talking points:

You can now graph all goal metrics (conversions, conversion rate, revenue [not shown], visits to goal, and time to goal), simply by clicking on any of those large-sized metrics at the top of the report. Previously you could only graph conversions. We've had a million requests to graph this other data - now you finally can. We considered graphing all of them at once but they all have vastly different scales and it simply did not work well.
This visit and first visit - Like most non-enterprise level services, Clicky used to only give you this visit data, e.g. data from the current session where the visitor converted. While interesting, most visitors do not convert on their first visit to your web site, so this data doesn't show the long term effects of your marketing efforts - example, which campaign they originally came in from when they bought something two weeks later, or what site they originally were referred by, if any.

And that's exactly what first visit is all about. When a visitor converts, we now look up both their current session and their very first session on your site (that we know about it) immediately and summarize it in a table that lets us generate this report really fast, even over large date ranges. I can pull up this new report for a 30 day date range for any of the goals we track in less than 1 second. Not bad!

Going down these two new columns are five categories (only two are shown here to keep the size reasonable). These categories are campaigns, referring domains, searches, split tests, and goals, which we feel are the most relevant metrics to track in relation to tracking conversions. Previously you could see this data if you filtered your visitors by a goal then chose the appropriate segment, but we wanted to bring these important metrics front and center and make it load super fast.

Trends are also shown for all data types in this/first visit columns, and you can of course click the red/green percentage next to any of them to graph historical data just like you can with any other report. Of note however is that we've only been tracking this data for 3 days, so there isn't much history yet.

New visitor details page

The old visitor details page did the job, but I used to refer to it as Old Betty if that tells you anything about my feelings towards it. I wanted to make it look nice, and add way more details to it. So... I did!

Jam packed with details - Click here to see what this report used to look like, for the same visitor. There used to be a lot of wasted white space, with things like one line for browser, one for OS, and one for screen resolution. These are all related, so why not group together? Same with hostname/org, IP + ARIN/RIPE lookups, etc.
All time goals - Everytime a unique visitor completes a goal for the very first time, we've logged it to a table for over a year now I think. This was originally so we could calculate the time to goal and visits to goal metrics, making sure we were only counting each person once per goal. While making this new update, I realized how interesting this data could be. I can't believe we've had it for as long as we have and never shown it to you like this. So, that's what this is. Every unique goal that this unique and beautiful snowflake has ever completed is shown here, in chronological order, with the date shown next to each one. Clicking on that date will take you to the session where they completed this goal!
This visit / first visit - Just like the new goal report, we also show this kind of information in the visitor details pain now. So now whenever you're viewing the details for any of your visitors, you can immediately see interesting details from their first visit as well - including how long ago it was (in this example, 288 days and 15 hours ago). Want to see that first visit? Click on the date. Bam.

Oh, you thought we were done?

New visitors report

Reorganization - If you use goals or campaigns, icons for those were shown near the left for visitors who had either one attached to them. The problem with this is that most visitors don't have goals or campaigns attached, so this added a lot of empty white space in the middle of the report which always bothered me. So, we moved these icons to the very right hand side of the report. (This example is a bit cluttered because I filtered by visitors who had completed any goal, just to make sure there was lots of things to see).
Direct Spy access - In the screenshot above, you'll see a third icon as well next to some visitors. What is this? Oh, it's only the best thing ever! If you're old school, you'll recognize this used to be the icon we had for the Spy report, before we removed the icons because we ran out of space. If you see this eye, that means that the visitor is online now, and you can click the icon to go straight to Spy with this visitor already pre-filtered! (If you don't have a premium account, you don't have Spy, so instead we just show a green dot icon indicating their online status).

(My only problem here is that the eye icon is available as a choice to you when setting up goals and campaigns. So you might want to change that if you're using it for anything, to prevent confusion. But there is no better icon to represent what this new function does, so I had to use it. Had to.)
Quick access to visitor details - So those visitor details I was just telling you about before? Well, there's no need to actually go to the visitor details page anymore, because they're now available directly on the main visitors report. Next to the actions link (e.g. 3 actions), is a grey arrow pointing top right. Click this icon and you'll immediately see the full visitor/session details page in a lightbox without having to go to a new page.

Bonus

The code that generates graphs when you click on a trend (those red/green percentages) was a mess and had been rewritten multiple times in several places for specific functionality. This is called horrible design. I took the time to rewrite it from scratch and it's way smarter and centralized in one place now, as it should be. Previously this code was unable to graph anything that had a parent/child relationship - for example, the this/first visit columns in the new goal report, that data is stored as children of the parent goal. I wouldn't have been able to let you graph this without rewriting this awful code. I really had no choice here.

So what's the bonus? Well, if you use our Twitter keyword monitoring, of course we keep history for all of that data - but we never showed you the trend percentage because we didn't want you to try to click it and have nothing happen (this data is stored with same parent/child relationship in the database). But since that mess is fixed, I have enabled the trends on the Twitter report, including the ability to graph any of them by clicking it. I use our Twitter monitoring a bit obsessively so, considering we released this feature almost 3 years ago, it's about damn time is all I have to say.

One more thing

From a UX perspective, the fact that we graph both hourly and daily data using the same colors is confusing, because we only log some data as hourly, and we show hourly by default if we have it. The only solution I can think of is to have the two types be different colors, but I can't find anything that works with our overall color scheme. We have a heavy emphasis on blue and orange. So I tried changing one of them to orange, and it looked horrible (screenshot). I'm just wondering if anyone has any ideas in this department, because I'm at a loss.

Ok, one more

In development for 2 months now is our path analysis feature. We're still working out the wiggles but expect it to be out within a few weeks and it will make an excellent partner to goals (although of course you will be able to use it without goals).

HAPPY GROUNDHOG DAY!!!

Count your chickens while they're still hatching

Wed, 04 Jan 2012 22:40:02 -0800

About 3 months ago, Google announced that all users logged in to their Google account, their search terms would be hidden from the referrer string when they clicked through. Net result is no trackers can see these search terms (surprisingly, this includes Google Analytics). Google says this is for privacy reasons. That's great, but I've said a thousand times, search analytics is one of the best reasons to run analytics in the first place so it sucks for site owners.

Anyways, the way our code processed blank search terms, they would show up like this:

This has led to a lot of confusion and many people thinking Clicky is broken, because they weren't aware of this change on Google's end (understandable).

Google updated their Analytics product to show the search as (Not provided) if it was blank. We've decided to do the same thing, although we are labeling it as [unknown] instead:

(Update: Per request, we changed this to [secure search] instead)

The main difference though is that this will now show up in your main searches report too. Previously blank searches just weren't logged in there. Now you will see an item for [unknown], and unfortunately it's probably pretty high on the list. For our own stats on getclicky.com, it's the #3 search term, representing about 1 out of every 6 searches.

I wouldn't be surprised if Google made this the default for all searches on Google sites within the next year or two. Hence I say to you, count your chickens etc, because that will be a horrible day for site owners the world round.

At the very least however, I am happy to know that Google is not providing a back door to their own analytics product that allows them to log the searches but not anyone else. That would just be evil, not to mention anti-competitive.

Load balancing the load balancers

Tue, 15 Nov 2011 01:28:14 -0800

Load balancing your load balancers sounds a bit ridiculous but yes, that's what we have to do to scale.

For about three and a half years, we've had a single pair of load balancers. One active, one in hot standby mode to take over if the active one goes offline. It's worked really well, but they were reaching capacity. I've pulled all sorts of tricks out of my hat to reduce excess load, but the time finally arrived where new hardware was the only option left.

So, we just added two more load balancers to the equation. But these new ones are twice as powerful as the old ones, and instead of active/passive pairing, they're both active. This means we have a total of three active load balancers, and these are load balanced with DNS round robin, with DNS monitoring/failover on top of that to quickly and automatically remove one from the pool in case it has a problem. The old ones act as a front for our entire service with a bunch of virtual services running on them, and hence remain paired (keeping them in sync would otherwise be a nightmare). The new ones are just for additional tracking capacity and nothing else though, so this setup is great for us.

Speaking of tracking capacity, this just quintupled it to ~25,000 pageviews/second. Just in time too, because last year, online activity on Black Friday and (cringe) Cyber Monday sent a ton of extra traffic our way and knocked us offline for a bit. This year, we're ready, so bring it!

Something else we just changed today is that the static resources for our web site are no longer hosted on static.getclicky.com. A problem common with many trackers is that their domains are on blacklists of ad-blockers and other privacy software. These days, almost weekly we get an email from someone saying our site looks funny. This is because their browser, or their OS, or their ISP, or who knows, is blocking static.getclicky.com from loading anything, so the stylesheet doesn't get loaded (nor any of the images, javascript, etc).

But we've had a secondary domain, staticstuff.net, that we've used as a generic CDN domain for our white label service for a while now. I had to change a few things around and get SSL running on it, but now that that's done, all assets for our web site (except the tracking code itself) will load from this domain instead. It points to the same servers, but it should bypass 99% of these blacklists because they are almost always based on domain name.

Google search rankings :D

Thu, 10 Nov 2011 22:22:56 -0800

Considering how much Google has been playing the privacy card recently, I'm surprised they do this, but it turns out the referrer string for Google searches typically includes a variable in the URL, cd, which signifies the approximate ranking of the link someone clicked on to get to your site for a search term. e.g. 1 would mean your page was the top result.

We've had requests to parse this data. As of about 20 minutes ago, we are now doing just that! (Pro+ account required).

Note that this is passive, in other words, we only have the data that Google gives us as people click through on search results. We're not scraping SERPs, and we only have this data from Google because they're the only ones who do this. (If any other major engines do it too, let us know and we'll try to add it). If you want scraped results, you should use our SheerSEO integration.

The screenshots below show how we report this data (5 different places - Spy is my favorite). Keep in mind the data shown in these screens is from our own stats and it's only been live for a short time so there's only a few results logged so far. But I took a peak at some super high traffic sites to see what the reports looked like there, and it's awesome.

Also, the ranking numbers you see for any given search are the average of all searches for that term. Not all visitors see the exact same search results! So if you had two people with a search and one saw it at position 4 and the other at position 5, the number reported would be 4.5.

First, rankings integrated right into the main search report:

But of course there's also a report dedicated to just rankings, and in this case, they are sorted from best to worst rank (menu included in the screen so you can see where to go to get this):

We integrated it into the keywords report too, so you can see your average ranking for any given single word. Note that the ranking numbers in this shot aren't accurate, since we're dividing the sum of all rankings for any word by the total number of searches for that word on that day, and since we only have ranking data for 20 minutes so far today, the divisor is out of proportion. Come tomorrow, it will be correct.

We also added it to the dashboard search module:

And last but certainly not least, we put it in Spy, which is my absolute favorite. As live searches from Google stream in, we'll show you the ranking right there (if it's included in the referrer string). You might also notice we're now showing the search in the same way we used to with the old version of spy, where it's a separate string instead of just the full referrer string which is harder to read searches from:

I freaking love this and hope you do too!!

Here's what's been happening

Wed, 09 Nov 2011 01:48:57 -0800

It's been a rough week. I wanted to explain what has been happening recently with our CDN, and talk about all of the problems we've had with CDNs in general. If you can stomach a novel, you'll discover the good news that it's been resolved to the point where we don't foresee any further issues.

The quest

In June, we decided to move away from our home brew CDN and get a real one, because we were outgrowing it and it was becoming a real pain to manage amongst other things.

The main requirement was that we needed support for HTTPS with our own domain name (static.getclicky.com). There are surprisingly few CDN's out there that offer this service without selling your soul and first born child. Most CDN's only let you use a generic sub-domain of their CDN's domain to get HTTPS, such as omg-secure.somecdn.net. This is fine the assets on the CDN are only for your web site, but that obviously is not the case with us.

Literally the only two we could find that offered this feature at a reasonable price were CloudFlare and MaxCDN, so we decided to test these out. We also wanted to try one of the enterprise level ones, just to see the difference in performance. For this we chose the 800lb gorilla that is Akamai.

MaxCDN offers HTTPS for $99 setup + $99/month, on top of the normal bandwidth costs. Very reasonable. The service was perfectly fine, but they only have locations in the US and Europe. This is definitely a majority of our market but we wanted Asia too. Well, they do offer Asia, but you have to upgrade to their enterprise service, NetDNA, for considerably more money. It was still less than what we were paying for our home brew CDN though, so I decided to try it.

This was one of the worst days I've ever had. I didn't know when the transition was occurring, because I had to submit a ticket for it and then just wait. When they finished it, they let me know, but they messed up the configuration so the HTTPS didn't work. (They forgot the chain file. If you know how certificates work, that's kind of important). It was several hours before I realized this however, because DNS hadn't propagated yet - I was still hitting their old servers for a while, which were still working fine. Once I realized there was a problem, the damage had already been done to anyone who was tracking a secure site. Not to mention it completely broke our web site for our Pro+ members, since they get HTTPS interface by default and none of the assets were loading for them. I immediately emailed them to get it fixed, meanwhile I pointed the domain back to our old CDN so HTTPS would work in the meantime. But they never actually got it fixed. I don't know what the problem was, we had a lot of back and forth, but it was clear this was not going to work.

Next was Cloudflare. I'd met the founders at TechCrunch Disrupt the previous September, they're great. Thing is, they're not technically a pure CDN. You point your DNS to them, and then all of your site's traffic passes through their network. They automatically cache all of your static resources on their servers, and then accelerate your HTML / dynamic content. Accelerating means requests to your server pass through their network directly to speed them up, but they don't cache the actual HTML - it just gets to you faster because the route is optimized.

All in all it's a fantastic service, and I'd be all for it, but they didn't (and still don't) support wildcard DNS - which is another do-or-die feature for us because of our white label analytics service. But their rock star support guy, John, told me they could setup a special integration with us where we could just point a sub-domain to them to act as a traditional CDN. Well, it was worth trying because there weren't any other options at this price level, especially since HTTPS only costs $1/month on top of their normal pricing, and they have servers in Asia too. It seemed too good to be true really. How could they be doing this for such a great price and have such good support? I'm pretty sure John doesn't sleep, no matter what time I email him I have a reply in minutes it seems.

Anyways, the service worked great. We had it live for a week or two. At some point there was a problem that caused us to move back to our home brew CDN, although I don't recall what it was exactly. But overall I was happy and planned to test it again in the future, but I still had Akamai to test.

Akamai is what the big boys use. Facebook, etc. I knew it was good, but also expensive. However, I figured it was worth it if the service was as good as I expected it to be. They literally have thousands of data centers, including South America and Africa which very very few CDN's have, and my speed tests on their edge servers were off the charts. Using just-ping.com, which tests response time from over 50 locations worldwide, I could barely find a single location that had higher than 10ms response time. Ridiculous to say the least.

They gave us a 90 day no commitment trial to test their service, which was appreciated. Their sales and engineer team were great. Very professional, timely, and helpful. But man did I hate their control panel. It was nothing short of the most confusing interface I have ever laid eyes on. I had no idea how to do anything, and I'm usually the guy who figures that kind of thing out.

They walked me through a basic setup, but then the next thing I didn't like was discovered - any changes you want to make take 4 hours to deploy. What if you screw something up? That's gonna be a nail biting 4 hour ball of stress waiting for it to get fixed.

I never actually got to really test their service because I was just too scared of screwing it up. A few weeks had passed and I had forgotten how to configure anything. My patience was wearing thin, as our custom CDN continued to deteriorate and I was dealing with other junk too. There's always a thousand things going on around here.

John from Cloudflare continued to email me to ask how our testing was going with these other services. He was confident Cloudflare would meet our needs. I was pretty sure too, just hadn't made up my mind yet. But I decided to go back to them because I didn't have much other choice.

That was early August and, well, we've been with them ever since. No problems at all. Great service. Overall I have nothing but good things to say.

But then...

Well, it turns out there was a problem. A few weeks ago, our pull server (that they pull static files from) crashed, and at the same time our tracking code stopped being served. It was fixed quickly but... How could this be? They should be caching everything from this server, right?

I emailed them about it and they weren't sure how the server crashing would affect cached files being served. But unless the cache expired at the exact same time as the crash, something was definitely up.

I did some digging and finally ended up watching the ifconfig output on the pull server, which shows bandwidth usage amongst other things. We were pushing almost 3MB per second of data out of that thing. Hmm, that doesn't seem right.

I renamed the tracking code file as a quick test, and sure enough, suddenly Cloudflare wouldn't serve it. Put it back, bam, it worked.

Clearly this file was not being cached. But why? Well, it wasn't their fault. The problem was the rather strange URL for our tracking code. Instead of e.g. static.getclicky.com/track.js, the URL is just static.getclicky.com/js. This is one of those Why the hell did I ever do that type things, but is too late to change now with almost 400,000 sites already pointing to it.

I emailed them about this and only then discovered that they cache based on file extension, not mime type or cache headers, which we of course properly serve. I wish I knew this beforehand, but wish in one hand shit in the other, see which one fills up first.

At this point I knew I needed to do something, since this single file was not being cached properly, it relied 100% on the single pull server being online at all times. I should have made it my #1 priority but with only a single 5 minute outage in 2 months, I somehow convinced myself I could think about it for a while. This was a big mistake on my part and I apologize profusely for it - it won't happen again. I could have spent a few grand with Dyn to get failover immediately to give us a safeguard until I found the right (affordable) solution, but I didn't (more on this in a second). I'm really sorry and I won't compromise our reliability like that again. Clearly it was not worth it.

So anyways, the same day I discover this caching issue, the server crashed... again. I got it fixed quickly, and as a quick precaution I setup another server and setup round robin DNS to serve both IPs so in case one crashed, there'd be backup. However there was not monitoring/failover on this config, but if DNS serves multiple IPs for a domain, theoretically the requester is supposed to fall back on the second one if the first one fails. I had never actually tested this scenario, but it was just an intermittent fingers-crossed fix until I got a real solution in place.

And then the server crashed again... and I discovered this did not work as I hoped (surprise).

Ok, so we need failover on this, like yesterday. This is now my #1 priority. Our DNS provider, Dyn, offers this feature, but what I hate about their implementation is the restrictions they place on the TTL (time to live), which is how long DNS will cache a query for. Obviously the TTL should be fairly short for maximum uptime, but the max they allow you to set with failover is 7.5 minutes. And with our level of traffic, this increases our bill several thousand dollars a month which is a bit steep for my liking. Not to mention the expensive monthly base fee just to have this feature enabled in the first place.

The plan

I finally came up with a plan though. I found another DNS provider, DNSMadeEasy.com, that offers monitoring/failover for very reasonable pricing and no restrictions on TTL. I specifically emailed them about this like 4 times to confirm it would work exactly as I expected. However I can't just transfer getclicky.com to be hosted there, because we're in a contract with Dyn (sigh). So I was going to setup a different domain on their servers, and then using CNAME's, point Cloudflare to pull files from that domain, instead of the sub-domain we were using for getclicky.com.

That was yesterday. Great!, I said to myself. I'll set it up first thing tomorrow because it's almost midnight!

And then this morning.......... that's right, the freaking server crashed again. My phone was on silent by accident and I slept in, so for almost 2 hours our tracking code was only being served for about 75% of requests (because DNS IP fallback does work some of the time, it seems). Hence, more problems this morning.

ARGH. I screamed at my computer and just about burned down my house I was so mad. I had come up with a plan that I knew would work and was going to implement it first thing the next day, but the server crashes in the meantime and here I am in bed, blissfully dreaming of puppies and unicorns, unaware of any problems because my STUPID PHONE IS ON SILENT. WHY. ME.

The fix

But the good news is, today, I got this all setup. Monitoring/failover is now live on our pull servers, and they are checked every 2 minutes - so if there is a problem with any of them, DNS will stop serving that IP to Cloudflare within 2 minutes at the most, and I verified it works properly by intentionally killing a server. And the TTL is only 5 minutes, so the absolute maximum amount of time there could potentially be a problem for any individual person is 7 minutes. And we added a third pull server, so at the most this would only affect 1/3 of anyone, and even then, for a maximum of 7 minutes.

(Note: Above I was complaining about Dyn's 7.5 minute max TTL, and here I am with a 5 minute one. Well, this one's a bit different because only Cloudflare's servers talk to it, so the total queries generated are quite small. The real issue is we're also going to be doing this same thing in order to load balance the load balancers (really?), because we're adding two more of them this week. Using failover on this is what would be really expensive, so we're avoiding that by using another DNS provider for it, and we figure we might as well do all of that monitoring and failover in one place. Load balancers are stable and reliable, so the TTL will be a bit higher - and even if not, their pricing is considerably cheaper than Dyn's, so it's all good).

On top of all that, Cloudflare desperately wants to fix this caching problem on their end too. (I say problem in quotes because their service is working exactly as they designed it to work, I just didn't know ahead of time that caching was based on file extension only). They are working on a solution that will allow us to rewrite URLs on their end so that their servers will see the tracking code file as something that ends with a .js file extension and hence cache it properly, without us having to make any changes on our end. Once that's live, even if all 3 of our pull servers were offline (knock on wood), it should have zero impact because that stupid legacy URL file will be actually be cached!

In conclusion

So that, my friends, is as short a summary as I can write about everything we've been through with CDNs.

And on top of all this, we also made an update to the tracking code on Nov 1 that caused issues for some of you. This update has been reverted but that was the last thing we needed with the CDN also causing issues at the same time. [Update: And there was a small network hiccup at our data center on Nov 9 that caused a short outage. Worst week ever.]

So I don't really feel like we have earned your money this month (and to think, it's only the 8th...) If anyone wants a refund, send us an email we'll happily refund you a full month of service.

No matter what, know that I value the quality of our service above anything else and will always do everything in my power to make sure it works flawlessly. This has been a horrible week, but as of now the CDN should not impact anyone.

Thanks for reading and (hopefully) understanding.

iframe tracking, copying dashboards, Google search encoding, etc

Tue, 01 Nov 2011 13:05:31 -0800

It's new feature Tuesday!

Better iframe support

A common problem we have is that people can only install the tracking code inside an iframe, but they want to track the parent document, not the iframe. But unfortunately this only tracks the iframe itself. Now I know there are plenty of people who want to track the iframe specifically, but there are way more people in the other camp. So now, by default, our tracking code will detect if it's in an iframe and use the parent documents URL and title instead of the iframe's. This is already what most other services do by default.

There is a way to override it though if you are actually wanting to track the iframe on purpose, via the new clicky_custom.iframe property.

[Nov 3 update: This change may have caused general tracking problems for some sites. We tested it, as we always do, against all major browsers before deployment and it worked fine, but something with it is causing problems for some of you, so the change has been reverted. We will look to add it back in the future.]

Copying dashboards between sites

If you have a bunch of sites, you may have created the most awesome amazing customized dashboard ever. And then you have to recreate it for every site in your account. So fun!

Well, now when you go to your customize dashboard page, there will also be a list of all the dashboards you've created for your other sites. One click and bam, that dashboard is now copied into the new site. After it's copied you can edit it if you want, or just leave as is.

Google search encoding

Some change Google made to their URL structure is resulting in double URL encoding, and you might be seeing searches+like+this instead of searches like this. It's not just affecting us either, I checked my Google Analytics account (gasp!) and was seeing the same thing. As of today, we now just double URL decode all searches before storing them, so this problem is history. I imagine Google will fix it on their end eventually but patience is not one of my virtues.

Black nav bar

We know some of you don't like this but we feel it's important to have these links highly visible and easy to find. If you stick something in a footer, no one clicks the links because no one sees them. Two designs ago, when we actually had a footer, as soon as we moved a bunch of those links into the sidebar we added, the number of clicks each one was getting skyrocketed. I'm talking 10-20x as much activity. That's a good thing.

But anyways, today, I reduced the padding so it takes up a bit less space, and also removed the position:fixed style rule so it's not always on the screen, instead it's only visible when the page is scrolled up all the way. I hope that appeases some of you to a small degree at the very least.

More ways to view hourly data... and more!

Thu, 27 Oct 2011 16:46:52 -0800

We just deployed a bunch of changes to hourly data, amongst other things:

Goals and Revenue now support hourly data, so you can more easily see your best converting and most profitable times of day. However, we just started doing this today, so earlier dates will not have hourly data.

Anytime we add hourly support for something, it essentially require 24x as much storage space, which is why we only do it for a few types of data (currently: visitors, actions, tweets, clicky.me short URLs, goals, and revenue). If you saw how big our databases were already, you'd cry and then realize why this is necessary.
Hourly averages - there are three new options in the drop down menu for hourly graphs:
- Same day of week average - example, this Monday vs the average of the last 4 Mondays
- Weekday average - Today vs the average of all weekdays (Monday-Friday) from the last 4 weeks
- Weekend average - Same as Weekday average but for Saturday/Sunday only
These are all insanely useful, particularly the first one!
You can set same day of week average as your default trend comparison in your dashboard preferences, in which case your hourly graphs will also default to displaying this mode. We initially coded in support for weekday/weekend stuff too, but they generated WAY too many queries; there were up to 20 extra pieces of data that needed to be pulled from the database for each item in any given report, and it couldn't be optimized since there are holes in the date ranges.
Daily graphs default to 28 days instead of 30 days, to more cleanly fit week boundaries. We think you will find this especially useful when comparing vs previous period. An example is shown on the right.
Compare menu fixes/additions - When viewing daily graphs, the Compare... menu has been broken for a while now. Not sure when it happened but we finally got it fixed. We also added some more options to it that were much needed (revenue, goals, campaigns, pages, and tweets, to name a few).

24-hour time formatting and smarter defaults for new sites

Fri, 21 Oct 2011 14:42:47 -0800

We have finally added a 24 hour time formatting option, so you'll see e.g. 15:30 instead of 3:30pm. This change should affect everywhere you see time within a site's reports, but if we missed something, let us know. You can change this setting in your site preferences.

The defaults when registering a new site also just got a lot smarter. Those of you with lots of sites probably get annoyed with how many preferences you have to change every time you register a new site - particularly if you are not on the west coast of the US. Now, any time you register a new site, we'll grab the following preferences from the last site you registered and make them the default for the new one (which you can of course change if desired):

Time format (12/24 hour)

Time zone

Daylight savings

Anonymous IP logging

Hide hostnames in visitors list

Hide ISPs

:D

utm_custom: a new URL parameter to attach custom data to visitors

Thu, 20 Oct 2011 19:41:41 -0800

One feature that gets requested a lot is to be able to set a variable in the URL that could then be attached to the visitor as custom data. This would be particularly useful for things like email newsletters, so when someone clicks through, they can be identified automatically.

The variable name needed to be generic because of our white label program, and since we pictured this being used with campaign activity more than anything else, we decided to call the variable utm_custom (related to Google/Urchin's utm_campaign etc variables).

You can see full documentation here. Because custom data requires a Pro or higher account (upgrade), this variable will also only be processed if you have a Pro or higher account.

utm_custom is an associative array so you can set multiple key/value pairs on a single page. (It must be an array with at least one key/value pair, or it will be ignored). For example, if you sent a visitor to this page:

http://yoursite.com/landing/page?utm_custom[username]=Bob+Jonesutm_custom[email]=bob@jones.com
utm_campaign=Email+blastutm_content=Oct+20+2011

You would see this in your visitor's list:

And this when viewing visitor/session details:

We've had requests for this countless times over the years so we know many of you will find it quite useful :D

SHUT. DOWN. EVERYTHING.

Thu, 29 Sep 2011 13:59:18 -0800

Hmm... did anyone actually read the announcement that Google made today? This isn't real time Google Analytics, this is a single report in GA that is real time. The rest of GA remains the same. This is more akin to Chartbeat, to be used as a real time compliment to a standard analytics package, rather than a full standalone real time service like Clicky is. But I guarantee you Chartbeat will be just fine, as will everyone else. We've all had, and continue to have, plenty of advantages over GA other than real time data.

If anything, I'm glad Google has done this, as it will bring more awareness to the concept of real time web analytics in general. This will inevitably lead to more people searching about it, and we just so happen to have the #1 organic result for this search on both Google and Bing (and hence Yahoo). Everything is going to be just fine!

Multiple dashboards and custom dashboard modules

Wed, 21 Sep 2011 15:10:39 -0800

Paying members can now create up to 5 unique dashboards for each site, allowing you to have multiple birds-eye views of your analytics - all a click a way in the sidebar (as seen to the left).

This is especially handy because you now have the ability to create your own dashboard modules. For example, if you want to see both top countries and top cities at the same time, you could create two new boxes, each one having one of these pieces of data. Previously, dashboard modules were categorized, so you could only view countries OR cities, but not both at once. You can add more than one data type to each module too:

And a much requested feature is the ability to assign a default dashboard to each of your sub-users. This allows you to create things like boss mode, where he will see only the things he cares about, but you, the analytics junkie, can see everything you want.

New option to anonymize IP addresses

Fri, 26 Aug 2011 12:28:23 -0800

We just added a new site preference to log IP addresses anonymously, which takes the last octet and changes it to 0. For example, 123.123.123.123 would become 123.123.123.0. And we're not just hiding the last octet from you - we remove it before storing it, so it should comply with laws in places like Germany where it's technically illegal to log the full IP address of a visitor.

This preference is available to all users. You can find it in your site preferences, under advanced.

BREAKING: TWITTER'S INFLUENCE IS NOW ZERO. FACEBOOK WINS. ALL HAIL THE ZUCK.

Sat, 20 Aug 2011 10:49:05 -0800

The media loves to hate Twitter when it comes to measuring their influence, or how many people click links shared on Twitter. Even when they state the obvious reasons (HTTPS sends no referrer, 99% of people use Twitter apps which also send no referrer, etc), they brush them off and pretend no one uses Twitter.

I'm not here to defend Twitter, but they just made a big change that almost 100% guarantees headlines like the one we're using here.

What am I blathering on about? I can't exactly tell what Twitter changed, as I never paid attention to t.co really, but either they finally started actually routing every link through their shortener, t.co, or they changed the way t.co redirects. The bottom line is this: you will pretty much never see a single referrer from twitter.com again. Instead you will be seeing t.co. (At least from non-Clicky analytics services - more on that in minute).

The reason is because of the way t.co redirects. Instead of using a 301 redirect, which every shortener should do, they are using a combination of a META redirect and Javascript to send you on your merry way. If you click a t.co link and hit escape really fast, your browser will pause on that page, allowing you to see the source:

noscriptMETA http-equiv=refresh content=0;URL=http://www.addedbytes.com/blog/if-php-were-british//noscriptscriptlocation.replace(http://www.addedbytes.com/blog/if-php-were-british/)/script

The problem is that both META redirects and Javascript redirects overwrite the original referrer. The referrer becomes the page with that code on it. Hence, no more twitter.com referrals, because every single link passes through t.co now.

Here are screenshots of our 30 day history of referral traffic for twitter.com vs t.co. Notice the last 3 days, twitter.com is zero, and t.co has come out of essentially nowhere:

What to do?

We just updated Clicky to convert t.co referrers into twitter.com automatically. Knowing the specific t.co link someone came from has no value, but knowing someone came from Twitter does. No other analytics service has done this yet that we know of, so as usual our tiny size lets us move lightning fast to address issues like this.

[Update: ok, we changed it back. See comments.]

But wait there's more! There's a damn nice silver lining here. The main reason twitter.com doesn't show up as a referral much, even before this change, is because so many people use apps instead of the actual twitter web site. When you click a link in an app, that app passes the URL to your browser, which then opens it - but that means no referrer.

However, now that all links are being passed through t.co, and this happens via the API as well (I confirmed via our own Twitter keyword monitoring feature), this means that even people who click links from apps will be passing through t.co first. If we automatically convert t.co links into twitter.com in the backend, this means we will be able to give you a MUCH more accurate picture of Twitter's traffic to your web site. (We just pushed this change so we can't guarantee this will be the case, but based on what we've analyzed, if you use Clicky you should start seeing a huge influx of twitter.com referrals).

This may even be the reason that they're doing redirect this way, because they're sick of the uninformed media saying they have no influence. By having a ton of t.co hits suddenly showing up in referrer logs, maybe the media will consider what that means. Doubtful, but one can always hope.

JW Player tracking, and other recent changes

Tue, 16 Aug 2011 11:26:15 -0800

Since we released video analytics last year, the number 1 request has been to add a library for tracking JW Player. Well, we just did that. You can find it on our video help page.

We've also been fixing a bunch of bugs recently, and adding a few minor new features. We don't normally make a blog post just for this type of junk, instead preferring to piggyback on top of another post, so here we go:

- NEW: Checkbox on the tracking code page to disable affiliate badge (for paying members)
- NEW: Email reports are now in your selected language, instead of English for everyone.
- NEW: go.mail.ru is a search engine, not a web mail domain - yes, we hear you :)
- FIXED: Tracking code pings now end at 10 minutes as stated in the docs, rather than 8 minutes and 40 seconds (this was a math fail on our end)
- FIXED: The Flashy widget was broken.
- FIXED: After editing site prefs, you may have seen a message about your site being disabled.
- FIXED: Y-axis text in charts was getting truncated for values over 6 digits.
- FIXED: Loading a site, changing to a different site, then choosing Bigscreen would load that for the FIRST site.
- FIXED: Non-paying users who use our Wordpress plugin, viewing stats within the WP admin area didn't count as a login so they were getting disabled after 60 days of no logins. Now we count that as a login, even though technically it is not, to avert this problem.

Major updates to alerts, goals, and spy

Tue, 09 Aug 2011 15:08:25 -0800

We've been working on a gigantic update to alerts, goals, and spy, and here it finally is. The most major update is to alerts, so we're pulling that out of the blackhole that is your site preferences and putting it front and center, as you can see on the right.

So what's new? Here's what the alert setup page looks like now, which should give you a nice overview of everything that's new:

Let's start with the new ways to be notified: Desktop, Sound, and ClickyTouch (our official unofficial iOS app). These are in addition to the previous methods, which are Email and Twitter. Any alert you setup can use any combination of these 5 methods, including all of them, so it would be pretty much impossible to miss an alert if you set it up right!

Desktop alerts - You may have seen some web apps using Google Chrome notifications (Tweetdeck, Rdio, etc). We explored this option, alongside using jGrowl for other browsers, but I'll be honest: The Chrome notification API is horrible and has very limited options and functionality. It's nice you can see them without having to have the browser in focus, but that's the only nice thing about them. So, jGrowl for all. (I'm aware the screenshot above mentions the ability to enable Chrome alerts - it is from a few days ago when that feature was still in place, so the shot is simply out of date and I'm way too exhausted to make a new one - sorry!)

Desktop alerts will appear in the bottom right corner of your browser window. Here's what they look like:

At the top is the alert name. If there's any revenue associated with this alert (from a goal), that will shown on this line too. Next line is brief details about the visitor: country, then IP tag OR custom->username OR organization OR IP address (in that order of preference), then their referrer. The last line is a link to view the session immediately on Clicky. And on the bottom right is a mute link, which is handy when you just want some piece and quiet to browse your stats. When alerts are muted, there's a sticky box in the bottom right corner (which you can see in the setup screen above) informing you of their muted status, with the ability to unmute them.
Sound - These add a lot of personality to alerts, and allow you to know an alert has been triggered even when you're looking at another tab or doing something else on your computer. Example sound: Cash register - perfect for goals where you make money! There's a total of about 20 sounds available.
ClickyTouch - The icing on the cake. ClickyTouch is a third party product for iOS that uses our API to give you a nice interface for Clicky on the go. We worked with Steve (the developer) to integrate push alerts into the app. So if you have ClickyTouch installed and check this box for an alert, you can get alerts immediately on your iPhone or iPad, wherever you are. And if you view the alert, it will pop open ClickyTouch and show you the visitor session that triggered it.

Important - to receive alerts on ClickyTouch, you must update to 1.5.2, which was just released in the app store alongside this release.
Email and Twitter - These are the original alerting methods we've had for over a year and they still work the same way. You can receive alerts via email or Twitter direct message. To get alerts via Twitter, you must be following Clicky on Twitter.

In addition to these new methods of being alerted, we've added two new types of alerts:

New visitors - This is an extension of new visitor sounds in Spy we added a few weeks back. That method only worked in Spy. This method works no matter what report or page you are viewing. But the option to toggle it on and off is still available in Spy as well. If you enable it via Spy, by default it will only be the traditional ding sound. But if you set it up in the alerts area instead (or edit it after enabling via Spy), you can have it to a desktop alert also or instead. To ensure we don't inadvertently hammer third party mail servers and APIs, this alert ONLY works with sound and desktop - the other three options are disabled.
Custom data / IP tags - We've had countless requests for alerts for when a specific visitor is viewing your site. This is the answer to that. Any visitor that you have named with IP tags, you can now create an alert for them. Even better, if you use our custom data tracking API (and if you're not, you're crazy - it's our best feature), then you can trigger an alert for ANY custom data that you add to a visitor session.

I want to talk more about desktop and sound alerts for a minute. To be clear, since these are integrated into the web site itself, these only work when you have our web site open. But if you're anything like us, that's pretty much 24x7, so no biggie, right?

Depending on how many alerts are queued up to show you, they are visible for either 6 seconds or 10 seconds. We only do one at a time though, so as long as there are less than 6 queued up (and 99% of the time, that should be the case, unless you are insane), then they'll be displayed for 10 seconds. Originally it was 6 no matter what but I found myself racing to find what an alert was for if I wasn't looking at the site when I heard the ding, so I decided it was much better to have them visible for a longer period of time when there's only a few to show.

When you are viewing reports for just one specific site (e.g. whenever you're inside the /stats/ directory), you will only receive alerts for that specific site. But if you are anywhere else on the site - user homepage, help, contact, etc - then alerts for ALL of your sites will be active. And in this case, we append the site's name to the end of the alert title, so you know what site it's for, as can be seen here:

Goals

We cleaned up the goal setup page quite a bit, so only the basic options that most of you need are up top, with the rest in the advanced section. And as you can see by this example alert name, we now allow global wildcards, meaning the entire goal can be just a wildcard. In this case, ANY page view will trigger the goal. You can do the same thing with funnels, as well as search and referrer alerts (which are different from the ones in goal, because in goals they can only be funnels. This is perhaps another area we could clean up a bit. It would be nice to setup a goal for a specific search instead of only being able to use that search as a funnel).

You can also see that we've added a shortcut to create an alert for a goal as well after you've saved it. This takes you to the alert setup page, with the alert name prepopulated to match the goal name, and the goal alert type with the proper goal preselected.

Spy

We spent a LOT of time integrating all of this new alerting into Spy as well. Not many of you know this but Spy is essentially a completely different product from the rest of Clicky. It is a true live stream of people browsing your site, whereas the rest of your reports are updated once per minute in batches using this same data. So, to make sure the alerts in Spy were triggered at the exact same time you see a visitor performing something in Spy that should trigger an alert, we had to write another entirely new version of the whole alerting system in Javascript - just for Spy. These alerts don't show the visitor details in the actual alert box though, since those are shown on the Spy page itself at the exact same time.

But wait, there's more! We thought it would be quite nice to actually highlight the goals in Spy as well. As you can see here, the row is highlighted, and the goal icon you chose is on the right hand side:

This was also quite a bit of work, because again, we had to rewrite the goal code in Javascript as well. I love me some Javascript but this was ridiculous. One of our developers, this was 95% of his time on this project over 2 weeks - processing goals and alerts in just Spy. Dynamic goals, manual goals, funnels, more than once goals - it all works. The only thing that doesn't work are campaign funnels, because of various challenges we encountered when trying to implement them.

Desktop and sound alerts work the exact same way here as they do in the rest of Clicky, so I'm not including a screenshot of that here.

What about Bigscreen?

You don't think we'd leave one of our newest most popular features high and dry, do you? That's right, alerts even work in Bigscreen, as you can see below. We made the fonts extra big so you could read them from afar. The alert visible here is the new new visitor alert, mentioned above. As you can see, no visitor details are shown. I wanted to touch on this briefly. The reason is because there may be 100 new visitors every minute, so this is more of a batch alert. In other words, you can read it as 1 or more visitors have arrived since the last time you saw this alert. Because of this, it is a bit generic. Maybe we'll clean that up a bit in the future but for now, this made sense.

We've tested this very thoroughly but we do expect there to be some minor bugs, especially with the Spy stuff. So let us know if something doesn't work like you expect it to.

Last, when creating alerts, there's up to a 30 minute delay before they are fully active within the system, so be patient -- and enjoy!

Update

Yes, there were some bugs. Just pushed an update that fixes them. Changes:
- FIXED: Spy was showing URL instead of Title in the top right content box
- FIXED: Unmute alert box was MIA because of last minute change to the way it works that wasn't fully testing before deploy
- FIXED: global alert bombardment when leaving /stats/ - now, all alerts are reset when you go to a non-stats page so you'll only get new ones that occur from that point onward.
- FIXED: clicking an alert URL was supposed to load via Ajax, but was not because of, well, it was dumb let's just leave it at that.
- FIXED: Minor goal processing bugs in Spy
- NEW FEATURE! You can use wildcards in the custom data alert type, including a global wildcard * to match a visitor with that variable of ANY value, e.g. username=ANYTHING.

Important change to goals

Mon, 25 Jul 2011 14:27:24 -0800

Goals have always been exact match by default, and only used any kind of wildcard matching if you specifically added that in. We thought this was the best way to do it but over the years, we've found that the vast vast majority of support requests that have to do with goals are because the user is not using wildcards where they should, usually on the end of the string.

For example, a user might enter /thankyou.php as their goal URL, without realizing (or simply forgetting) that these types of pages typically have query parameters too. Then their goal wouldn't work, so they'd contact us, and adding a wildcard on the end was almost always the only change needed. Sometimes a wildcard is needed at the start though as well, but usually just the end.

So, as of now, all goals by default will be processed as if they had a wildcard at the start, and at the end. We know this won't work for everyone of course, so we added a new checkbox to the goal setup page called exact match. This will force the old behavior, but it is off by default (based on our analysis of how you have setup goals, very few of you will need it). We also expect quite a few people who setup goals but they never worked to suddenly find them start working as if magic has occurred.

While we were at it, we also fixed a few long outstanding bugs: https:// goals used to not work, and depending on how goals were setup, sometimes they were case sensitive which was quite obnoxious. These are both fixed.

PDF export for all reports

Thu, 21 Jul 2011 15:50:06 -0800

Short and sweet:

Spy preferences and sound effects

Wed, 20 Jul 2011 17:46:31 -0800

When you set various options in Spy, such as zooming in the map or disabling the popups, used to be that it wouldn't remember any of it next time you came back. Fixed that! We store your settings in a cookie so they'll be restored everytime you visit Spy (on the same computer/browser). This is a Clicky-wide setting too, so any site you're looking at or any account you're logged into from the same computer - bam.

We've also added a request we've had more often than we would expect, which is having a sound effect play when a new visitor arrives. This is of course DISABLED by default. This feature will mainly be of interest for lower traffic sites, who don't always have visitors online, but would like to know immediately when someone shows up.

The HTML5 audio element is being for this (yay, no flash needed!), and we have both mp3 and ogg formats so the sound will play in all five major browsers. Of course you will need a browser released within the last couple of years for it to work, but thankfully our userbase is quite good at abandoning old, depressing technology. For example, less than 0.5% of you are still on IE6 - that's way better than average! It's because you are SO AWESOME!!

PDF email reports!

Tue, 19 Jul 2011 16:20:19 -0800

Now that we ditched Flash, we can make our email reports a bit more exciting by making them look exactly like our web site. If you edit an existing report or go create a new one, there are now checkboxes to choose the format(s) you want, which can be any combination of plain text, HTML, and/or PDF.

A PDF report for any site is essentially an export of that site's dashboard. We chose to do this rather than the specific data types you selected for the report because the point here is to make the report look like our web site - including the new graphs. Your dashboard is meant to be your one stop customizable overview of your site's traffic, so it makes sense to use it for the PDF report. The data type options in the email report interface (which are still available, and still used in the text/html versions) are there because we used them to create a new display of your site's data designed for email. Now that we can just use a replica of our web site, that's what we're doing with the PDFs.

One thing we'll also be adding in the near future is the ability to be viewing any report and just export it to PDF immediately - like you can currently do with CSV/XML exports.

Click here to view a sample PDF report

Extreme database maintenance this weekend

Fri, 15 Jul 2011 10:50:31 -0800

We typically only do maintenance once every couple of months and only to one or two servers at a time, but this weekend will be pretty ridiculous.

The database servers listed below will halt traffic processing for up to 10 hours this weekend while we perform some necessary maintenance, starting either Friday night (if I get it ready in time), or Saturday morning. (This is US pacific time, GMT -7). When the maintenance is done, they will all have a large backlog of traffic to process before they are caught up with real time again.

(Spy will still working during this time, because it is an actual live stream of data as it comes into our tracking servers, rather than using the database. So if you have a paid account you can still keep up with basic stats via Spy during the maintenance.)

These are mostly older servers so most sites registered within the last year or so should be unaffected. The exceptions are db27 and db33 which are less than a year old. These servers have quite a bit less data than the other ones though so their maintenance window should be quite a bit shorter.

To determine which database server a site is hosted on, take a look at the preferences page for that site.

Affected database servers:
1 - 11, 15, 17, 18, 20, 21, 23, 27, 33

No more Flash!

Wed, 13 Jul 2011 09:04:22 -0800

We have converted to a native graphing library (Highcharts) that works on almost every platform, including iPhone and iPad. It loads faster and it looks good. The graphs look and feel the same as the old ones, so other than the fact that they will now work on your non-Flash devices, you can barely tell the difference:

Bonus: this will finally allow us to send PDF email reports. In fact, those have been under development for about a week now, alongside this. They're almost done... we were planning to release them at the same time but a few last minute issues dashed those hopes. Tomorrow, perhaps.

The only bad thing about Highcharts is that it doesn't (yet) work on Android, because Android doesn't support SVG. The next version will supposedly have SVG, but in the meantime the developers are working on an update to make this library compatible with this OS, as can be seen on github. For now, Android users will see the old school bar graphs instead. (I'm an Android user so yes I take this problem quite seriously.)

Ok, so we do have one last piece of Flash left on our site, that being the maps you see in Locale->Global map. If anyone knows of a similar non-Flash library, do share.

On demand email reports (PDF's coming soon)

Wed, 22 Jun 2011 17:40:54 -0800

In your email report area, there is a new option to send now next to any of your email reports. Going here will let you send a report immediately, instead of waiting for the next day/week/month. You can choose a custom date range for the report, and enter in different email addresses than the default. These will be inserted into a queue, which will be processed once per minute, so you should receive it within a few minutes of requesting it.

We are also investigating native graphing libraries, such as highcharts, to replace our flash-based graphing system. Once this is in place, we will be adding PDF as an attachment option to our email reports, which will essentially be screenshots of how your reports look on the web site (minus the sidebar). This of course also means that the graphs will work on all modern mobile devices. Really, that's the main motivation to move to such a system, but having them in the PDF reports will be a nice bonus.

Big screen mode + faster page loads

Mon, 20 Jun 2011 12:45:11 -0800

We're testing a new feature we're calling Big screen, which is a self-updating, single page report highlighting your key metrics, designed for that giant plasma hanging on your office wall. It looks radically different from the rest of Clicky, because we felt a dark theme made more sense for this type of feature.

It grows and shrinks with your browser window, up to 1080P. Our developer also made sure it looks awesome on the iPad and iPhone - yes, including the graphs.

For now, you can find it in the sidebar menu when viewing your reports, although I'm not sure that's the best place for it. I'm thinking it would make more sense to launch it from the user homepage. So it may move around on you. Really, we just wanted your feedback on the feature itself before we finalized anything, and we figured more of you would see it if it was in your site's sidebar menu. Let us know what you think.

It is available to all users right now but will become a Pro-only feature by the end of the week.

Faster page loads

Our aging web server has been replaced by a server that I was guessing beforehand to be 100x as powerful as the old one, and it turns out I was almost exactly right. The 15 minute load average on our old server was typically between 5.0 and 7.0 during peak times. The new server is between 0.05 and 0.10 during the same hours. It's a beast.

The result of this is much faster loading times across the board. The only thing that's still very database heavy/dependent is filtering visitors and/or large date range reports. Those will still load faster, but since the total loading time may be a bit long either way, the improved performance won't be as noticeable as the rest of the site.

Better bot protection and backups

Fri, 10 Jun 2011 20:19:45 -0800

Two complaints we receive fairly often are that too many bots get logged, and backups on Friday night are annoying. Well here I am on a Friday night letting you know that things are looking up!

Bots

Let me first be clear that this problem is not unique to Clicky. Most bots don't interact with Javascript, so most are not logged by Javascript-based trackers. We also have a fairly big regular expression that aims to filter out any that do the Javascript thing, and it works pretty good. I think we are definitely one of the best at filtering out bots already, but the complaints keep coming in. People see it as a defect of Clicky, even though it affects every tracker. And the bots keep getting trickier.

Both Microsoft and Google have started sending out bots in disguise in the last year or two, the theory being that they're ensuring your content doesn't appear differently if your web site thinks it's a regular visitor instead of a crawler. These bots have real user agents so you can't tell they're bots. However, a few people pointed out something unique - their user agent is always Windows XP / MSIE 6.0, and they always report a screen resolution of 1024x768. That alone is not enough to filter out a visitor - chances are good someone on IE6 has a real dinosaur of a computer on their hands - but since Clicky tracks organizations, we can dig deeper. When we look up the organization info for these visitors, if it's Google or Microsoft, we can be 99.9% confident this is definitely a bot. (Because if either of these extremely rich companies still seriously have computers this horrible that are used by employees... well, they should be sued).

The problem was however, we didn't look up the organization of a visitor until after that visitor was inserted into the database. But tonight, I re-arranged some things, and now we check for those three unique factors - XP, IE6, 1024x768 - before inserting into the database. If we have a match, we'll look up the organization immediately and pull a little preg_match(#(microsoft|google)#i, $organization) magic out of our hats, and if it returns true - BAM. Not logged.

There will still be bots who sneak through, I'm sure of that. However, Google and Microsoft seem to be the biggest problems, and I've never seen what was obviously a bot from either of them that did not have XP / IE6 / 1024. They might update that in the future to make our lives more difficult again, but for now I'm confident this will eliminate almost all of the bots that we log that shouldn't be getting logged. Yay!

Backups

We do full database backups every Friday night starting at 10pm PST (GMT -7), during which traffic processing is halted. As the databases grow in size, these take longer and longer. We were investigating improvements to this process earlier this week, and I realized I was not setting a flag that would basically cut the time needed to do the backup in half. This was a horrible oversight on my part but I'll own up to it, and this has now been fixed. Most databases complete their backup in 1-2 hours, but some that are 3-4 years old were getting near the 4 hour mark. Now, the max any of them should take is about 2 hours, and most should be an hour or less.

But wait, there's more! We're going to be moving to a new database engine in the near future (goal: 3 months) that will be much more backup friendly. We won't have to halt processing at all while the backups are taking place. That will be a nice change. ^_^

Good night!

Clicky is a launch partner for CloudFlare Apps

Wed, 25 May 2011 10:35:03 -0800

We met the CloudFlare team while we were at TechCrunch Disrupt last September, and we think their product as well as their co-founders, Matthew and Michelle, are awesome! CloudFlare was runner up for best startup at the conference, and they've been growing leaps and bounds since then.

CloudFlare sits between your web site and the internet, making it faster by acting like a CDN for your entire site, and more secure by blocking evil bots and the like. The original article on TechCrunch summarizes what they do quite well. CloudFlare is completely free to sign up for. They have paid upgrades with additional features, but there aren't any limits on free accounts for things like how much traffic you have. So if you think your site is slow, we wholeheartedly recommend trying them out.

This morning at TechCrunch Disrupt NYC, they announced their latest initiative, called CloudFlare Apps, which launches on June 1. It's launching with 20 services, and Clicky is one of them.

CloudFlare's users have asked for a realtime analytics solution since we launched, said Matthew Prince, CEO and co-founder of CloudFlare. Rather than reinvent the wheel and build our own, we are proud to offer a great solution like Clicky that lets any website owner see who is on their site as they click from page to page.

A common problem for many web services like Clicky is that people need to copy and paste code onto their site to start using the service. CloudFlare is trying to solve this with their new Apps service, which allows anyone using CloudFlare to install web apps like Clicky with a single click of their mouse. We get a lot of emails about this from new users, so it's a very real problem, and we think this is a great solution.

How do they do it? CloudFlare serves all of your web site's traffic, so they can automatically insert additional code into your HTML as it travels through their servers. So if you opt in to Clicky, they'll add our code at the bottom of all of your pages automatically as each one is served. And if we ever update the format of our code, CloudFlare will update it too, ensuring you always have the latest and greatest.

We think this is fantastic in all regards, so we're really excited to be a launch partner!

UPDATE! Someone tweeted that they were excited about this partnership because it meant they could finally use Clicky on their Posterous blog, which currently only allows Google Analytics in terms of Javascript tracking. We hadn't considered this, but the potential here is really great. There are tons of hosted services out there that don't allow you to add third party Javascript to them, but as long as you can slap your own domain on top of it, you'll be able to do this with CloudFlare. Very cool!

Facebook referrers update

Fri, 20 May 2011 10:19:12 -0800

A request we've had quite a bit is to show the actual page that a visitor has come from on Facebook. It's not that we were trying to hide it in the first place, it just didn't show anything beyond facebook.com. We decided to dig into this further today.

When you post a link on Facebook, whether it's in your feed or on a fan page, Facebook makes that link go through a redirect script first. There are several good reasons for this that I can think of that benefit both Facebook users and Facebook Inc., but we don't need to get into that right now. All that matters is any link that someone clicks on Facebook to an external site goes through their redirect script first.

Browsers normally keep referrers intact through redirects, but Facebook is doing something different. They are using Javascript to call document.location.replace() to send you on your merry way. This method works the same as if this intermediate page instead had a link to click on, and that link sent you to the external page: the end result being that this intermediate page becomes the referrer.

Out of curiosity, I wondered if you had Javascript disabled, since this intermediate page appeared to only use Javascript and no other method of redirect. Well, turns out with Javascript disabled, the links on Facebook actually point directly to the third party page. But... sigh... without Javascript, Clicky can't access the referrer at all.

So I hate to be the bearer of bad news, but it looks like what we have now for Facebook referrers is the best we're going to get. If you know of an analytics service that through some minor miracle actually gives you referrer data from profiles or fan pages, let us know, but I'm pretty sure it's impossible. Sorry!

The user experience and psychology of color [FIXED]

Wed, 18 May 2011 22:17:11 -0800

One of my most favorite articles ever written about Clicky is this one, which might seem entertaining at first glance, because it's basically ripping us a new one for a design decision I made almost 7 years ago (pre-Clicky) and that I have stuck with ever since. What decision is that? That whenever I want my software to give you any kind of feedback, whether good or bad, that it will be displayed in SKULL-MELTING BOLD RED.

Now of course, I know that people associate red with bad. For example, You totally forgot to fill out a field! Nice going!. But I make web sites for a living, and while I consider my attention to detail to be off the charts, I have caught myself missing messages all the time that random web site X is trying to share with me, because the message doesn't BURN MY RETINA.

So what about Joe Sixpack? How many of these messages is he missing? Considering my background, I would guess he misses a lot more of them than me. And since these tend to be important things, the fewer he sees of them, the more confused he's going to be. And what does confusion lead to? Tech support! Now don't get me wrong... of course I'm absolutely not saying anything negative about anyone who emails us for support. But, the fewer emails we get, the more time we get to spend writing code, which is the ultimate dream of any software business. That's where the fun is!

So that's been my philosophy. It may not be right, but I wanted you to know the reasoning behind it. As we continue to grow, however, the amount of #UI #FAIL tweets and emails we get has increased substantially, and it has started to bother me. But the real tipping point... yes, the real tipping point was today, when one of our new developers, Alexander, was playing with his local install of Clicky, and he did something that trigged a success message that subsequently melted his skull. He said, Success messages are red?. I gave him the spiel. He understood, but he emphasized how much his mood was spoiled. He was truly upset that Clicky was essentially yelling at him while at the same time it was congratulating him for successfully filling out a form.

I felt bad. I almost let him go home early! But then I decided enough is enough... it was time to fix this. So I spent the last 4 hours or so doing just that. This is the result (screenshot below). And based on the comments in the article I linked above, I took the time to make it color-blind friendly (using blue instead of green for good messages). There are still some areas of our site where I use red to make something stand out, e.g. a specific sentence in the middle of a paragraph in our help documentation, but otherwise you should find Clicky a much friendlier companion.

User homepage totals

Wed, 18 May 2011 15:17:26 -0800

We've added a much requested feature to the user homepage: a row at the bottom summarizing your total numbers across all of your sites. This can add a bit of loading time to your user homepage though if you have a lot of sites registered, since it's showing today, yesterday, and the last 7 days. So if you don't need this feature and you feel this page loads too slow, you can disable it on your user home customization page.

Example screenshot is below of what this looks like. (For you mathematicians out there, the numbers don't add up because this is just a snippet of the top and bottom of my home page.) I also wanted to point out that the bounce rate is a weighted average, instead of just sumOfBounces/numberOfSites. Enjoy!

Update May 19: Due to popular demand, we changed it so this on top by default, instead of the bottom. If you want it on bottom instead, we added a new preference to put it down there, on your user prefs page. You can also turn it off entirely, as you could before, if you don't want it at all.

Tracking code updates

Fri, 13 May 2011 11:53:34 -0800

A highly requested feature has been to be able to view the /stats/ page for all of your sites at once (e.g. sum them up), or to officially support multiple tracking codes on one site (which doubles the amount of traffic you log, but lets you have a master site_id that logs all traffic for all of your sites).

The former option is more appealing to us for bandwidth and storage reasons, but the latter is easier to do because it only involves changes to a single file instead of a huge rewrite of the internal code. Using multiple tracking codes did already work to some degree, but there were a lot of bugs because it was not originally designed to work like that.

Well, no more! Alexander, one of our new developers, undertook as his first project a fairly major rewrite of the tracking code to officially support having multiple copies on a single page. I would however like to reiterate that we don't really like supporting this, because it doubles storage and bandwidth requirements on our end for your account - but, we know this is important to a lot of you so here it is. Do keep in mind that if you do this, you may need to upgrade your account to a higher level to support the additional traffic you'll be logging.

The code has also been updated to allow for dynamic clicky_custom updates. This is mainly of importance for those of you doing fancy things with Javascript, but if it affected you, you will appreciate this. Previously, once a page was loaded, clicky_custom was static - any updates you made to it dynamically (e.g. if you refresh a page via Ajax) would not be reflected in future calls to our tracking servers until the page was fully reloaded. But now the code checks the current status of clicky_custom for every single request, so if anything has updated since the last full page refresh, that new data will be sent along to us. This probably only affected a few hundred of you at the most, but one of those who was affected was myself, and it was driving me mad. Being a customer of my own business has its benefits.

One last thing. If you're currently using the asynchronous tracking code, we have made some minor (but important) changes to the format of the code that you paste onto your site. If you are planning to use multiple asynchronous codes on a single page, you'll need to update to use the new format that you paste onto your site. Otherwise, you can leave the code as is.

HTTPS support for all of Clicky

Wed, 11 May 2011 17:56:47 -0800

Clicky has always had HTTPS support on the login and credit card pages (and of course for the tracking code on your site), but otherwise we weren't allowing it. You may be thinking we were trying to save on performance, but that's not the case - our load balancers have hardware HTTPS decoding so the penalty is negligible. No, the one major reason was because of Google.

The Google Maps javascript API that we were using (version 2) did not allow HTTPS without an enterprise account for the low low price of just $10,000/year. Including insecure items on a secure page isn't a big deal of course... unless you're an IE user, and 13% of our users are on IE. So it is in fact a big deal. We could always just exclude that feature for them, or only include it on the pages that require it, but those felt like cheap hacks. I wanted proper support for it.

One of the good things about working with other developers is they can tell you things you don't know! We just hired three new developers, and I've been learning all sorts of amazing things from them. For example, just today, Mike told me that Google Maps API was now on version 3, and one of the amazing new features was full HTTPS support for no cost - not to mention no more API keys! How did I not know about this?!

So, I spent the last few hours converting our code to their new API, and now we have proper HTTPS for all of Clicky. We do require a Pro or higher account for this, but if you have one, your connection to our web site is now fully encrypted!

The last 6 weeks we've spent opening an office, interviewing a bunch of people, hiring three of them, and getting everyone up to speed on how Clicky works. This has been completely overwhelming, but we're finally past all that and the future is looking bright. We went from just one developer, to four, so you can expect things to start moving a lot faster. Each one of them is already working on some great new features, all of which have been requested a million times and I can't wait to get them into your hands.

I'll write more about them and show off our new digs in a future post, but now, back to work!

Update May 19: We added a preference to disable this in your user preferences, if you don't want it or it's causing problems (e.g. firewall not allowing port 443). It's on by default for all Pro+ users otherwise, though.

We're hiring

Wed, 30 Mar 2011 17:01:20 -0800

We're in the process of opening an actual office, and hiring a web developer or two to help step this bad boy up a level. This is going to take a ridiculous amount of our time so you're not going to see much excitement around here over the next month or two.

If you're an experienced web developer, proficient with PHP, MySQL, HTML, CSS, and Javascript, and you're looking for a full time job... view our listing here.