Perhaps you have heard someone else utter these unfortunate words, or maybe you have heard yourself say them as your stomach cringed and tried to run away from the implications. No requests were made to change analytics code, but something clearly changed. What do you do now?
In the majority of cases, the code does not just simply change itself, so most data anomalies align with some sort of code push, new site release, etc. Even the slightest oversight can send your numbers plummeting for the 0-line, so a bit of additional QA is highly recommended. If an official QA team is not working for your analytics department (which may simply be you), then the job falls into your own hands.
And I'm here to help you do that job in a few quick minutes.
In order to run these spot-checks, you will need a few tools of the trade. Namely, some sort of traffic sniffer. My two favorites are:
· HTTPFox: FireFox add-on, can be found here
· Fiddler: Commonly used with IE, can be found here
If possible, I try to use FireFox, as HTTPFox makes me smile the biggest. However, if you happen to be restricted to using IE, Fiddler will serve just fine. These programs will help you monitor the requests made when you load a page from your site. The key will be looking for the image request made by your analytics tag, but we'll cross that bridge when we get to it.
A Google Analytics Example
The techniques below (and tools above) will work for basically every analytics vendor, but I'm going to use Google Analytics in the example. The process includes three steps:
1. Double-check that the tag is still resting peacefully on the site.
2. Confirm the tag is firing an image request.
3. Confirm data is populating in your reports the very next day.
It might be the case that Step 3 failed and caused the panic in the first place, but I wanted to include it as the last step in case the process is being followed immediately after a new code push/site deployment. We'll start from the top.
Where's My Tag?
First, you want to view the source. Simply right-click on some empty piece of real-estate on the page and choose "View Source" or "View Page Source" from the context menu:
Usually, your browser will dynamically look for items as you type, so once you are finished, you'll see one of two results:
· A highlighted '/ga.js' on the page, as seen below
Some message that the string was not found.
Before we make that leap, let's take a bit of a closer look at our GA tag. We need to confirm two things are happening:
1. The appropriate account is being set.
2. The _trackPageview function is being called.
Depending on when you installed GA onto your site, you may have the Asynchronous code, which looks like:
Or the Synchronous code, which looks like:
In both examples, the key points are highlighted in red or blue. Please confirm that the account ID (in blue) in the tag matches the ID you see in your GA account in the header of the profiles you are using for that particular site. Depending on your implementation you may have otherfunctions being called, but these absolutely should be on every page.
You've confirmed the code is on the page (or not). Now we can check for an image request!
Where's My Image?
Our traffic sniffers will now come in handy, as we want to see what is loaded when the page loads. HTTPFox has dynamic filtering on the results, so I greatly prefer spot-checking in FireFox. If you are using Fiddler, just keep it open while the page loads, though you'll have todo some sifting through the results. The image we are looking for is:
Within HTTPFox, simply filtering for "utm.gif" should restrict the results to just the requests that the tag would be making. The following image shows a few key points of HTTPFox. The red box surrounds the icon that must be clicked to pop up the HTTPFox interface. The blue rectangle highlights the button that must be clicked *before* loading the page. The green rectangle highlights the filtering text box where "utm.gif" would be entered.
If you reload the page while HTTPFox is running and see no results, there's a very good chance your tag is not firing. This problem could be because you did not find the tag in the source before, or perhaps you did find the tag but you do not see an image. More complex problems could be the root cause, but our job is to locate the break in the circuit, so we are keeping our observations fairly binary. In other words, the image did or did not fire.
If we are feeling adventurous, then we can take our analysis of the image one step further, just for diligence. You'll notice the above screenshot has a "Query String" tab in HTTPFox. This tab allows us to see all of the different parameters being sent with the GA image. Feel free to explore this to find out how you can check out referrers, the page URI that's being passed, etc. However, we're going to double-check the account ID being passed to insure it matches the ID in our tag, as well as the appropriate ID in your GA account. The parameter we're looking for is "utmac", as seen below:
You may have to scroll down a bit to find the utmac parameter, but it should always be there.
So we've found the tag on the page, and we've confirmed that the tag is firing the appropriate image request to Google. If we know the account IDs line up and everything is firing, then we should see data in our profiles.
Where's My Data?
The last step is to simply check the profile the next day to confirm that data is flowing in properly. Of course, there could be various anomalies that occur with new site releases and browser compatibilities, but that analysis is better served in another blog post.
Extrapolating for Other Tools
That's it for today. I encourage all of you to be the vigilant superheroes I know you happen to be. Ta ta for now!