User homepage totals

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.

10 comments |   May 18 2011 3:17pm

Tracking code updates

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.
6 comments |   May 13 2011 11:53am

HTTPS support for all of Clicky

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.
13 comments |   May 11 2011 5:56pm

We're hiring

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.

18 comments |   Mar 30 2011 5:01pm

Enforcing page view limits

We've been very lax about enforcing the page view limits of whatever account you have signed up for. For the most part this hasn't been a big deal, but as we continue to grow past 300,000 monitored sites and attract bigger customers to Clicky, it has become a serious problem.

When you go to the upgrade page, it won't let you sign up for a plan that doesn't have at least as many page views as you are currently logging on average. That's all well and good, but the problem typically occurs after the upgrade. Here are the two most common patterns that we see:

  • High traffic site signs up for Clicky and pays for an upgrade almost immediately. Say this site has 300,000 daily page views, but if they've only been tracking for an hour, they probably only have 10-20,000 page views logged so far. The upgrade page would let them sign up for Pro (30,000 daily page view limit) at this point, even though they're going to be logging 10x as much traffic. We could extrapolate their traffic so far to get an estimate, but some sites have very strange traffic patterns so there's no way we could make this reliable.

  • User pays for an account and is within the limits of that account. As the years go by and their traffic grows, however, they are eventually well beyond the limits they are paying for.

Clicky is an expensive operation to run, but we still manage to have the best pricing in the industry (excluding free services of course). For example, in terms of the features offered and the mix of real time and historical data, Woopra is arguably our closest competitor. If you had a site with 30,000 daily page views, you could monitor that on Clicky with our Pro package, which costs $10/month or $60/year. With Woopra, you'd need their "Platinum" package to monitor that many page views, and the price for that is $50/month or $500/year.

With pricing this good, we can no longer allow the above scenarios to occur. So starting this week, we're going to enforce what you are paying for.

Here's how it's going to work. Clicky's pricing is based on daily page views, but we'll be doing this based on total monthly volume. If you have a Pro account, those 30,000 daily page views will be seen as 900,000 monthly. We're going to allow a 20% buffer, which means Pro will be allowed an additional 180,000 page views for the month (1,080,000 total).

For a Pro account, once you hit 900,000 for any given month, you'll get an automated email from us about exceeding your limits, and you'll see messages in the Clicky interface about this too. But once you are over the 20% buffer, tracking for your sites will be disabled until the end of the month, unless you upgrade to a plan that supports your traffic levels. You'll get an email when that happens, and you'll see messages in our interface about it too.

We hate to have to do this, but to keep our pricing as reasonable as it is, we need those of you using a lot of resources on our end to pay for what you are using. To be fair, most of you are well within your limits, and we appreciate that greatly. But for the people who are over their limits, they are generally well beyond them, in the 5-10x range. That's a problem!

Update: As of March 9, this is live.
26 comments |   Mar 07 2011 8:13am

Next Page »

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