Web Entwickler Frontend

Google Analytics and Responsive Web Design - Introducing Responsive Tracking

In responsive web design (RWD) the sections of a page get rearranged with the help of CSS3 media queries. In general, the most valuable content for the user will be placed highest on the page to avoid unnecessary scrolling on a mobile device. Less useful content will fill up the lower sections. An important element for the conversion could be a searchbox, a product description or an article depending on the type of website or the business behind it.

By reordering the hierarchy of the page's sections and components, some parts will lose the precious focus of the user. To get an idea of how a user interacts with those components, we need a method to track specific events on mobile devices.
To create another buzzword, let's call it Responsive Tracking.


The issue

Let's assume we want to track the clicks on a certain button on a mobile device. In the desktop version it may be placed on the right hand side. This will move the button far down the page on a 480px viewport size - far below "the fold" shown in the red area seen below. As a consequence, the button will no longer be as prominent as it used to be. Being data driven when it comes to change, we need to measure how often it is being clicked.

The place of a button (red box) on a desktop and a mobile device.

To gather information about how the button converts and if the visitor of the site interacts with it, we track the clicks on it but only at a viewport size of 480px.


The idea

As we all know, it's not possible to fire a Javascript event via a media query in the CSS file. That means a solution based on Javascript is needed to trigger the event tracking. A solution to simply detect the viewport size is already available in Javascript (here's Andy Langton's approach to it). However, it's not able to catch and then react to a viewport change like a switch from portrait to landscape mode and back.

Event tracking in Google Analytics (GA) are simple Javascript methods that send customized values through a tracking pixel (_utm.gif) to your GA account. Once processed in GA, those values are counted and displayed in the Event Overview section. This makes it very easy to send customized values into GA. Fortunately there is already a snippet that fits our needs and forms the basis for Responsive Tracking.

