mysiteonline™

Most solutions that I've found for tracking outbound links with Google Analytics have been to send the link through a local file that would then be able to be tracked by Google, sending a query string as your end-result location. I never really liked that.

The other day, I accidentally found someone else's solution to use jQuery and Google Analytics for outbound link tracking.

The following code snippet is what I ended up with for my own use (so it doesn't add an actual visit/pageview to my own site's ranking):
$(document).ready(function(){ var domain = document.location.host; //includes port, whereas hostname does not $('a[href^="http"]:not([href*="'+domain+'"])').click(function(){ //can use the following for internal PDF/DOC hit tracking //pageTracker._trackPageview($(this).attr('href')); pageTracker._trackEvent('Outbound', 'click', $(this).attr('href')); }); });
What's happening here?
$(document).ready(function(){ - when the DOM is ready, do the following...

$('a[href^="http"]:not([href*="'+domain+'"])').click(function(){ - whenever a hyperlink is clicked that does not contain our domain anywhere in the URL, run the following... (this includes any subdomain, further string trickery would be required to keep subdomains listed in the same category)

pageTracker._trackEvent('Outbound', 'click', $(this).attr('href')); -- Run Google's _trackEvent method to register an event. Typically the 2nd parameter passed in is an "action". In my final version, I changed "click" to be $(document.location) instead, so that I can tell where people are clicking these outbound links from.

You can read more about the Google method "_trackEvents" from the Google Documentation on Google Analytics. Oh, and...about the commented out code, that's more of a reminder to myself, if I ever want to track PDF or DOC file clicks on my own domain, but the code would have to be revised a bit for that to work. Also, make sure you change the domain string to whatever you'd like to track (a specific subdomain, or your whole domain).

Work has finally progressed on the StatTracker. It's taken me a little bit of time to get accustomed to Event Driven programming, but I think I got the hang of it. To be honest, it was kind of nice after I understood what was going on (and created a flowchart to more easily see what I needed to code for). It forces me to go back to my OOP roots in C++. I've been doing procedural PHP for so long, I almost forgot how to spread procedure calls in to separate, more manageable blocks. I now call one function upon application instantiation that runs all other functions, depending on iteration.

Anyhow, the last post I had, I showed a mockup in Photoshop. Here's a live running example of the UI (built directly from the mockup):

What's done?

• CakePHP Web-based backend
• Adobe AIR application, can be installed on Linux, OSX, Windows
• Use jQuery JavaScript library with Adobe AIR
• XMLHTTPRequest to backend server from AIR app to dynamically build the UI

What small things do I need to fix?

• Currently, at least in Windows, if you have a :hover state on a button, moving the mouse to the transparent portion of the window does not trigger the mouseout event and disable the :hover state. I will have to overcome this either by JavaScript, AIR properties, or some HTML/CSS trickery.
• There is currently no indication that an action has occurred properly (did I press it properly? *click click click CLICK!!!*) as it's such a simple application, I felt it was unnecessary. My boss basically told me I was stupid (with a grin), and I agree.
• As of right now, the project only supports up to 9 different question types as the background colors are hardcoded in CSS. This will need to be dynamically coded at a later date. Our library only has a need for 4, so I'm not too overly concerned with this prior to me releasing the code.

What's left?

• Attaching onClick events to the buttons to submit a value to the server (very easy, and is the next step)
• Setting a modal dialog for the Text button to submit data to the server
• The hard part: If saving to the server fails for whatever reason, store the data in an internal SQLite DB - constantly check the server at predetermined intervals, and once connection succeeds again, upload all data in the internal DB back to the server, and empty the local DB store
• Backend will (eventually) provide numeric as well as graph/chart-type statistics (I think I'll use ezComponent's ezGraph, I was going to use Open Flash Chart, but Flash based data does not print, and I'd imagine our department heads will want to use the statistics in their monthly reports)

I switched tooltip libraries from SimpleTip to qTip, both jQuery tooltip libraries written by Craig Thompson (http://craigsworks.com/). qTip was a rewrite of SimpleTip. It didn't take much time to switch, but there was a bug that he only just fixed this morning that was preventing me from moving forward. Getting the window to properly display in the bottom right portion of the viewport was also "fun", but I'm learning, which is good. Unfortunately, it's all untested in Linux and/or OSX as our library only uses Microsoft Windows, but I can test OSX functionality at home at a later date; or better yet, once this goes up in SVN, anyone else can test it out too, and possibly supply fixes or updates (or if I use GitHub, create their own fork)!

Suggestions, comments, feedback?