Aza Raskin's SocialHistory Javascript library allows you to do something incredibly cool: detect which sites your web users have visited on a per-user basis. The javascript runtime isn't supposed to be privy to the information in a user's browser history, but there's an information backchannel common to all major browsers which allows you to effectively interrogate the browsing history and determine if a particular URL has been visited before.

It works by creating an anchor link to the site in question and applying a CSS style to the link, specifying a different display property for "a:visited". By reading the computed style back from the anchor element, you can then determine the property's value, and consequently if the user had visited the URL or not.

This could probably be used for a number of devious purposes, but Aza's concept for the SocialHistory library is actually really useful. By querying the default URLs that belong to all the major social network sites, you can figure out which sites a particular user visits and custom tailor any social badges that you display. If they use del.icio.us, you show a del.icio.us link. If they visit Digg, you show the Digg button. It's an awesome feature made possible by a pretty freaky security leak.

Now, it's not perfect. It requires that you query the exact URLs that a user may have visited. You can't figure out everywhere they've been, how frequently, or in what order, only whether a particular URL that you know about has been visited before. On the other hand, it's a pretty useful tool considering you aren't even supposed to be able to do this.

How to Detect the Social Sites Your Visitors Use
SocialHistory.js

When you look at the analytics javascript code you see that it combines several sets of data into an image request. This image request sends the right data to Google (not the javascript). When you know what url you should use for the image, you can call the image directly and send the same data. Of course you need to be able to request the image url and that isn't easy from another image, rss feed or pdf. This is why we request it "server side".

You can add the code to the PHP that drives a blog site, for instance, and generate page views when your RSS feed is hit. You can even write a very simple script to proxy images and downloads, which will let you track hit data for all files on your site, not just the html pages viewed by a javascript enabled browser.

Taken a step further, you could even use this on the client side, triggering analytics views from standalone Flash apps or even desktop applications.

The one thing you need to keep in mind is that server-side analytics requests will appear to come from your server, not the client's machine. So while you can track page views and download events this way, you'll loose a lot of the information about your user base. Because of this, it would probably make sense to use a separate tracking ID for the server side events.

Google Analytics Without Javascript

First I was thinking about doing some sort of regular expression search and replace throughout the site and database, but that reminded me of CSS3 selectors and their ability to do simple pattern matching. I've seen people apply a special style to outbound links this way, so after a few minutes of monkeying around with things, I now have a chunk of jQuery that will automatically track clicks on all outbound links.

Here it is, in a nutshell:

jQuery(function($){

   // Match all anchor tags in the "maincontent" div with
   // urls that begin with "http" but don't contain the
   // string "yourwebsite.com"
   $('#maincontent a[href^="http"]').not('a[href*="yourwebsite.com"]').click(function(){

     try {

     // Get the href url and toss out the "http://"
     var href = $(this).attr('href');
     if ( href.indexOf("://") > 0 ) {

       // Track the page in Google Analytics as
       // "/tracking/outbound/www.somesite.com/foo"
       var outbound = '/tracking/outbound/' + href.split("://",2)[1];
       pageTracker._trackPageview(outbound);

       }
     } catch( e ) {}
   }
}


With this running, all of my internal pages get tracked as usual, and any external links will appear as pageviews that look like "/tracking/outbound/www.somesite.com/foo".

If you link out to many different pages on several sites, keeping the full site url in the tracking code and building these deep paths is particularly useful. Google Analytics will allow you to drill down into the tree like it was normal content and quickly pull numbers on how many total outbound clicks you received (/tracking/outbound), how many went to www.somesite.com (/tracking/outbound/www.somesite.com), and how many people clicked out to a particular page on the site.

This saved me quite a bit of time and is immensely more flexible than any other outbound tracking method I've used. I hope this helps someone else. Drop me a line in the comments if this works out for you.

Update: it looks like I wasn't the first to do this. An article by Rebecca Murphey shows how to do something similar, while also adding the referring post title to the tracking code. Pretty cool stuff, I must say.

Reuben Yau came up with a nice hack that solves the full-referrer problem. The hack uses urchin's manual javascript tracking mechanism, typically used to track flash events, to register a page view with the full referring URL as the title. Just update your tracking code with the following:

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-XXXXXX-X";
urchinTracker();
urchinTracker(document.referrer);
</script>

After you've made the change, you'll start seeing referring URLs showing up in the main content reports (as opposed to the "referring source/cross segment performance/content" report). They'll look a little different from typical content, as the content name will contain a full http:// URL. You can then filter the report for "http:" if you only want to view the referrer data.

Google Analytics Full Referrer Tracking -Link.