At this point, enquire.js comes into play. enquire.js is a Javascript library without any dependencies on jQuery (even if we'll use it in this example anyway) or other similar libraries. It's lightweight (less than 1kb when GZIP'd and minified) and very easy to use. It works with the simple syntax know from the CSS media queries to set up the detection rules. Here's an example of how it looks.

enquire.register("screen and (max-width:1000px)", {
    match : function() { console.log('1000px'); }


The solution

Let's go back to the test scenario and let's assume the button we want to track isn't a real button, it's an email-link to contact the service team of a shop with the appearance of a button. The GA-code, jQuery and enquire.js are already implemented into the page and the only thing to do is to add a function to fire the event when the email was clicked. Sounds easy? Indeed it is…

The tricky part is that we only want the event to be fired when the user is within the 480px viewport range, therefore we'll dynamically apply a class to the anchor-element and remove it when the screen size is larger than this. The function to achieve this with the help of enquire.js looks like this:

$(function() { 

  var query = "screen and (max-width:480px)";
  var iconMail = $(".icon-mail");

  function respClass(className) {
    return {
      match : function() {
        console.log('add class 480px');
      unmatch : function() {
        console.log('remove class 480px');
    .register(query, respClass("clickMail"))

Explanation: At first the media query (var query) is set to a maximum width of 480px and the class of the element we want to manipulate is being declared (.icon-mail).
The next function defines the behavior when the viewport matches or respectively unmatches a width of 480px. In this case the class called .clickMail is added to or removed from the element. console.log is just for debugging purposes and posts a message to the console of the Dev Tools when the viewport matches. It can be removed after debugging.
The last paragraph initializes enquire.js and, by adding the handler listen(), the event is going to be fired each time the user enters or leaves the 480px range.
Next we'll build the click-event for the dynamically applied class clickMail with jQuery:

$(".clickMail").live("click", function() { 
    _gaq.push(['_setAccount', 'UA-XXXXXXXX-X']); 
    _gaq.push(['_trackEvent', 'Get In Touch', 'Click Email at 480px']); 
    console.log('Email clicked at 480px'); 

We use the jQuery event handler live() here, because the class was added dynamically to the element and isn't present in the DOM when it is first rendered. Without this handler, the click event won't be fired and that's the simple reason why we use jQuery for this case. The next two lines represent the GA tracking code for events. We provide the account-ID as well as the event with the category "Get In Touch" and the title "Click Email at 480px". Category and title are defined by the analyst to make sure that the events can be kept apart from each other. Learn more about tracking events in GA at Tracking Basics (Asynchronous Syntax).

Tracking in GA
Tracked events in GA's overview section

If everything works fine, the result will appear in the Events Overview in the Content section of Google Analytics. You can filter the events by clicking on the category name. If you want to easily set up and configure tracking events for GA, you can use Raven's Google Analytics Configuration Tool.
At this point we have achieved to set up a simple solution to track events in RWD.

Unfortunately debugging the code can be a pain because it takes up to 24h until the results appear.


Quick tip for debugging

For debugging the code we use the Developer Tools of Google Chrome. I know that there are several extension like Google Analytics Debugger for Chrome and Firefox making it more easy to read out the data within the headers of the tracking pixel. But I choose the Developer Tools to avoid cluttering my browser with extensions and plugins. People often aren't aware of the capabilities the Dev Tools provided. So let's dive into it.

After implementing the function for the tracking of the event into the source code of the website, we first open the site and then the Dev Tools in Chrome (hit F12). To be sure to match 480px we scale the browser window down until the console displays the add class 480px message. After clicking the element we want to track the event should be fired. We can examine it by clicking on Network in the Dev Tool panel and check the last entries. Here we can see if the __utm.gif was fired (see screenshot below, top section). If not, check the code of enquire.js and the jQuery handlers. If so, click on the item to open the details of the header.
Within the headers you should see the domain, the values of your event (category, title, …) and the ID of your GA account. If not, you should check the event tracking code of GA.

debug view of Chrome
Top: check if the analytics-gif has been send. Bottom: check the headers and if all informationn are contained in it.

As simple as the implementation is, I'm looking forward to hear your thoughts, ideas and improvements.


Alistair Lattimore

Henry, Great article, I shared it into Google Analytics Google+ community and Twitter just now. In the Google+ post I made, I mentioned that I'd use the standard screen resolution reports in Google Analytics to track macro conversions like a form submission instead of your responsive solution. I realise that there would be some discrepancies in the tracking if a user switches their device orientation but I think the trend is more important in this instance. I'd be more inclined to use this ability to track micro conversions or feature use within a responsive website I think. Again though, if you've got enough traffic to your site, does improving the tracking make that much difference if the trends are already clear? What was your motivation for putting this together, just to see if you could get better data or did you have a tracking issue you were trying to solve specifically? Also, what other items do you think would be worth while tracking with a response web design aware script like you've put together above? Regards, Al. Gold Coast, Australia.

am 10.02.2013


Henry Zeitler

Hi Alistair, apologies for answering so late, we’ve had a few busy days here. Thank you for commenting and sharing the article. The idea behind it was to have an option for tracking interaction with an element, i. e. for A/B-Testing purposes in an responsive environment. It's not about trying to gain more traffic, it's more about collecting data on conversion and goals. I could imagine using this on social share buttons, RSS Feed links and even shopping carts depending on their realignment and position in the device’s viewport. I hope this is useful for you. Henry

am 15.02.2013



Now whilst I find this idea mildly interesting I don't see the point. For a start depending on the size of your site, you will have greatly increased the total load and I get the impression here that you're only concerned at seeing whether your CTA still works if you have it lower in your perceived document hierarchy. Well it doesn't matter, because if you actually wanted those items further up the document you could have put them there. Your example shows a very common but ultimately crass layout. You have two columns and assuming that the content of column two will collapse under column one. However, if you do some looking around into the concepts and patterns that both Brad Frost and Luke Wroblewski have shared you might have started to think more about how you design your layouts so that if you want those content blocks within the context of the main content they are accompanying you could have built your layout to faciliate that.

am 02.03.2013



Avangelist, I don't think redesign techniques was the point of this post. You know there are many factors when its comes to these projects. Just following a pattern someone has made with a few lines of code is not always that easy. This technique will benefit a lot of professionals, and yourself being a professional, can surely respect and comprehend that, for different situations. Not everyone has 100% control or infinite amount of time, not even Luke or Brad. One could be very critical of their actual paid work also in some circumstances. Thanks for the article. Nice to see someone utilizing enquire in a tutorial! I've been a fan for a very long time!

am 02.03.2013


Henry Zeitler

Thx a lot for your feedback. @John: Thx for clarifaction, that's the exact intention of my post. I'm looking forward to hear other opinions as well...

am 04.03.2013


Otto Ringborg

Very good indeed! The one problem I see is that this needs coding, a release and so on. This shouldn't be the case 2013. Check out this http://innometrics.com/product/web-analytics. Whith this tag management solution you can do this using drag and drop and then have it live within minutes.

am 05.03.2013


Antoine Frange

The idea is interesting, although it would be easier to : 1/ Pass the resolution as a Label : _gaq.push(['_trackEvent', 'Get In Touch', 'Click Email', 'Res=480px']); OR 2/ Pass the resolution as a Custom Variable : _gaq.push(['_setCustomVar',1,'Items Removed','Yes',3]); A custom variable will apply to all Events on the page, so you can see all clicks on all buttons for this resolution.

am 06.03.2013



This is fantastic and very useful. Can't wait to implement it and play around. If you haven't heard of it, the Google Analytics Debugger for Chrome is pretty good. So long as you can replicate every triggering event, you'll be able to see the Event Tracking fire in the console. (https://chrome.google.com/webstore/detail/google-analytics-debugger/jnkmfdileelhofjcijamephohjechhna)

am 09.04.2013


Akshaya Raghuvanshi

Really good article. Everyone who wants to go more deeper in Responsive Web Design must read this. And I am gonna use enquire.js now.

am 21.04.2013

Kommentar hinzufügen
Vor und Zuname
E-Mail bei weiteren Kommentaren
Mein Kommentar