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.

Short and sweet:

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!!

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

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