Database maintenance this weekend, new release next weekend

We need to perform maintenance on a few database servers this weekend. This will begin on Friday night around 8-10 PM (USA PST), and will last 8-10 hours. Affected servers are db7, 8, and 9. The database server that any site is hosted on can be found on that site's main preference page.

These are all fairly old servers, although they were opened up for some new sites for a couple of weeks in the beginning of 2010. Usually we only have to do this kind of maintenance on older servers so it doesn't affect too many people (since typically speaking, the longer you've been a member, the less often you log on). Unfortunately, this is not the case for everyone this time, since these servers have some sites registered as recently as 3 months ago.

When we do this type of maintenance we usually take the affected servers fully offline. However, due to complaints we are going to try a new method this time where they stay online so you can still view your stats, but no new data will be processed while the maintenance is happening. This will slow down the maintenance to some degree, but we think it will still be acceptably fast, especially since Friday night / Saturday morning is the lowest traffic levels of the week. We will be monitoring the performance and if we decide it's slowing it down too much, we will take them offline so that they can finish as quickly as possible, but we hope to not have to do that.

Our new release, that will include pinging and cookie support in the tracking code, much more accurate unique visitor and time online values, as well as tracking new vs returning visitors, is coming along really well. We were hoping to get it out the door this weekend, but combined with the database maintenance, it is just too much. So we are delaying it until next weekend. There are a couple of major database changes that in this new release, so every database server will have to be taken fully offline for approximately 2 hours while the changes are made. We plan to do this on a Friday night as well, so the least number of people are affected.

During maintenance periods, your traffic data is still logged, but it is not processed until the database comes back online. So don't worry, you won't lose any stats! But they will be lagging behind real time when they come back online for at least a couple of hours.

We are also always tweeting live updates during maintenance, so be sure to follow us on Twitter to for up the minute updates.
4 comments |   Apr 08 2010 8:28pm

Check in at your favorite web sites - automatically!

You thought the sneak peek of our new interface was hot? You ain't seen nothin' yet!

You like Foursquare. You like Clicky. Why not combine the two? Exactly what we were thinking! Every time you visit a site with the Clicky tracking code installed, we'll automatically tweet out from your Twitter account which web site you are viewing. Combined with Foursquare, not only will all your followers know WHERE you are every second of every day, but also what you're doing on the internet - every second of every day!




And what would be a check in service without super amazing badges to earn? Here's a preview!

Old habits die hard

Awarded for logging on to any web site with IE6

OCD

Awarded for logging on to your own web site 20+ times in one day

Going to store ROFL

Awarded for logging on to Twitter 50+ times in one day and sharing way too much personal information with your followers

I can has cheezburger?

Awarded for uploading 20+ photos of your cat to any photo sharing web site

Reality Distortion Field

Awarded for purchasing an 10+ iPads on apple.com within 2 weeks of launch

Night owl

Awarded for using the internet non-stop between 12am and 5am

Lonely

Awarded for logging on to 50+ naughty web sites sites in one week

Lookin' for Love

Awarded for visiting any craigslist personals category

Pizzaholic

Awarded for ordering pizza online 7 nights in a row

Swarm

Awarded for being part of the swarm from slashdot/digg/reddit that brings down a web site


That's only a small preview. We'll have over 5,000 badges ready to go when this feature launches next week. Hope you love it!
11 comments |   Mar 31 2010 9:08pm

Sneak peek of the new Clicky

Competition in our space is heating up, so we're working furiously to make Clicky stand out. One way to do that is with colors. Remember Paint by Numbers? Well we have taken that concept and color-coded all your favorite stats to the colors of the rainbow. And we thought... what's prettier than a rainbow? Maybe two rainbows? Exactly.

So as you can see, your stats have never been prettier, or easier to read. Our guess is that you will never want to leave your computer again.

To say that we are

SUPER EXCITED

would be the understatement of the decade. This bad boy is going to eat our competition for breakfast. Coming soon!!!


37 comments |   Mar 31 2010 5:29pm

Cookies and pinging support coming soon to our tracking code

