Using Google Analytics in your Single Page Web Application

On break the other day I had a thought: “Why not log all activity in our web application with Google Analytics”. These coffee-break thoughts are quite common for me and sometimes they turn out to be more than caffeine-fueled delusion.  Now this is a b2b application and you generally wouldn’t think about such a thing since Google Analytics is used primarily by online marketers and SEOs. Still I think there is value in seeing what pages are browsed most frequently as well as the power to log HTTP Errors. Given that we are a mostly single page AJAX driven application a little extra work had to be done. Here’s how to implement Google Analytics in your own application.

Sending Ajax Calls to Google Analytics

Here we use jQuerys ajaxComplete callback. This works out of the gate assuming the analytics tracking code has already been added to your document. Now this is pretty basic and you might want to expose a bit more information to Analytics. To do so you’ll want to familiarize yourself with the various fields GA accepts.

Sending Additional Fields to Google Analytics

In this example we are splitting on the request URL to determine the controller and method. We concat these and put them as the page title. This makes reports in GA much easier to read and categorize. This is great for getting usage data, but what would be better is if analytics could tell us about non-200 HTTP response codes.

Sending Ajax Errors to Google Analytics

In our application we use jQuery’s ajaxError callback for a whole bunch of things. In this example we use ajaxError to send errors to GA. This data can be accessed in the events section in GA. Since all data is displayed in real-time you can indeed catch errors as your customers are catching them. First, if your application is not a single domain you’ll want to tell Analytics to track all domains under a single account with the _setDomainName property. We did the following:

Next go into Analytics > Events > Pages and add a “hostname” as a secondary dimension to the report. You can exlcude certain host names such as local, staging, (not set) by using an advanced filter. We were surprised by some of the errors that were going unreported by customers.

Final Thoughts

I’m looking forward to leveraging this tool more in the future. Not only is it a nice error reporting tool, but this data can be used to determine what portions of an application are used more or less than originally thought. This opens up interesting possibilities:

  • If a page is under-utilized should it be moved out of the main navigation into a sub-module?
  • Should an under-utilized page be condensed into another page thus reducing navigation clutter?
  • What about pages that are utilized more than previously thought? Do we add these to the navigation?
  • Are nested pages being accessed more frequently than thought?
  • Can an application search feature get users to their desired destination in fewer steps?
  • Is bounce-rate a valuable metric?
  • Is there value in setting up goals?
  • Mo’ data, mo’ problems.

Once we know something, we find it hard to imagine what it was like not to know it.

– Chip & Dan Heath, Authors of Made to Stick, Switch