Archive for February, 2009
Posted on February 26, 2009 by John
Tracking to multiple accounts? What’s that?
When you create a GA account, you get an account number starting with “UA-” followed by a string of digits. When you put the GA Tracking Code on your pages you must specify what account you want it to send the data to by including this account number. If you want to send that data to multiple accounts you need to duplicate portions of the Tracking Code and include both account numbers:
<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-11111-1″);
pageTracker._trackPageview();
var otherTracker = _gat._getTracker(“UA-22222-1″);
otherTracker._trackPageview();
</script>
Above we see two lines duplicated with different UA numbers. The data for the page that includes this code will be sent first to the account UA-11111-1 and then to the account UA-22222-1.
But when you do this there is the possibility that you may not get what you think you’ll get.
Using this method, the same cookies are used for both keeping tracking of information sent to both accounts. This opens the door for some potential problems.
1. Non-Identical Code
Some things you can do with the GA code can cause it to write cookies in different formats. If this happens GA can get a little confused. Okay, a lot confused. Here’s an example that will cause you you problems:
<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-11111-1″);
pageTracker._setAllowHash(false);
pageTracker._setAllowLinker(true);
pageTracker._trackPageview();
var otherTracker = _gat._getTracker(“UA-22222-1″);
otherTracker._trackPageview();
</script>
In the above code, the first tracker includes the lines to allow for Cross-domain tracking in GA. This means that the first set of code will try to write cookies in one format, but the second set of code will try to use a different format.
Using Cross-domain tracking is fine, but you have to make sure that the code is the same for both trackers. If you do it in one, make sure you put the same lines into any additional trackers.
2. Different Pages
Another problem you can encounter is not having the Tracking Code on all the same pages. That is, some pages are tracked to both accounts, while others are only tracked to one account.
The problem here is, again, that the same cookies are being used. So, I view a page that is only tracked to Account A, and then view a page that is tracked to both Account A and Account B. The Account B code will see the cookies that were originally created by a page that had No Account B tracking code. The first pageview recorded to Account B will have referral information created on a different page. It will think this is the second pageview, etc.
So, make sure the same code is on all the same pages for consistent tracking.
3. User Defined Segments
The User Defined Segment value is stored in a cookie (__utmv). Since both sets of code are using the same cookies, once you set a User Defined Segment for one, you’ve set it for the other as well. You can’t have one set of User Defined Segments for the first set of code, and another set of User Defined Segments for the second set of code.
For example, you can’t use the first set to keep track of Member/Non-member and the second set to keep track of Male/Female because they will overwrite each other.
<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-11111-1″);
pageTracker._setVar(‘Member’);
pageTracker._trackPageview();
var otherTracker = _gat._getTracker(“UA-22222-1″);
otherTracker._setVar(‘Male’);
otherTracker._trackPageview();
</script>
In this example, because of the way that GA handles _setVar, when the visitor comes back for a second visit he will be classified as “Male” in both accounts.
These are some of the most common issues I’ve seen when troubleshooting these types of implementations. Hope this gives you some things to look out for, and if you have any questions, feel free to use the comments to ask.
John
View Comments (24 Responses) | Categories: Google Analytics
Posted on February 24, 2009 by Robbin
The Web Analytics Association will be having Board of Director elections soon, but nominations close this Friday, February 27. Your chance for fame, glory and fortune. Oops, maybe delete the fortune part, but definitely, your chance for fame and glory. Check out the nominations info on the site and get your name in the hat –
Robbin
View Comments (1 Response) | Categories: Industry News
Posted on February 19, 2009 by Robbin
Google Analytics, we all know, has a feature that you can opt into and benchmark your performance against similar sized websites in similar industries. But what do you do when that doesn’t quite meet your needs – for example, you have a fiduciary responsibility to benchmark specific websites against each other? And how do you do it if the sites are competitive (can’t see each other’s data)? There are both technical issues and analytic issues.
Here at LunaMetrics, we’ve succeeded with this by implementing a single set of GA tracking code across all sites, as well as a second set that is a unique account for each site. This creates both a roll-up and easy comparison. It also ensures that each of the sites in the benchmark has its own, private account not accessible to the other sites. There are situations in which the technical work gets complex; John Henson from Luna is going to blog about that topic next week.
The hardest part of creating a benchmark is getting the organization to agree on what the metrics should be, especially if the organization is benchmarking to show “how they are doing” (instead of benchmarking to answer specific questions). In the former case, the organization’s web managers usually need to see a trial benchmark to decide how well it meets their needs – so it tends to be an iterative process.
At this point – technical issues dealt with, benchmarked indicators agreed upon – the organization will often find that the indicators don’t quite make sense. For example, it’s not helpful to compare visits or unique visitors to (say) The New York Times vs. the Pittsburgh Post-Gazette, because one is so much larger than the other. In situations like these, trending is your friend – it still makes sense to see if visits to The New York Times increase or decrease over time at the same rate as those to the Pittsburgh Post-Gazette, by segment.
The skew that large sites bring to the benchmark can be remarkable, even when you are looking at rates rather than absolute metrics. For example, let’s say that you are comparing pageviews/visit among three sites. The first one has a million pageviews and 700K visits (1.43 pages/visit). The second has fifty pageviews and twenty-five visits (2 pages/visit). The third has 25 pageviews and three visits (8.33 pages/visit). But when we benchmark by adding all the pageviews and dividing by the sum of all the pageviews, the average will always be very close to 1.43 – i.e., very close to the one site that overwhelms the other sites in size. (And so the data are not very meaningful.) On the other hand, if we benchmark by computing the ratio of pageviews/visit for each site first, and then averaging the ratios across the three sites, the tiny sites with their higher metrics have a disproportionate pull on the average. A good answer might be to provide both benchmarks.
Finally, you have to be careful about using benchmarks with metrics that add up to 100%, unless you have a very clear understanding of what “good” means to the overall organization. Trends in metrics that add up to 100% are a zero-sum game – one metric can only go up if another one goes down. For example, let’s say that you consider benchmarking visits by medium. One site might bring in lots of visits organically and another, via direct. Unless the benchmarking organization has a clear mandate (e.g. “increase visits from search engines organically”), the acquisition patterns of the two sites mentioned here (organic vs. direct) are not illuminating. You will have learned that they are different, but not how one is doing vs. the other. (New visits vs repeat visits face the same issue.)
View Comments (No Responses) | Categories: Google Analytics, Web Analytics
Posted on February 10, 2009 by Robbin
I’ve had this conversation with a lot of customers and potential customers. The site owner has at least two problems: not very much traffic, and lousy conversion. “So which do you want to work on first?” I ask them.
On rare occasions, the very savvy customer will say, “Let’s work on the conversion first. After all, it doesn’t make sense to send lots of traffic to our site and just see that traffic bounce.” This is common “wisdom,” and lots of analysts pay lip service to this idea. Maybe more than that, maybe they really embrace it.
However, I love to be the contrarian, and would submit that it is smarter for the vast majority of sites to work on traffic first. Why? Because when it comes to conversion, split or multivariate testing are your best friends. You can do all the “conversion” work in the world, but at the end of the day, you need to prove which version works the best through testing. And if you don’t have enough traffic, you will sit and sit and sit with your test, waiting for statistical certainty. Or you will dumb down your test enough so that it runs in six weeks instead of six months, and then not learn enough.
(To those who haven’t done the six month thing: when your test has to run for six months to get statistical significance, you will fight battles all the time. Everyone wants to make changes to the page you are testing, from the content manager to the SEO firm to the PPC firm. And let’s not forget the calendar: you may need to show a different page in the fall than in the spring, based on what you sell. As soon as you change the page, the test is basically dead.)
But what about larger sites? They don’t need to work on traffic, do they? They already have traffic.
Well, maybe not so fast. Statistical significance of testing is based on having enough data in both a numerator and a denominator: The number on top of the ratio (conversions) and the one on the bottom (views of the test page.) So you might have a fairly large site with a miniscule conversion rate, and still not have enough traffic to get a significant test quickly. Ergo, you still need traffic.
Robbin
View Comments (17 Responses) | Categories: Conversion Science
Posted on February 4, 2009 by John
As you know, Google Analytics allows you to define a campaign with marketing parameters at the end of a URL linking to your site. You can set things such as the name of the campaign, the medium, the source, etc.
The _setAllowAnchor method [http://code.google.com/apis/analytics/docs/gaJSApi.html#_gat.GA_Tracker_._setAllowAnchor] in GA allows you indicate these parameters in the URL with a # symbol instead of the ? symbol that is normally used.
However, the documentation for this method is a little confusing, so I’d like to go over how to use it.
The JavaScript
To enable the use of the # symbol for your GA campaigns we need to add one line into the middle of your existing GATC. Everyone’s GATC may look a little different, but everyone should have the lines below.
var pageTracker._gat._getTracker(‘UA-xxxxxx-y’);
pageTracker._trackPageview();
Somewhere in between those two lines you need to add a line of JavaScript:
var pageTracker._gat._getTracker(‘UA-xxxxxx-y’);
pageTracker._setAllowAnchor(true);
pageTracker._trackPageview();
This change should happen on every page of your website.
The Campaign URLS
After making the above change to your GATC, you can still use the standard campaign tracking parameters. You do not need to change any of your existing campaigns. But you also get the option to use an alternate version of campaign tracking. In the alternate version, you are just replacing the ? with a #.
This standard method for campaign tracking uses a URL that looks like this:
http://www.lunametrics.com/index.html?utm_source=december&utm_medium=email&utm_campaign=monthlynewsletter
The alternate method for campaign tracking uses a URL that looks like this:
http://www.lunametrics.com/index.html#utm_source=december&utm_medium=email&
utm_campaign=monthlynewsletter
The Example in the GA Documentation looks like this (This doesn’t work):
http://www.lunametrics.com/index.html?utm_source=december#utm_medium=email#utm_campaign=monthlynewsletter
Four Examples in GA
Here is an example of 4 different variations and what you will see in Google Analytics as a result:
1. ?utm_campaign=1&utm_medium=1&utm_source=1
2. ?utm_campaign=2#utm_medium=2#utm_source=2
3. #utm_campaign=3&utm_medium=3&utm_source=3
4. #utm_campaign=4#utm_medium=4#utm_source=4
As you can see, when the # is used in place of the &, GA doesn’t seem to recognize it as a separator.
So there you have it. I hope it is fairly straight-forward.
UPDATE
Someone pointed out that I had overlooked a possible situation. What happens if your URL already contains a query parameter such as ?page=123, what then?
**If your original URL looks like this, then the # replaces the first ampersand.**
This URL:
http://lunametrics.com/?page=1234#utm_source=henson&utm_medium=john&utm_campaign=test
Will provide this result:
And remember, campaign tracking doesn’t have to be cam-painful.
(more…)
View Comments (24 Responses) | Categories: Conversion Science
Posted on February 2, 2009 by Jim
Using the hash mark (#) instead of the question mark (?)
Have you ever wanted to track the visits to your site from a specific link, but worried about the negative implications of using query parameters in the URL? (I know, it’s kept me up late at night too.) We recently talked with Mike Plummer, a Seattle-based web analyst at POP, about this topic and he gave us some ideas to chew on – thanks Mike!
Using tracking parameters in the URL is a great way to track visits from links on other sites, but it raises a couple of thorny issues: duplicate content and (possibly) devaluing the links to your site if they are perceived to be paid links. Let’s look at the first issue – duplicate content.
Duplicate Content (Duplicate Content)
Here’s a hypothetical example: Let’s say LunaMetrics is running a special promotion of giving away a lifetime supply of ice cream to all new clients. In fact, this (hypothetical) promotion is such a big hit, web analyst guru and all-around great guy Avinash Kaushik decides to blog about it and post links to our homepage.
Of course, being the analysts we are, we want to track the visits from those links, so we ask Avinash to add the following tracking parameters to the links:
http://www.lunametrics.com/?utm_source=avinash&utm_medium=blog&utm_campaign=icecream
Things are going great – we are able to segment the traffic to just the visits from those specific links, and see that visits from Avinash have an 87% conversion rate! In fact, readers of Avinash’s blog are so excited about our promotion (and they love ice cream so much) they all start bookmarking our homepage and linking to it on their own blogs and websites. The only problem is that they bookmark and link to the URL with the tracking parameters (who can blame them – they just copy and paste the address from the browser).
The problem is that the search engines view the URL with the tracking parameters as a different page than our homepage URL without the parameters. So the value of all the links to the URL with the parameters doesn’t count toward our homepage at all. (And we all know how important links are when it comes to ranking higher in the search results, right?)
What are we to do?
Anchors Away!
Instead of using a question mark (?) in the query parameter, set it off with the hash mark (#). Of course, you’ll want to modify your Google Analytics Tracking Code with pageTracker._setAllowAnchor(true); to track the parameters after the hash mark. Google’s documentation on this feature is a little confusing, so we’ll be covering the proper usage in a short follow-up post later in the week. (Update: As promised, here’s the follow-up post – “Campaign Tracking with _setAllowAnchor“)
The great thing about this method is that when Google sees a URL with a hash mark, it ignores everything after the hash. So…
www.lunametrics.com/#this
and
www.lunametrics.com/#that
and
www.lunametrics.com/
are all the same page in the eyes of Google. That means that when someone links to www.lunametrics.com/#utm_source=avinash&utm_medium=blog&utm_campaign=icecream it will be the same as linking to www.lunametrics.com as far as Google is concerned.
The Issue of Paid Links
Here’s what Google says about paid links:
Google and most other search engines use links to determine reputation. A site’s ranking in Google search results is partly based on analysis of those sites that link to it. Link-based analysis is an extremely useful way of measuring a site’s value, and has greatly improved the quality of web search. Both the quantity and, more importantly, the quality of links count towards this rating.
They go on to say that some SEOs and webmasters have participated in buying and selling links that pass PageRank in an effort to rank higher. That is in direct violation of their webmaster guidelines, and they have been getting more aggressive in detecting these paid links and devaluing them. (It’s only fair to include that Google isn’t against all paid links – as long as they are designated as being paid.)
In the last paragraph, they say “Google works hard to ensure that it fully discounts links intended to manipulate search engine results, such as excessive link exchanges and purchased links that pass PageRank.”
Let me put on my aluminum-foil hat for all you conspiracy theorists out there. There are some that believe that if Google sees campaign parameters in a URL that it’s a signal for a paid link. If that’s the case, then links to your site that include campaign parameters may not pass any PageRank to your page.
But there are certainly cases (like our ice cream promotion example) where we aren’t paying for the link, but want to be able to track it. Again, using the hash mark (#) instead of the question mark (?) should accomplish this.
There you have it. Now, who wants ice cream?
View Comments (15 Responses) | Categories: Conversion Science, Miscellaneous
Subscribe to this blog's feed
Follow us on Twitter
Become a fan on Facebook