During a web analytics implementation (or audit), you need to check whether the data is being collected as planned. You can do that as follows:
The Basics: View Source Code
To identify whether basic code is on the page, you can often visit the site > right-click> View Source. Here I’ll use popular Q&A site Quora.com as an example:
Then, hit Ctrl-F to search for “UA-” or “_gaq” (no quote marks). This should bring up something like this:
We’re now looking at Quora’s Google Analytics source code. Here’s where you can visually check that the code is up to date, the account number is right, the vars are being named right, etc. A quick review shows that Quora could remove the _trackPageLoadTime method that’s been deprecated. Also some of those page-level scope variables look like they should actually be session-level. This shows the power of viewing the source code — it’s really easy!
Real QA: Download a Debugger
The trouble with the above method is that sometimes the code is obscured or minified so it’s not visible on the page. Also, even if the source code looks correct, there could be some issue preventing anything from being sent to GA’s servers. This is why we use debugging tools to identify exactly what is being sent to GA’s servers. These are some recommended tools:
|Omnibug||http://www.rosssimpson.com/dev/omnibug.html||this is an add-on for Firebug. Only works in Firefox. Tracks Omniture and GA|
|WASP||http://webanalyticssolutionprofiler.com/try.htm||Firefox only. Tracks a wide variety of web analytics and advertising tools in an easy-to-read format.|
|Chrome GA Debugger||https://chrome.google.com/webstore/detail/jnkmfdileelhofjcijamephohjechhna||Chrome only. Only tracks GA. In my experience it doesn’t work that well, but it’s the only debugger I know of for Chrome.|
Using these tools, you can verify that the code is actually firing and sending the right information.
Example using Omnibug Debugger
This is a screenshot of what quora.com looks like in the Omnibug debugger, so you can match it back to the original source code we viewed above.
For a full list of what these parameters correspond to, you can check GA’s reference document at https://developers.google.com/analytics/resources/concepts/gaConceptsTrackingOverview. However, I’ll focus on a few of the most useful ones here:
1) utme. This is the parameter that shows what is being sent as a custom var or event. If it is prefaced with an 8 (as you can see above) it reflects custom var names, if it’s prefaced with a 9 it reflects custom var values, and if it’s prefaced with a 5 it reflects events. An 11 will reflect scope. For custom vars, all the var names will be in the first array (the first set of parentheses), all the var values will be in the second array, and all the scopes will be in the third array. I put those arrows in to show more explicitly how they all match up.
Note that if you see an exclamation point like 3!2, this indicates what slot it refers to if the previous slots were not used. So in this case it’s telling us that scope 2 applies to custom var 3. No scope shows up if it uses the default of 3 (page level), so in those cases you’ll see the exclamation point indicating an offset.
2) utmp. This shows the page name that is being sent to GA. Useful if you are debugging virtual page names.
3) utmac. This is the account ID. Make sure you’re sending to the right place!
4) utmcc. This holds the cookie values. While there is a lot of interesting data in there, the most frequently used is the campaign information. This is where you can check, say, that you’ve tagged your emails properly or that your AdWords auto-tagging is turned on.
The most useful one that is not shown above is utmt. utmt indicates what kind of request it is: event, transaction, item, or custom variable. If it’s not present (as above) it is a standard page view tag.
If you have an ecommerce site, the process is the same, but note that you will have to buy a product and go all the way to the receipt page. If you are in a QA or staging environment, this shouldn’t be an issue, otherwise get used to canceling quickly 😀
For QA’ing to be effective, you need to check EVERYTHING. It is important to be extremely thorough — check every event, every custom variable, every page template. You don’t want to find out later that data is missing or broken, because there is no way to go back and collect it again. Hopefully this post helps get you started with the mechanics of how to QA and debug your web analytics implementation.