Status Update: Week 46

Sun, 21 Nov 2010 18:32:00 -0400

Done

It was a pretty slow week, I mainly just worked on patches for Mozilla Lab's Prospector and answering questions on the Google Analytics and Website Optimizer help forums this week.

Mozilla lab's Prospector

findSuggest: Clicking a word overwrites the last word in the find field instead of replacing the existing find field (Issue #33)
queryStats: Bug fix for an exception when running add-on (Issue #48)
queryStats: failed to work and disable itself when installing by proxy file or putting xpi into extensions folder manually (Issue #49)

Still working on finding resolutions to the remaining bugs blocking Scriptish 0.1..

Tracking Outbound Links - The Really Right Way

Thu, 17 Dec 2009 04:15:00 -0400

About 5 months ago Eric Vasilik wrote a post on his GWO Tricks blog about Tracking Outbound Links -- The Right Way which was ment to point out a solution for the problem with the technique outlined in the Analytics Help Center article called "How do I manually track clicks on outbound links?", is that it suffers from a Race Condition which may mean the tracking doesn't take place. If you haven't read Eric's article, please do.

Well as readers of my blog would know, I recently wrote a JavaScript click tracking library which can be found at GitHub here. In the blog post I mention that I implemented Eric Vasilik's "Right Way" to track links, but today I started thinking about this some more.

I decided to do some searching on how to cancel a click event, and I found a great old blog post from 2006 by Ryan Campbell pretty quickly which mentions a method implemented by Prototype called Event.stop(). So I decided to dig in to the Prototype code to see what Event.stop() did exactly, so I could extract it, and I found that it does two things, one is to stop the event propagation, and the second is to stop the default behavior for the event. At the end of the post Ryan said that it not work for Safari 2.0.3, which is why it could not be relied on at the time, but today Safari 2.0.3 is dead, and I tested Safari 3 out which works. In fact I decided to do some PPK style testing and try test cases on every browser I could.

After seeing that Event.stop() had two purposes I wanted to find out why this was done, and found this documentation page for Event.stop(), which says this was done "because stopping one of those aspects means, in 99.9% of the cases, preventing the other one as well", but in the case of simply click tracking we don't really want to stop the event propagation, we just want to stop the default action from being triggered eventually. So here is what my update to Eric's example looks like:

Click me ]]>

To try the code above see the test page here. I have tested this out on IE6+, FF2+, Opera9+, Safari for the iPhone OS 3.0, Google Chrome, and Safari3+ on MacOSX and WindowsXP and they all work, so I am pretty confident that this is going to work for something like ~99% of web users today, and since it would not error even for a user using Safari 2 (which I wasn't able to test), and Safari 2 is so slow, there is a good chance the user would still be tracked anyhow.

If anyone else could try this out on some other browsers at let me know what they find good or bad that would be nice so that I can add them to the list above. The best way to test the test page is to comment out the setTimeout line, and make sure that clicking the link doesn't do anything.

The beautiful part about this method is that it is totally unobtrusive JavaScript code, and will work even if you are using the onclick attribute for other site functionality (even though you shouldn't ever use the onclick attribute).

Merry Clicking!

P.S. The Click Tracking JavaScript Library has been updated to use this really right method, check it out if you haven't already!

Erik Vold's Blog - Google Analytics

Status Update: Week 46

Done

Mozilla lab's Prospector

Next

Tracking Outbound Links - The Really Right Way