We're working on another update to our tracking code that's going to add two much needed features: cookies, and pinging support. We have to make some backend changes also to support this, so we expect it to be about 2 weeks before it's ready. Here's what these features will do for us:

Mmm... cookie

Cookies will let us track unique visitors more accurately. Currently we just do this based on IP address, which works well most of the time. But if you have a bunch of people all behind the same router all accessing the same site at the same time, Clicky currently sees this as one visitor. This is rarely a problem for most of you, but some of you have sites that are accessed mainly by intranets, so it's more of an issue. Cookies will also let us finally track new vs returning visitors.

Cookies will be enabled by default. Most of you couldn't care less, but we do have some government sites using our service and we have been contacted more than once to ask about cookies, because it's illegal to have a government site that sets third party cookies without a signoff from the Secretary of Defense - no joke. So if you want to disable cookies in your tracking, implement this code as soon as possible. We're going to email everyone who has a .gov site in their account and point them to this post so we can be sure that everyone sees it.

Pinging

Pinging support will let us provide much more accurate "time on site" figures for your visitors. Right now we just rely on a time out period to say "ok, this person is gone". With pinging, we'll actually know when they're gone. Spy will be much more accurate in terms of how many visitors are actually on your site literally right now. This will also let us track how long someone is on your page for the last page view of their session. In particular, people who only have 1 action will no longer all be shown as "10 seconds" - we'll actually know how long they were online.

We're also going to adjust our "bounce rate" calculation so not everyone with just one page view will be counted as a bounce. While a lot of people who only have one page view are not engaged with your site, this isn't always the case. If you have a long article linked from Digg for example, 50% of the people may actually read the whole thing and be on your site for 5-10 minutes. Right now, all of these people would be shown as bounces, but once this feature is implemented we'll probably classify anyone who is on your site for more than 30 seconds as an engaged user, and they won't be a bounce.

Woopra recently poked fun at us on their blog for not having pinging support, but we agree with them - this feature is needed, and we will have it very soon. It's been a planned feature for a very long time, so we're glad it's finally in the works.
18 comments |   Mar 29 2010 1:16pm

Asynchronous tracking code, take 2

Kindly ignore yesterday's post about asynchronous tracking code. After further research it was determined that we didn't entirely know the full details of how this works with other services like Google Analytics. The code we released was simply waiting for "onload" to fire and then creating the script element that would trigger tracking. While this sort of achieves the same effect (it doesn't interfere with your site's loading), it definitely decreases accuracy, which is why we warned about that.

Well, forget all that, k? We just released an updated version that is truly asynchronous, and it should be more accurate, not less. Why? What we didn't know yesterday was that if you inject a script element into the DOM, all modern browsers by default will download that script asynchronously, which means in parallel with anything else that is already downloading to a visitor's browser. I'm embarrassed I didn't know about this trick, but it's true.

Taking this a step further, we modified the actual tracking code that you link to from your site so that the beacon it sends back to log data is also based on an injected script element, which means it now is asynchronous as well. Previously, we were using an image, which does not get this benefit.

We've been testing this new stuff most of the day for the tracking of getclicky.com, and it's working very nicely.

So, if you do absolutely nothing, you will still automatically get the benefit of the asynchronous logging of data. You may still see "waiting for in.getclicky.com..." in your browser's status bar, but it is not interfering with the downloading of other items from your web site.

But, if you want full asynchronicity, then go grab a fresh copy of the code from your tracking code page. This new code that you paste onto your site will also inject the tracking code script into your site's HTML, which will give you the full benefit of this functionality.

On yesterday's post, someone asked why we still recommended pasting it into the bottom of your site, rather than the head like Google Analytics suggests. The way the code from yesterday was designed, there was no benefit to placing it higher. But today, things are different. However, from what we have read, Google's recommendation is incorrect. They recommend you place the async code inside your site's "head" tag, but this code then manipulates the "head" object directly before the browser has fully parsed it. Everything I have read says you should not do that, as it can cause serious browser malfunction. If you want to place this code higher up, we recommend doing so at the very top of your body element, rather than the bottom. But we really don't think it will make much of a difference either way.

Ok, go enjoy!
15 comments |   Mar 25 2010 5:30pm

Next Page »




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