Advanced Analytics Debugging: No Code Access? – No Problem!

A typical day in the life of a Web Analyst: On a certain web page, something is not being tracked the way it should. Looking at the source code, you are almost certain that adding, deleting or rewriting just that one line of Analytics code would make it work. But how do you verify that if you cannot change that code yourself?

Web Analysts are usually not developers and often have to find errors in systems where they have little to no access to the code base or the server-side templates where the HTML and JavaScript code comes from. You can make hypotheses about how to solve these errors, but in order to test these hypotheses, you often need a developer to update the code first according to your hypothesis.

Say hi to Fiddler, the browser-independent HTTP debugger and manipulator

To get the testing job done without the developer help, you first need Fiddler, a free HTTP debugging and traffic manipulation tool. Remember that, unlike browser-plugin-based debugging tools like Chrome GA Debugger (see my article here), the very basic Google Tag Assistant, or the flashy WASP, the basic advantage of Fiddler is that it is browser-independent. This is important since there are still many bugs that only happen in Internet Explorer or Firefox for example. With Fiddler, you can even debug your iPhone apps or anything else that does not run through a classic browser. And you can manipulate the web pages and files that you up- or download from the web before they render in your browser – and thus, as if they had come like that from the server itself.

I have published a little video here already a while ago about the basic debugging functions of Fiddler, so if you have not heard about Fiddler yet, do watch that video first. It shows you how to use:

• The filters to capture only the requests you need (e.g. the Google/Adobe/Webtrends Analytics HTTP requests)
• The inspector tab where you can investigate all the request’s parameters under “Web Forms”
• The AutoResponder that allows you to “kill” specific files or replace one (JavaScript or other) file by another one on your computer or somewhere else

I am now going to show another technique that allows you to change the very code of the web pages you are debugging.

Rewrite the HTML with FiddlerScript

As shown in the video mentioned above, with the AutoResponder, you can easily have your browser load the file you want instead of the default one. So if the code you want to debug is in that specific analytics_code.js file, you just download that file, change it the way you think it could work, save it to your hard drive as “my_analytics_test_code.js”, and then tell the AutoResponder that whenever it encounters “analytics_code.js”, it shall replace that file by the test file on your PC. 

This helps with many cases. I also use it to inject and test new tracking code to make sure it really works before giving it to the developers. That saves me test cycles and communication time.

But there are some cases where you really have to alter the very HTML code of the page, not simply replace an entire file. Examples when you need this are: 

• You want to change a line (or more) of the tracking code inside of your HTML, e.g. add a Webtrends HTML meta tag or a custom variable for Adobe Analytics or Google Analytics
• You want to rewrite an inline Event Tracking call (“inline” are those “onclick” handlers that are inside the link, e.g. < a onclick=”yourcall” >Link< /a >. You should avoid them by the way to keep JavaScript and HTML separate so it is less likely that you have to resort to the method I am describing here)
• You want to test-drive another tool, for example a Tag Management System, a heatmap tool, some conversion tracking for your email marketing tool, or whatever else that requires you to insert code into the web page – which would usually mean working yourself through your development release cycle first (and wait months, ask for budget etc…)
• You want to check whether it is the Tag Management System’s fault that a tag is not working. I had this case recently with a tag in Google Tag Manager (GTM). When I inserted it “the traditional way” by rewriting the HTML via Fiddler, I saw that the tag fired correctly. I realized that it was one of those tags that have to load synchronously, but GTM can only fire tags asynchronously (see some more drawbacks of Google Tag Manager). After some more hours of re-coding the tag, I finally got it working via GTM as well.

So let’s get to it. Again, this is how you simulate a change in a section of the HTML code of a page in your browser without having access to the code file itself:

1. Download the AddOn “FiddlerScript” and execute: http://www.telerik.com/fiddler/add-ons => “Syntax-Highlighting Add-Ons”
2. Restart Fiddler. There is now a tab “FiddlerScript”:
   
3. Click on that tab. You should see a lot of code:
   
   You can get really nasty here with all kinds of possible traffic manipulations, but that is pretty hard without deeper know-how (if you want to dive into it, I recommend http://fiddler2.com/r/?fiddlerscriptcookbook ). But don’t worry, our “Rewrite HTML” example does not need you to understand any of this code.
    
4. First, find “static function OnBeforeResponse” via the “Find…” field (marked in red in the screenshot above). You should be moved to the following code section:

5. After this section (still before the closing curly bracket of the “function OnBeforeResponse”), fill in the following code. The parts in bold are those that you have to fill individually depending on what you want to do. These are just some examples.
   

    You can add as many lines of “oSession.utilReplaceInResponse(‘replace this text’,’by this text’);” Note that you can of course use only double quotes (as in the example src=”iamhere.js” and not ‘iamhere.js’) or you need to escape the single quotes (\’).

6. The whole OnBeforeResponse section should now look like this:

   

7. Click on “Save Script”. If Fiddler’s capturing is switched on (check if it says “Capturing” in the lower left corner), this page should now have a lot of underlined text since we exchanged the < strong > tags for the < u > tags

We can also check out the HTML source code now and we see that we have indeed inserted a script reference to “iamhere.js”, a file that of course does not exist (think of the JS file for the tool you want to try out here).

Make sure your test data doesn’t go where the “true visitor” data goes

Fiddler makes it possible to debug and test code on the production (live) website in your browser. That is awesome because the live website is publicly available (no need to ask three different people for passwords and special links to finally get to that test platform), the live system is usually faster than most test systems, and it is 100 percent the system the user is experiencing. Little things like a different (sub)domain or lack of SSL encryption on a test system can sometimes weaken the reliability of Analytics debugging results.

But one thing that is not so nice when you debug on the production system (sometimes you have no choice) is that you are constantly sending test data to the live data bucket of your Analytics tool. Especially when you test a shop and constantly create purchases, you will skew the conversion rate and revenue considerably, especially on smaller sites. That is why I use the following method to re-route anything I test to the data bucket for test data or, if there is none or I don’t care about it, send it to Nirvana.

In the case of WebAnalyticsWorld, I can simply rewrite the line where Google Analytics sets the Account and Property ID. I don’t know the test data bucket for WebAnalyticsWorld, so I simply use a syntactically valid property ID that (hopefully) no-one really uses (000000-0):

_gaq.push(['_setAccount', 'UA-4778560-3']);

 gets replaced by

_gaq.push(['_setAccount', '000000-0']);

To accomplish this, I add another line into the section mentioned above under 5.:

oSession.utilReplaceInResponse('4778560-3','000000-0');

I save the FiddlerScript, et voilà: Instead of polluting Angela Wilkinson’s precious Google Analytics property UA-4778560-3 with all my garbage data, I send it to the mysterious property ID 000000-0 which is owned by Nirvana.

Questions? Suggestions? Own experiences?

I hope this post helps you to ensure better Analytics data quality and to find bugs faster in the future. I am keen on any suggestions and will gladly answer questions in the comments. If you have your own time-saving debugging method in Fiddler or any other tool, please do share it!