Article Archive by Author

June 16 2011

12 easy tools, add-ons, and resources to troubleshoot your web analytics implementation

by

A clean, proper, and accurate web analytics implementation equals a happy marketer, analyst and website owner.

If you’ve ever worked with Google Analytics, Omniture SiteCatalyst, WebTrends, Coremetrics, ClickTracks or IBM’s web analytics solutions, you probably realized at some point that implementing web analytics is much more than copying and pasting one snippet of JavaScript on all of your website pages. There are eProps, sVars, events, variables, customizations, conditions, dynamic values, and all kinds of mayhem that goes along with a healthy and robust web analytics implementation.

Before you send your next Email to your web developer or IT team asking for something to be repaired with your analytics platform, you can likely identify potential problems very easily, so that you can point your hard working tech team in the right direction. And, if you are in the IT team, you can use the following list of tools to troubleshoot an analytics implementation before you do any work.

So, have a gander at the following list of tools, and go install them today. They will definitely help identify errors, issues, bugs, missing snippets, and many other things to allow you to have the cleanest, most successful web analytics implementation possible!

1. HTTP Fox
Good for: Any web analytics platform
Supported Browsers: Firefox
Link: https://addons.mozilla.org/en-us/firefox/addon/httpfox/

HTTP Fox is a bare essential for any web developer. This browser add on “...monitors and analyzes all incoming and outgoing HTTP traffic between the browser and the web servers.

2. Firebug
Good for: Any web analytics platform
Supported Browsers: Firefox (Full Version); Any browser (Lite Version)
Link (Full): https://addons.mozilla.org/en-US/firefox/addon/firebug/
Link (Lite): http://getfirebug.com/firebuglite

Firebug allows you to monitor, edit, and debug JavaScript (web analytics snippets), HTML, and CSS on any webpage.

3. WASP
Good for: Any web analytics platform (and other programs)
Supported Browsers: Firefox
Link: http://webanalyticssolutionprofiler.com/

The Web Analytics Solution Profiler (WASP) is a great web analytics specific Firefox add-on, providing data on any tool that sets cookies or sends server requests. It also measures conversion tracking snippets, behavioral targeting tools and voice-of-customer platforms.

4. Charles
Good for: Any web analytics platform
Supported Browsers: Internet Explorer and Firefox
Link: http://www.charlesproxy.com/download/

Charles is a web debugging proxy application for any operating system using Internet Explorer or Firefox.

5. Live HTTP Headers
Good for: Any web analytics platform
Supported Browsers: Firefox
Link: http://livehttpheaders.mozdev.org/installation.html

Live HTTP headers monitors and provides additional information on requests to and from web servers.

6. Fiddler
Good for: Any web analytics platform
Supported Browsers: Internet Explorer
Link: http://www.fiddler2.com/fiddler2/

Fiddler logs and records all HTTP traffic between your Internet Explorer browser and the internet.

7. Google Analytics Tracking Code Debugger
Good for: Google Analytics
Supported Browsers: Chrome
Link: https://chrome.google.com/webstore/detail/jnkmfdileelhofjcijamephohjechhna

This Chrome-only plug-in alerts you when a Google Analytics tracking code snippet is generating errors or is not functioning properly.

8. Omniture SiteCatalyst JavaScript Debugger
Good for: Omniture SiteCatalyst
Supported Browsers: Any browser
Link: http://www.webanalyticscentral.com/2009/12/09/how-to-set-up-the-omniture-debugger/

This resource from the Web Analytics Central blog shows you how to use the Omniture SiteCatalyst JavaScript debugger, as well as other tips and tricks for Site Catalyst users.

9. WebTrends Troubleshooting Guide
Good for: WebTrends
Supported Browsers: Any browser
Link: http://product.webtrends.com/WRC/7.1/Documents/Troubleshooting.pdf

This great troubleshooting guide from WebTrends will help you through any WebTrends-specific issue that you are experiencing.

10. Yahoo Web Analytics Troubleshooting
Good for: Yahoo Web Analytics (IndexTools)
Supported Browsers: Any browser
Link: http://help.yahoo.com/l/us/yahoo/ywa/troubleshooting/

Users of Yahoo Web Analytics (formerly IndexTools) will love this online troubleshooting guide, filled with great technical tips and tricks.

11. Built-in Developer Tools
Good for: Any web analytics platform
Supported Browsers: Chrome
Link: http://code.google.com/chrome/devtools/docs/overview.html

Google Chrome’s browser comes built-in with developer tools that analyze server requests and detects any page-level bugs, issues, or errors.

12. Built-in Activity Window
Good for: Any web analytics platform
Supported Browsers: Safari
Link: http://www.apple.com/safari/features.html

