Google Analytics is a wonderful tool for tracking the behavior of visitors to a web site, but one of the things that has always been challenging for site administrators is finding a way to embed the javascript necessary to track visits via Google Analytics in to every page on a web server.  Google recommends strategies like providing server-side includes with the code embedded – but that will only work if every site on a server is using the same programming language or else is able to make use of the same set of server-side include files.  Often, that’s not the case.

If you’re running IIS 7 or later, you can now easily take care of Google Analytics code inclusion by creating an outbound rewrite rule via the web server. This outbound rule can make sure that the Google Analytics code gets injected on the response from your server to any requests.  This is helpful in a couple of ways.  When new sites or content is created, there’s no need to worry about modifying the sites or code itself to include Google Analytics. Additionally, because the script injection is handled as an outbound rule, it isn’t going to matter if the site being visited is .NET, PHP, or simply HTML – the web server include the tracking code regardless.

Setting Up the Rule

Setting up an outbound Google Analytics rule is pretty easy – but there are a couple of things to watch out for that we’ll talk about in just a moment.  First, let’s quickly step through setting up the rule.

As a first step, open up IIS Manager, and in the connections window, highlight the site that you wish to create a rule for.  Once highlighted, the features for that site should appear in the right hand side of your IIS Manager window.  In the features section, double-click on the feature labeled “URL Rewrite”.

In the “Actions” pane, click “Add Rule”, and a modal window will launch allowing you to define the type of rule that you want to create.  In this instance, we want to create an outbound rule using the blank outbound rule template found in the modal window.

1. Give the outbound rule a recognizable name
2. In the “Precondition” drop down menu, choose “Create a new precondition”
3. Define the precondition using regular expressions, and add the variable {RESPONSE_CONTENT_TYPE} as the input, selecting “Matches the Pattern”, and then adding the value “^text/html” as the pattern to match.
4. After saving your precondition, verify that the name you gave it is listed in the drop down list of the “Precondition” section of the rule that you’re creating.  If not, select it before continuing.
5. In the “Match” section of rule definition, choose “Response” as the matching scope.  Leave “Match the content within” blank, and in the “Content” drop down, choose “Matches the Pattern” using “Exact Match”.
6. In the “Pattern” section, enter “</head”>, and choose the “Ignore case” check box.
7. Leave the “Conditions” section blank, and move on to the “Rewrite” section.
8. Select “Rewrite” as the action type, and in the value, past the Google Analytics tracking code.   Make sure that “Stop processing of subsequent rules” is left unchecked – and save your rule.

Prepping the Tracking Code

There are just a couple of things that you’ll want to do to prepare the Google Analytics tracking code so that you can use it as a URL Rewrite rule within IIS.

First, paste the entire block of tracking code in to a text editor (I recommend BBEdit for Mac users or Sublime Text for Mac or Windows users) and remove any carriage returns/line breaks, leaving yourself with the entire block of tracking code from <script> to </script> on a single line.

Next, at the end of this single line, append </head> so that when the rule removes the initial </head> tag and injects the tracking code instead, the </head> code is replaced after injection.

Finally, as a last step, IIS has trouble interpreting left curly braces as a part of URL Rewrite rule syntax.  The Google Analytics tracking code uses the left curly brace by default in almost all of its iterations – so you’ll need to manually inspect the tracking code in your text editor, and replace any instance of “{” with “{UrlDecode:%7B}”.

Testing the Rule

Once you’ve finished with rule creation, click “Apply” and then check to make sure that the code is being correctly included by requesting a page on your site in a web browser.  When the page is returned, view the source of the page and make sure that the tracking code is being included in the appropriate location.

Watch Out For

• If you find after creating the rule that you’re encountering a javascript error message along the lines of “Uncaught SyntaxError: Unexpected token….” then you’ve likely missed a left curly brace in the tracking code in your rule.  Go back and make sure that any reference to left curly braces are URLDecoded as noted in “Prepping the Tracking Code”.
• If you run pages that make use of Adobe’s ColdFusion server, note that ColdFusion compresses outbound content, and IIS outbound rules will not work if the response is compressed since the response won’t be readable by the rule definitions. This will cause a 500 Server error on ColdFusion pages.  The best solutions I’ve been able to come up with for these sites is to disable the outbound rule on ColdFusion based sites and instead include the tracking code manually for those sites in an include file. If someone knows of a better way to solve the issue with ColdFusion pages, please let me know in the comments.