A friend suggested this a few days ago, and frankly, it makes so much sense that I’m kicking myself for not doing it on my own.

As of just now, the My Cligs displays little flags for each geotargeting rule the clig has. The screenshot below shows what that looks like for one of my test cligs:

Each flag is a link to the geotargeted destination, so hovering over each flag or clicking on it will tell you the destination for visitors from that country. If there aren’t any geotargeting rules, nothing is shown.

As ever, feedback most welcome.

Saturday’s speed up had a little bug in it: if you edit a clig or delete it, Cligs will not show you that the clig has been edited or deleted when in reality the changes were successfully done.

I’ve fixed that now, and to help you check, I’ve added a refresh link on the My Cligs page, right above the hits table (screenshot below). Click on that and Cligs will reload the detail of your cligs from scratch and you will see the changes.

I’ve finally deployed some things I’ve been working on for a while now. Collectively, these changes are making the Cligs service super fast, the fastest it’s ever been actuallly. These speed-ups mean that forwards are now done faster and the /cligs analytics pages load in the blink of an eye.

Given the gain in speed, I’ve upped the number of cligs shown by default on the /cligs Executive Summary page to 15.

The changes also enabled me to deploy a very cool new feature: the Cligs Browser which displays a paginated list of all of your cligs WITH hit counts. This new Browse View replaces the old, slow, time-out prone, and clunky List View with Hits. The List View without hits (the previously fast view) is still with us and now even faster.

As this is the first installment of the Browse View, I’m particularly keen to hear your thoughts and feedback about how to make it better and more useful. Please let me know.

A lot of users have suggested that the maps analytics is important to them but with the new design it takes too long (too many clicks) to get to it.

So as of just now, the geo analytics map is part of the executive summary page as shown in the screenshot below. It really does fit there as it summarizes the hits the clig received from around the world.

The reason it was split out initially was to minimize the loading time and to also have the analytics in a more structured format. However, moving it back does not really slow down the page because the map data is retrieved in the background as the page is loading.

As ever, questions and feedback most welcome.

I didn’t notice this till a user pointed out: the Social Media tab in the cligs analytics was not showing any tweets. It was working for a while then Twitter changed something that broke the search. It’s working again now.

Over the past few weeks, users have been reporting slower than usual forwarding and sometimes a generally slow service. I’ve been looking into the performance quite a bit for the past few weeks, and just now I rolled out the first in a set of improvements that make the forwarding go much faster.

Because most of the traffic on the site is forwarding, the service itself is now faster too. Pages, in particular the analytics, load noticeably quicker. And no, I did not disable any features to make it go faster

There is a bit more I want to test to see if I can make it go faster. It is a continuous process.

Let me know if you see anything broken. And please keep the feedback coming!

I’m very excited today to announce that Cligs is part of a new industry initiative to create a back-up mapping service for short URLs called 301works. This means if anything bad happens to Cligs, it will not be a disaster as there is a permanent backup stored outside of the service. This initiative already has the support of other leading URL shortners including Adjix, awe.sm, betaworks, bit.ly, URLizer, and urlShort. The data will be stored independent of any URL shortener by Gnip, a specialist data storage and distribution company.

How it Will Work for Cligs

Over the next few weeks, I’ll be updating you about how you can opt-into this backup service. I will be working with Gnip to test the data transmission mechanism and be updating Cligs to help you pick which cligs are backed up. There are many considerations for this, and rest assured that nothing will happen without your explicit decision. More details as soon as I can share.

History and Thanks

This idea has been talked about for a while. It was first proposed by Jonathan Strauss of awe.sm and he and I have been discussing its implementation details on and off for a while. With the recent panic about the almost-collapse of tr.im, we as an industry decided to act quickly. Several phone calls at weird hours of the day and emails later, we’ve reached an agreement that I’m very proud and happy about. The URL shorteners industry needs an independent body for this purpose, and I’m glad we all put our healthy competition aside to make sure we as an industry can serve our users better! I would like to thank everyone who helped make this happen including Eric and Shane of Gnip, Jonathan of awe.sm, and the teams at Betaworks and Bit.ly who provided the necessary momentum to actually do this.

Coverage and More Info

• 301works home page: 301works.com.
• Announcement press release.
• CNet
• Techcrunch.
• Mashable.

And if you are a URL shortener, please join us!

Following the recent introduction of anti-spam and anti-malware features, I’ve now deployed extra protections on top of the previous ones.

The intial protections checked the destination URL (and domain) and the requester’s IP address when the clig is first created. The problem is that sometimes the public blacklists that Cligs uses sometimes do not know about malicious URLs. In this instance, Cligs and other URL shortening services are at the very beginning of a spam/virus campaign, and no one knows about it yet.

Obviously, this is not a good situation to be in. We need to check again later.

Like random police checks, sometimes Cligs re-checks the destination URL before forwarding it onwards. How random? Each forward has a 10% chance of being checked. The balance to strike here is between performance/necessity of checking 100% of the time vs stopping malicious links getting through. If you think about it, viruses and spammers send out massive amounts of emails and these generate a lot of traffic; checking 10% of that will catch the spam eventually.

If the new system detects a malicious clig, it immediately disables it and starts returning a 404 Page Not Found error.

The beauty of this is that the system is completely automated. I only get an email saying a clig has been caught. That’s an email I’ll always be happy to see!

The work is complete. Please let me know if you find anything broken. Thanks!

I’m currently updating some of the backend and the analytics screens. You may see some thing temporarily broken or the analytics may not add up or be shown. It’ll be done shortly.

The analytics are being logged normally though. It’s just the viewing that’s affected.

Several users have reported a large number of new cligs being created in their accounts. On investigation we’ve narrowed it down to the Tweetmeme plugin triggering the creation of these new cligs.

I am in contact with the Tweetmeme team and rest assured we’ll solve it for you. I’ll update this post as soon as I know more.