The Safari browser has a built-in activity measurement window, where you can see activity and potential errors in real-time.

Don’t forget – any browser will allow you to view a page’s code source, which in some cases, is the best overall tool to use!

What tools did we omit? Which guides do you use? What techniques do you employ? Please leave a comment and tell us about it!

June 8 2011

How to exclude an IPv6 address from your Google Analytics profile data

by

Today is the World IPv6 Day, and every major Internet player is involved.

Essentially, the Internet is running out of connection space. The way that we connect our computers, our laptops and our mobile devices to get on to the internet is made possible by an IP address that we are assigned as we attempt to log-on and surf the web for work, for pleasure, or both.

The world is running out of IP addresses. Today, June 8, 2011, is the first world-wide scheduled test flight of an improved and enhanced method that will provide over 4 billion times more space than what we have available to us through IP addresses. This method is known as IPv6, and its successful global deployment will make it possible for every man, woman, and child in every country on every continent on Earth to access the internet.

How this process works, and a little background

Have you ever heard of the Internet Assigned Numbers Authority (IANA)? I’d bet that you probably haven’t. They have one of the most difficult and responsibility-laced jobs in the world: it’s up to the IANA to manage global IP address space allocation. Basically, every IP address in the world is tied back to the IANA.

The IANA works with five regional internet registries (known as RIR’s) to distribute blocks of these IP addresses to local registrars and internet service providers (the company that you pay for internet service).

The IANA is operated by the Internet Corporation for Assigned Numbers and Names (known as ICANN, which you may have heard of before).

So, a possible hierarchy of how an IP address eventually gets assigned to you could look something like this:

ICANN
–> IANA
—–> RIR
———->Your ISP
—————> Your Company
———————> Your computer / laptop / mobile device

A traditional IP address vs. an IPv6 address

A traditional IP address is something that looks like this:

192.168.255.255

This is the traditional IP address (an IPv4 address, to be exact). There are four octets (parts) in an IPv4 address, and each octet must be between 1 and 255. As you can imagine, this means that there are a limited number of combinations possible – 232 (4,294,967,296) addresses to be exact!

Two to the thirty-second power sounds like it’s a lot, but the truth of the matter is that we are very close to reaching that number.

An IPv6 address will look like this:

2001:db8:0:1234:0:567:8:1

Each IPv4 (traditional) address is 32 bits in size (232). An IPv6 address is 128 bits in size, which means IPv6 allows for approximately 340 undecillion addresses (2128). Yes, two to the one hundred and twenty-eight power. That’s definitely more than you can shake a stick at!

Excluding your IPv4 or IPv6 address from your Google Analytics profile data

At MoreVisibility, we feel that one of the ways that we can lend a hand is by showing you how to exclude your IP address (IPv4 or IPv6) from your Google Analytics profile data. It may be that you never are assigned an IPv6 address, or it may be that it takes years for you to get one, so the goal of this blog post is to serve as both a message in a bottle, as well as something you can do today with your traditional IPv4 address.

Let’s start excluding your own traffic from your reports!

Step-by-Step Guide:

1. Log-in to your Google Analytics account.
2. Ensure you have Administrative Access to your Google Analytics account.
3. Ensure that you are using the new version of Google Analytics.
4. Select the appropriate web property / profile that you wish to apply this filter to.
5. Click on the Filters tab.
6. Click on + New Filter.
7. Ensure that you’re creating a new filter, not choosing from an existing filter.
8. Give your filter a name and keep Predefined filter as the filter type.
9. Change the middle of the three drop-down menus to traffic from the IP addresses.
10. At this point, stop what you’re doing for now.
11. Open a new browser tab or window and visit http://www.whatismyipv6.net (or, search for “what is my IPv6 address” on Google and select from a large sampling of websites that will check your IP address).
12. Copy and paste the IP address that is returned to you, and paste it in the IP address form fields back in your Google Analytics account where you just left off.
13. If you checked your IP address and it’s an IPv4 address, place each octet, in order, in the four boxes that you will see. If you checked your IP address and it’s an IPv6 address, check the IPv6 check-box first, and then paste in your IP address into the long form field.
14. Click on Save at the bottom of the page, and you’re done!

Filters in Google Analytics can take approximately 24 hours to activate, so give your new filter about a day or so to start working.

ip-address

* Sources for this blog post: Wikipedia (IPv6) and the World IPv6 day website.

June 3 2011

Installing Site Speed tracking for Google Analytics

by

A website page’s loading time is unfortunately something that is often over-looked. Have you ever been to a website that loads slowly? Almost everyone who has used the internet has at one point or another – and it’s a highly frustrating experience. We want pages to load, and we want them to load instantly!

