Our network host is requiring all customers to move their servers into a new server room they built last year. We've been putting this off for as long as possible, but the moment of truth has arrived.

We will try our hardest so there's no time when our network is actually 100% offline, because that affects your web sites. The plan is to move one of the paired load balancers and one of the tracking servers into the new room, then take the other stuff offline and let the already-moved LB and tracking server take over tracking temporarily. When the other servers are moved and come back online, everything will magically pair back together. This way there won't be more than a 5-10 second blip, and no tracking data will be lost.

The site will be in maintenance mode during the move, which we expect to take about an hour. When the database servers come back online, they will be behind real time by about an hour, so they will take a little bit to catch back up.

We've had our servers in the same set of racks in the same physical room for more than 4 years, so we don't expect to have to do this ever again.

It's been pretty quiet around these parts recently, so in case anyone was wondering if we were asleep at the wheel, the answer is NO! We took a few weeks off for the holidays but have been hard at work on lots of new goodies for the last two weeks. I just wanted to outlay what you can look forward to in our new release, which should be out by the end of this month.

• Split testing - split tests will be defined 100% dynamically using our clicky_custom javascript object, which means there will be no limits on how many tests or versions of each test you can have, and no annoying forms to fill out. You'll also be able to define the specific goal you want to track for this split test, so that we only calculate the "best" version of your test based on one goal which is likely desired the majority of the time. Otherwise, we'll be tracking all goals that occur after this person visits one of your split pages.
  
  
• Dynamic goals - For campaigns, we support both static and dynamic campaigns, so you don't have to define them first if you don't want to. We'll be adding the same thing to goals. One reason is to allow you to have more goals - there won't be any limits with dynamic goals. Secondly, we think it's easier to not have to predefine everything. This makes sense especially when combined with our new split testing feature. You will be able to define both your split tests and the goal you want to track for that test on the fly (if you want).
  
  
• Total number of visits per unique visitor - this seems obvious but we're not currently tracking it directly. That's going to change so we can quickly query this value for any of your visitors. This will be particularly useful for goals, so you can see how many visits it takes the average person to complete any of your web site's goals (we'll be adding this as a new column in the main goal report). We'll also be reporting the average time too, which will be based on the time of each unique visitor's first visit to your site.
  
  
• Customizable cookie domain - If you don't know what this means without further explanation, it probably won't be something you want or need. But, we have had a number of users ask to be able to set this to something other than the default ".yoursite.com", so you'll have that option now.

As we develop new features, other ideas or tweaks for those features usually come to us constantly. So, chances are there will probably be some extra stuff other than what's outlined above. We'll dive into much greater detail about each new feature in a new blog post when it's released.

One of our most requested features has been to segment out image searches from "normal" searches. We have just added this, so you should start seeing a new entry in your traffic sources report:




This feature has been requested countless times, as far back as June 2008. We're calling it "media searches" instead of "image searches", since we want to be as general as possible and may add support for video searches or other types of media in the future. Image searches from Google, Yahoo, and Bing are supported at the moment. We've also renamed "Direct / Bookmark" to just "Direct", and "RSS readers" to "Syndication".

Other new features and bug fixes from today:

• Windows phone 7 detection (will show up as just "Windows phone" though)
  
• The new "Google Web Preview" bot is now blocked by default as requested
  
• AOL recently moved to "q" as the default search parameter in their search engine, so their searches were just showing up as links in Clicky. We've updated our code to support this new parameter. It still supports the old ones too (query and encquery) in case those are still used anywhere.
  
• In October, we added support for google.com/aclk referrers, which is what we see when someone clicks on a paid search on Google. However, there's been a bug where these were referrers were showing up in your main "links" report, which normally only shows non-search referrers. We've fixed this bug, which was probably quite annoying for those of you running paid searches on Google.

That's all for today! You should start seeing us go back to our regular feature release schedule, where we release new stuff almost every week. The last few months have been insanely hectic from the massive redesign and tons of traveling and a big partnership integration we'll be announcing soon. We are excited to get back into the groove of writing lots of code because that's what we live for.

