Development Seed Blog

How To Get Detailed Metrics for Drupal Site Running on USB Drives

We recently put a disaster relief kit in the form of a Drupal website on a usb drive for the American Institute of Architects’ Communities by Design initiative (for details, see here, here, and here). As development proceeded, we got to discussing setting up the Drupal installation to “phone home” to get software updates and centralized backups. And if the installations were already phoning home, well, why not track how and where they are being used?

Using Google Analytics, we developed a tracking mechanism for each and every copy of Drupal on a stick. In this post I’ll describe how we did it.

We decided we wanted to track the stick’s usage – the application pages they visited and length of stay – whenever users were connected to the internet. Google Analytics fit the bill as the best means of tracking, but how would users call Google's javascripts? Google doesn't allow listing 127.0.0.1 or localhost as a domain for purposes of their tracking tools. We solved this problem by embedding an IFrame element in page.tpl.php of the application’s custom theme and listed its source a newly purchased domain. We'll use http://example.com for the purposes of this post so as to keep our tracking domain untainted with spider traffic.

This solved the domain problem, but we still needed the sticks to transmit more detailed usage information. We solved this fairly easily by appending Drupal's query string to the requested url on http://example.com like so:

<iframe height="0" width="0" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="display: none;"src="http://example.com/<?php echo $_GET['q']; ?>"></iframe>

The next trick was to make sure the remote tracking server served a page with the Google Analytics script on it. We couldn't possibly hope to map all the permutations of urls that Drupal could generate, so we used .htaccess and mod_rewrite to essentially map any and all urls to the same page. This also enabled us to not serve an HTTP 404 page (where we could have just as easily put the Google Analytics script), which was ideal because Google's tracking works much better when a 20x HTTP code is returned by the server.

Testing this setup gave us mixed results, mainly because it was generating quite a javscript error:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMScreen.width]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://www.google-analytics.com/urchin.js :: _uBInfo :: line 297" data: no]

After a little googling (natch), we figured out the problem: the style declaration. It turns out that one of the many things that Google's urchin script tracks is the users’ screen size. When there's a CSS declaration of display: none; attached to an IFrame, the browser requests the page but never displays it, causing the screen size tracking in Google's urchin script to fail, ahem, aggressively. Removing the style and increasing the width and height to 1 did the trick:

<iframe height="1" width="1" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" src="http://example.com/<?php echo $_GET['q']; ?>"></iframe>

Since the page returned by the tracking server is blank, the IFrame is still invisible to the user.

So far we’ve distributed several beta versions of the disaster kit in a stick, and we’re seeing that it’s being used across the United States and Canada. Once more are distributed, it will be really interesting to see how their use changes during a disaster.