Product Management Insight

When we discuss Web Analytics, we talk about Implementation, Reporting/Analysis and offering recommendations on how to improve a website. QA/Testing is something which is often put in the backburner. Companies focus on the Analysis of data but don’t usually concentrate on the validity of data. This often leads to reimplementation of code and the data being inaccurate. This is not good news for companies tagging their website with Web Analytics code and paying for Implementation and Analysis. This article at a high level explains some of the things which may help improve the Web Analytics QA process of organizations. These are some of the points which can be useful for Web Analysts looking to setup a Web Analytics QA process.

1) Spread the word: Spread awareness about Web Analytics QA benefits to your Manager/Stakeholders specifying how thorough Web Analytics QA can help them save cost in the future. For e.g. you can tell them that proper Web Analytics of the code/data can help companies reduce repetitive fixes/patches of code or resultant skewness of numbers while performing Analysis.
2) Include in release cycles: Try to incorporate Web Analytics QA in the weekly/monthly release cycles by bringing into perspective all stakeholders from QA Analysts, Developers to Program/Project Managers. It might involve lot of patience, persistence and convincing but it is worth the time. Come up with a process document/Flow chart depicting the QA process and share it with the concerned teams.
3) Performing QA/Knowledge Transfer: Once the Web Analytics QA process has been approved, start off by performing QA yourself and transition this responsibility to the resident QA Analysts as a Web Analyst should be involved more with Analysis/client interaction etc. Sharing tutorials about different Web Analytics tools might be helpful to pass on to the QA Analyst.
4) Create a reusable test document: Once the training has been imparted, the QA Analyst or Web Analyst can create a test document to perform Web Analytics testing. The QA document should leverage a Packet Sniffer (explained in my previous article) and should also validate data in the Web Analytics tool. For e.g. the below screenshot makes use of conditional formatting to color incorrect values (not matching requirement) as Red and correct values as green. This is a screenshot taken from a QA document which I created in one of my assignments where we were QA’ing Omniture data. This document helps in validating the code as well as checking the output and should be reusable.



Hope you like this post. Please comment in case you agree/disagree with my analogy about Web Analytics QA process being an integral part of a Web Analytics assignment.

I came across a question on Yahoo Web Analytic Group regarding debugging tracking code on a webpage without having access to the Web Analytics tool. The answers to this question can be more than one but based on my experience, the best way to check Web Analytics code on a page is to use a Packet Sniffer.

A Packet Sniffer or HTTP/JavaScript Debugger as it is known is a tool that analyzes and parses network traffic. There are many other uses of a Packet Sniffer but in this case we are only looking at capturing HTTP/JavaScript packets. So if I have a webpage containing Google Analytics code, all I need to do is activate this software while the webpage is being loaded. Once the entire code snippet on the page has been loaded, you can go to the Packet Sniffer tool and search for the Google Analytics code from the list of captured packets.

Let us look at an example by going to www.msn.com and capturing the Omniture Web Analytics tag on their webpage using a tool called Fiddler. Please look at the 2 screenshots captured after the MSN-US page load was complete.


The first image is an overall summary of all the code being rendered with the Omniture code highlighted in Blue. Please note that for an Analytics JavaScript code to be successfully rendered, it has to make a ‘Status 200' call to the respective Datacenter meaning the request has been completed. Now double click on the captured snippet and look at the second screenshot for the next step.


After double clicking on the Omniture code, you will have to click on the Web Forms tab on the top right in order to view the various parameters being passed onto Omniture. You will notice all the various parameters being sent to Omniture like the Page name, Language, Screen resolution and so on. This step will also tell us whether the custom variables we passed on the analytics code are being sent correctly or not.

Packet Sniffers have a very important role to play in Web Analytics as they can help fix issues like data not being present in the reports to discrepancy in numbers. Finally listed below are a few more HTTP Debugger tools that I’m aware of:

1) Adobe Experience Cloud Debugger
2) Charles Proxy
3) Debugger for Adobe Analytics