Steve has updated ClickyTouch to version 1.2, which is now a universal bundle (single application) that takes full advantage of the iPad's larger screen real estate when installed on an iPad. New features include a sidebar menu that's always visible (on the iPad), an inline browser for viewing referrers, the ability to choose a date other than "today", and a few new reports.

If you already have an old version of ClickyTouch installed, simply update it in the app store to get the new features. If you don't have it yet, you can download it here.

Please note this is a third party application, not commissioned by Clicky, so Steve is asking a very reasonable $2.99 USD to purchase the app. However, Steve is offering a free copy to 5 people who leave a comment on this post. Simply leave a comment and include your Clicky username or site ID, and we will pick our 5 favorite comments over the next few days and send you your promo code. Note that promo codes only work in the US app store right now, which is most unfortunate, but this is a limitation on Apple's end, not ours!

See ClickyTouch.com and our previous post for more details on the app.

Monday was a doozy. But good things have come out of it.

When we added pinging to our tracking code back in April, a few of you raised concerns that the new way we calculate time-on-site values may be misleading, since lots of people use tabbed browsing and open pages in the background, not to view them until minutes or hours or sometimes days later. This has its consequences on our end too: a user who opens a page in the background and isn't actually viewing the page, they are still sending us "pings" for 10 minutes (by default). This basically means for someone not actually using your site, they could still send ~15 overall "hits" to our tracking servers during that time. Big waste of resources on our end.

What happened on Monday was unrelated to pinging, but the pinging does add a lot of network activity to our servers. It accounts for just over 50% of our overall network requests. So when our load balancers crashed on Monday due to overwhelming network activity (theory is that it was related to Cyber Monday craziness), disabling pinging in our tracking code helped us calm the storm quickly. Pinging has been disabled since approximately 12pm PST on Monday, which is why your bounce rate and your time-on-site values since then have been off kilter.

We really want to alleviate the load these unnecessary pings put on us, and we want to make your analytics more meaningful too. So we took some suggestions you gave us back in April and integrated them into our new tracking code, which was just deployed about 20 minutes ago.

What changed

Now when a visitor opens a page in a background tab or window, the page view is not logged and the pinging does not start until that page is actually being viewed by the person. If they open it in the foreground, tracking will work as it always has. This change only affects people opening background tabs. We think this will provide much more meaningful data to you, because now we'll only be logging the visit once they start using your web site.

The only downside to this is that if you are comparing Clicky's visitor log to that of another service you may also using on your site, some of the arrival times for your visitors won't match up. For example, IP address 1.2.3.4 may show up in Clicky as arriving at your site at 1:30pm, whereas your other service may show them as arriving at 1:25 instead. When you see something like this, the reason will be because that visitor initially opened your page in a background tab at 1:25pm, but didn't start viewing/using the page until 1:30pm.

Pretend that when this person started using your site at 1:30pm, they looked around at a few pages and left at 1:35. Would you rather we report that they were there for 10 minutes from 1:25 to 1:35 (the old way), when they were really only there and using your site for the last 5 minutes of that visit (the new way)? The new way more accurately reflects this visitor's actual "session" on your site, and hence is a better way to look at things in our opinion.

This is what "analytics" is all about - "analyzing" your data to make it more meaningful. Like how our bounce rate is different than other services, but it's better because it's different. This is another one of those things. We celebrate our differences as the purple cow of analytics, and hope that you do too.

Update: No action is required on your part. The tracking code that your site links to, hosted on our servers, has been updated, so everyone gets it automatically.

Also, after this being live for most of today, the difference on our end is quite noticeable. The load on our load balancers has dropped by almost 15%, and the load on the tracking servers behind them has dropped more than 30%. Yay!

Update 2: Although it worked fine in testing, there is some strange bug with Safari that was causing this browser not to be tracked 100% of the time. Based on our numbers it looks like about 1/3 of Safari visitors weren't getting tracked. We have updated the code so that this new method does not apply to Safari anymore. Since Opera doesn't support document.hasFocus() and Chrome's implementation is wonky (it always returns "true"), this means that basically only Firefox 3+ and IE7+ support the new method. This is more than 2/3 of internet visitors though.

Update 3 (Dec. 8): We have reverted to the old version of our tracking code. While most users/sites experienced no problems, a few experienced drastic differences in visitors logged.