Today, we’re going to help every website owner using Google Analytics to measure how fast (or, how slow) their webpages are loading by showing them how to configure their JavaScript tags to collect page loading speed data for their reports.

Ready? Here we go!

Step 1: Google Analytics Tracking Code

We have been very fortunate over the years to have a frequent stream of new readers to our Analytics & Site Intelligence blog (and our other blogs here at MoreVisibility), so we’re not going to assume anything – even if you’re a new reader and you use Google Analytics.

The Google Analytics Tracking Code (GATC) is the snippet of JavaScript that you will see on the pages of your website if you view the source code of any page. Most websites today are using one of two versions of the GATC: the asynchronous version (the “async” version), or the traditional version (the “ga.js” version).

Before you can install site speed tracking, you need to know which version of the GATC your site is using.

If your code looks similar to the following example, then your site is using the “async” GATC:

<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXXX-X']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript';
ga.async = true; ga.src = ('https:' == document.location.protocol
? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga, s);
})();
</script>

If your code doesn’t look like the above example, but looks more like this second example, then your site is using the “ga.js” GATC:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol)
? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost +
"google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-XXXXXXX-X");
pageTracker._trackPageview();
</script>

Knowing the type of GATC tracking code will allow you to follow along with your own site for the remainder of this blog post.

Now, for the small number of you who don’t see either of those two examples on your site, but rather you see something like this example:

<script src="http://www.google-analytics.com/urchin.js"
type="text/javascript"></script>
<script type="text/javascript">
_uacct = "UA-XXXXXXX-X";
urchinTracker();
</script>

then, you are about to receive some bad news. Your site is using the legacy GATC model, which is also known as the “urchin.js” GATC. Site speed reporting in Google Analytics does not support the “urchin.js” tracking code. You will need to update your website pages to the “async” GATC (recommended) or the traditional “ga.js” GATC in order to be able to collect and use site speed data in your reports.

Read about the benefits of the new “async” tracking code here.

Step 2: Installing the site speed command

To pull this off, you will need to install one additional line of JavaScript in a specific location of your GATC. However, make sure to copy the correct line of code for your GATC!

If you are using the “async” GATC, copy this line:

_gaq.push(['_trackPageLoadTime']);

If you are using the “ga.js” GATC, copy this line:

pageTracker._trackPageLoadTime();

Now that you have copied the correct site speed tracking line of JavaScript, paste it directly and immediately after the call to _trackPageview (this command appears in both GATC versions). I placed that instruction in bold because you want to make sure that you install this correctly (as with any JavaScript snippets).

Your “async” GATC should look like this after installation:

<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXXX-X']);
_gaq.push(['_trackPageview']);
_gaq.push(['_trackPageLoadTime']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript';
ga.async = true; ga.src = ('https:' == document.location.protocol
? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga, s);
})();
</script>

Your “ga.js” GATC should look like this after installation:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol)
? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost +
"google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-XXXXXXX-X");
pageTracker._trackPageview();
pageTracker._trackPageLoadTime();
</script>

Note: You don’t have to install site speed tracking on every page of your website – you can install it on select pages, or one page if you just want to test it out first. However, most developers use some type of include file or global template – so it maybe easier to apply this change on that include or template and update your GATC site-wide.

3. Things to know about site speed in Google Analytics

Now that you’re collecting site speed data, you will be able to see that data appear in the new version of Google Analytics (the data will not appear in the current / traditional version of Google Analytics). The report is in the Content section, and is the third link from the top.

Here is a list of things that you will need to know about the data that you will see:

– You will see two new metrics in the Site Speed report: Avg. Page Load Time and Page Load Sample.

Avg. Page Load Time is easy to understand: it’s the average amount of time (in seconds) that it takes for your pages to load.

Page Load Sample is the metric that you have to watch out for: this is the actual number of page views that Google Analytics is using at its sample to calculate the average page load time. You will definitely notice, as you collect site speed data, that Google Analytics isn’t using 100% of all page views to calculate your average page load time – this is perfectly normal.

Technical: using _trackPageLoadTime means that your website pages will send an extra “utm.gif” request to Google Analytics servers – which is separate from the standard request sent to track page views, and which is also perfectly normal.

– Visitors using older browsers that don’t support HTML5 or visitors using older browsers without the Google toolbar installed will not be able to be tracked for the site speed report (this is a small fraction of your visitors).

Have fun, glean lots of insights, and start optimizing slow-loading pages to be fast-loading pages! Also, leave us a comment to tell us how you will use Site Speed, or any tips that you would like to share.

© 2018 MoreVisibility. All rights reserved