Quality assurance using WASP: tag all pages

In a post from a year ago, I was commenting on the challenges of JavaScript tagging. Here, I want to share some insight and advantaged of doing web analytics implementation quality assurance using WASP. This will take the form of a series of posts, each one addressing a specific issue.

Tag all your pages!

First and foremost, we need to make sure all pages are tagged. Obvious isn't it?

What strikes me when beginning with a new client is how bad their web analytics implementation is. Missing tags is the #1 problem to look into. Sadly, the area that are left out are transactional areas: the outcomes! Why?

• It's more complex to tag transactions beyond the mere "page view" tags
• Content areas are often rendered out of templates, transactions require case by case tagging to be implemented
• Transactions are often under the realm of IT and changing them implies "negotiation" for resources, timely delivery, tests and answering any security considerations.
• In some cases, transactions are on a different host and even a different technology altogether
  

The WASP advantage

Using a crawler such as the excellent SiteScan by EpikOne to check if all pages are tagged is a start, but it's not enough (plus, that's fine for Google Analytics but none others). A crawler won't be able to log into secure areas of your site, fill forms and execute transactions. Most crawlers will look for a specific string within a page, so even if the JavaScript code is there it doesn't guaranty it will be executed (more on JavaScript execution in a later post). Using the debugger provided by the solution provider, such as the one from Omniture, is fine for ad hoc tests, but hardly usable and often hard to decipher. Using proxys such as Charles, ieWatch or Fiddler is interesting, but they work at a lower network level and are way too technical. The other alternative is to open your wallet and work with Maxamine to do a complete and thorough web analytics, security, web compliance audit.

Because WASP blends itself into your browsing session, you will be able to go into any area of your site and make sure the tags are correctly implemented, even checking if specific parameters are being set correctly: custom variables, events, segmentation, etc.

Simply put, I'm from the school who think quality assurance of transactions can hardly be automated. You have to define test scenarios and diligently go through them not only to make sure the transaction work as expected and provides the appropriate results, but also to make sure you are measuring them correctly.

Coming up in WASP

The next release of WASP will include a couple of long awaited features:

1. Site crawl*: from any page, launch a recursive crawl of all pages on that same site.
2. List of links to parse*: already have a list of URL you would like to scan? Simply open the file and WASP will visit all of them and report back the results.
   

This is perfect to check the non-transactional pages of your site. For transactions, you will still be able to use the passive page checking already offered.

You will also get two ways of viewing the information:

1. Web analytics implement view: what's currently shown by WASP
2. Web analyst view*: showing simplified and plain English information about the tags found on that page.

Another request that was on queue: results are going to be available as a CSV file with domain, page, web analytics solution found as well as the exact data sent.

* Those features will be part of an advanced version of WASP available on a subscription base/purchase only.