1 minute uptime monitoring! And more new custom upgrade options.

We just launched a revamped upgrade page with some highly requested feature customization options.

  • 1 minute uptime monitoring intervals - When we launched uptime monitoring in beta back in January, we said that 1 minute uptime would be "coming soon". Ha. Anyways, we still haven't launched Monitage as its own standalone product yet, so we still consider it a beta feature for the moment, but we've had a lot of requests for 1 minute monitoring so now you can choose that interval if desired.

    There's also the option to increase the number of monitors you can have per site, up to 10 (default is 3).

  • Higher heatmap sampling - Heatmaps by default only sample 50% of visitors, minus mobile visitors (we'll eventually log them, once we get to test things them more). Now there are more options for this, all the way up to 100% (again, minus mobile visitors).

  • API throttling - Back in February we had to start throttling the analytics API, as some customers' heavy usage was impacting some of our database servers' ability to keep up with real time. This only impacted a couple of specific data types though: visitors-list, actions-list and segmentation.

    There are two aspects to throttling. One is that we only allow one request per IP address per site ID at a time. The other is that these types of requests are limited to 1000 results and a max date range of 7 days.

    The option to remove API throttling that we are offering now is for the first throttle only, that is, you will now be allowed to send unlimited requests per IP address per site ID. However, the date range and max result size of 1000 will still be in effect. We've analyzed the data and we just can't offer this without impacting a large number of customers.


Here's what the new upgrade page looks like:




Each customization you choose increases the price by a certain percentage, such as 10%. They don't compound though, meaning if you choose two upgrades that each increase the price, they are each calculated based on the core price of the non-customized plan.

If you're ready to take the plunge, you can upgrade here.
1 comment |   Jun 06 2013 5:52pm

Local search now supports 'pretty' searches and multiple parameters

By popular demand, local searches now support multiple parameters, as well as path based "pretty" searches. You can mix the two types as well. To use multiple of either one, just separate with commas.

For path based searches, what you want to enter is everything that goes between the domain name and the search term. For example, if someone searches for "apples" on your web site and they end up here:

http://yourwebsite.com/search/apples

Then you would enter in "/search/" into the box. Without quotes of course.

For good measure, here is an example of a comma separated list of both types, pretending your site has both "q" and "s" as search parameters, and also does path based search with the search term appearing after /search/, as shown above:

/search/,q,s
1 comment |   May 15 2013 4:04pm

Tracking tel: URLs, custom heatmap objects, and other tracking code updates

Note 1: DO NOT PANIC. You don't need to change anything with the code installed on your site. We've simply made some changes to the way the code works, adding a couple of features and fixing a few bugs.

Note 2: Other than the "tel:" tracking, most of this only applies to advanced users.

New features

  • Tracking tel: URLs - This has been requested here and there over the years, but as Skype et al become more ubiquitous, these URLs are on more and more pages. So we just added support for automatically tracking them. Like mailto: links, these will show up in your outbound link report. You don't need to do jack diddly, it should just work.

  • Custom heatmap object tracking - Our heatmap code by default listens for clicks that bubble up to the document.body element. The default for all events is to bubble up, but there are plenty of events that don't do this, which means those clicks weren't being captured. We ourselves have been affected by this too, mainly by our Javascript menus.

    So now there is a new clicky_custom property, heatmap_objects. With this you can specify custom elements, by tag name, ID, or class. It can be a string if you just need to specify one thing (most likely), or it can be an array of strings if you need to specify more than one. Using this we can track clicks on these elements. Which reminds me, I forgot to update our own Javascript code to track our menus! Mental note.

    You should ONLY use this for events that don't bubble up, or you will experience oddness.

  • clicky.goal() changes - This likely does not affect you but if you use the clicky.goal() javascript method at all, you may want to read on.

    When we released heatmaps, we added a new event queue system for logging some items in batches: heatmap data, javascript events, and javascript goals. The reasoning behind this change was to reduce bandwidth for heatmaps, and increase accuracy for events and goals. The accuracy part being that if you sent a hit to clicky.log() or clicky.goal() when someone clicked on a link that would result in a new page being loaded, chances were good that it would not be logged because the page would be unloaded from the browser before the logging request went through.

    So the queue system was made to store events and goals in a cookie, which is then processed every 5 seconds. So if the person is just sitting on the same page still, the queue will be processed shortly and send that event/goal to us. But if instead a new page is loaded, the cookie is still there holding the event/goal that wasn't logged on the last page, and can be processed immediately on the new page view (which we do before processing the new page view itself, to ensure things are in the correct chronological order).

    ANYWAYS... there were some customers who were using clicky.goal to log goals when visitors were leaving their site. The queue would intercept these goals though, resulting in a snowball's chance in hell of the goal ever being logged.

    SO... we added a new parameter to clicky.goal() called "no_queue", which will tell our code to skip the queue and just log the goal immediately. Check the docs for more.

    This doesn't affect many of you, but if it does, the back story I've written above is probably worth a read.

  • New method to check if a site ID has been init()'d - for customers using multiple tracking codes on a single site/page. This was a specific request from one customer, but we realized our code itself wasn't even doing this sanity check, so if you had the SAME code on your site multiple times, there were some minor bugs that resulted from this.

    If for some reason you think this applies to you, the new method is clicky.site_id_exists(123), which returns true or false indicating whether this site ID has been passed through the clicky.init() function yet. Note: "123" is an example site ID. Use a real one.


Bug fixes for sites using multiple tracking codes

In addition to the last item above about loading the same site ID multiple times resulting in oddities (and which is now fixed), we've made another change to the way the init process works.

There are a number of things that happen when a site ID is init()'d, but it turns out most of those things only needed to happen once, even if you had multiple site IDs on a aingle page. However, our code was executing this entire init process for every site ID on a page, which resulted in bugs such as:

  • clicky_custom.goals and clicky_custom.split only working with the first site ID that was init()'d.
  • The automatic pause that we inject for tracking downloads and outbound links was being called once for every site ID, rather than once per click (which is all that's needed)
  • When loading heatmaps by clicking the heatmap link from clicky.com, the heatmap would sometimes load twice (making it extra "dark").


There were a few other much more minor bugs, but those were the ones that were really irritating. So now what happens is we split the setup procedure into a different method, and wait 100 milliseconds before calling it (just once), giving a chance for all site IDs to be passed into the init process first. And the actual init() method now just puts each site ID into an array which we loop through when any request to log data is called.


Coming soon

Been requested a number of times and something we will definitely add in the coming months. That being when you set custom visitor data with clicky_custom.session (or utm_custom), we will store this data in a cookie so the data will be applied to all future visits by this person, so even if they're not logged in, they'll still be tagged as they were last logged in / tagged visit.

We'll probably only do this with a few specific keys though, since people use clicky_custom.session for all kinds of crazy purposes, many of which can be session specific. But we'll probably do something like, only do it for keys like "username", "name", "email", and a few others.

Just something to watch out for. We think this will be a nice addition when we add it.
3 comments |   Apr 17 2013 10:34pm

Local / internal search support!

Local searches (searches performed with your site's own search engine) has been one of the biggest feature requests we've had over the years, so we're happy to finally support it!

First, you need to tell us what the search parameter is that your site uses. Common ones would be "q" or "search". Examples:

http://yoursite.com/search?q=lollipops
http://yoursite.com/search?search=care+bear+stare

You can set this in your site preferences:





You will then start seeing data in the new local searches report:





You can click on any of the searches to filter down to the visitors who performed said searches:





They will also show up in Spy:





As well as the actions log (both globally, and when viewing a session):





The action log can also be filtered down to just show local searches:




And that about covers everything!
28 comments |   Apr 16 2013 4pm

Tracking Youtube videos no longer requires PhD

Recently we were inspired by this post detailing how to automatically track (with Google Analytics) all Youtube videos embedded on a page, with zero work required other than including a single Javascript file (or two if you don't have jQuery).

Our old method for tracking Youtube was really ugly, requiring a good bit of custom code for every single video you wanted to track. We wanted it to work more like what we read above.

So, now it does! The old method still works for those of you who already have it deployed, but the new method is great because it works with the default iframe embed code that Youtube gives you, and it requires pretty much no work on your end.

Head on over to the video analytics docs to see what you need to do to get it working (scroll down, click 'youtube').

Coming soon

We've got a couple new features we hope to release this week. One is local search support, probably our biggest feature request of all time. Another is tracking clicks on tel: URLs. Another is the ability to click on any graph to view/segment visitors based on what you clicked. Last, Monitage (uptime monitoring) is being finalized, which also means we'll have up to 1 minute monitoring available and the ability to setup more than 3 checks. Monitage won't launch this week, but soon thereafter.
2 comments |   Apr 09 2013 4:06pm

Next Page »




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