Mixed Type Custom Variables in Google Analytics

Posted by Jeremy Aube on June 28, 2011 · Leave a Comment

It's a mix tape! Google Analytics features 3 types of custom variables: page-level, session-level, and visitor-level. The official Google Code documentation on custom variables is pretty explicit about the fact that it's best not to mix types:

"Generally it is not recommended to mix the same custom variable slot with different types as it can lead to strange metric calculations."

What isn't exactly clear is what happens if you do decide to mix types. Google Code provides two cases, but surely there are additional cases. To this end, I decided to test 9 total cases:

Case 1: Page to Page
Case 2: Page to Session
Case 3: Page to Visitor
Case 4: Session to Page
Case 5: Session to Session
Case 6: Session to Visitor
Case 7: Visitor to Page
Case 8: Visitor to Session
Case 9: Visitor to Visitor

Granted, three of these cases are not mixed type, but I decided to include those cases as well since the behavior for those cases should be well defined and good benchmarks for the other cases.

It would also be good to know exactly how Google Analytics attributes conversions in these types of situations. To that end, I set up a test with 5 different pages:

Page 1: Standard Google Analytics Tracking Code
Page 2: Set first type of custom variables
Page 3: Standard Google Analytics Tracking Code
Page 4: Set second type of custom variables
Page 5: Standard Google Analytics Tracking Code

In Google Analytics, I set up 5 different goals, one for each of the above pages. The idea is to see whether or not each custom variable gets credit for a conversion on a previous page, the current page, or any successive page.

I also included a second visit, with two additional non-goal pageviews just to confirm behavior for visitor-level custom variables.

Normally you're restricted to using 5 custom variables, but it is possible to get more than this. This allowed me to run a single test with 9 custom variables at once, which looked something like the following on Page 2:

On page 4, I changed all the names and values from _1 to _2 and made appropriate changes to the scope of each variable (3 for page-level, 2 for session-level, 1 for visitor-level).

There are a couple interesting things to note if you ever decide to run a test like this. First, if you run your test too soon after creating a new Google Analytics profile, it's possible that the data from that test will never show up in your reports. So it may be a good idea to wait an hour or so after creating the profile before running the test to make sure that you'll see any results.

Second, certain types of information take longer than others to show up in your profiles. While you can segment by custom variable keys and values pretty much as soon as the data shows up in your reports (in well under an hour in some cases), the dedicated Custom Variables (in the old version of Google Analytics) report actually takes as many as 48 hours before any data starts showing up in your reports. So this is something to be aware of if it looks like things are missing.

The result? Take a look:

Just to be clear, when the custom variable appears with an _1, it means that the first custom variable set was reported. When the custom variable appears with an _2, then the second custom variable set was reported. For example, the entry for session_page_1 means that the session-level custom variable was reported, while the entry for session_visitor_2 means that the visitor-level custom variable was reported.

Based on the data, we can conclude the following:

1. If a visit only includes page-level custom variables, then each custom variable set will receive attribution for the page it was set on, including goal attribution if the goal was set for that page.

2. If a visit contains either a session-level or visitor-level custom variable, then the last of these set will be the only one that's reported. Furthermore, that same custom variable will be the one that receives credit for any and all goal conversions during the visit, regardless of whether those goal conversion appeared before, at the same, or after the custom variable was set.

3. A corollary to #2 is that for a visit that contains a page-level custom variable and either a session-level or visitor-level custom variable, only the session-level or visitor-level custom variable is reported.

4. Based on the custom variables that received more than one visit, a visitor-level custom variable only persists if it was the last custom variable set. For example, while the entry for visitor_page_1 indicates that the visitor-level custom variable received credit for the visit, because the page-level custom variable was set after visitor-level custom variable, the visitor-level custom variable was not reported on the subsequent visit, as indicated by the fact that there was only 1 visit for this custom variable. If you watch the __utmv cookie, you'll see that the data for the visitor-level custom variable is actually removed when a page-level or session-level custom variable is set for the same slot.

The results of this test also prompted a follow-up test for an edge-case:

Case 10: Visitor-level on the first visit, page-level on the very first page of the second visit.

It turns out that the visitor-level custom variable is reported on the first visit, as expected, but the page-level custom variable is reported on the second visit.

Based on these results, it looks like two cases is sufficient to account for all mixed type situations, but it might help if the first case provided in official Google Code documentation more clearly show-cased these rules.

For the first case, instead of the following scenario:

The following would more clearly illustrate the precedence property:

The fact that the visitor-level custom variable set on page 2 would be the one reported more clearly indicate the way the precedence works. There would also be an opportunity to mention the fact that because the page-level custom variable occurred after the visitor-level custom variable, that the visitor-level custom variable would not be reported on any subsequent visits.

Feel free to leave any questions or comments about custom variables, especially if you can think of additional scenarios that are not covered by the official Google Code documentation or this post.

This post is brought to you by ROI Revolution: A Data Driven Google AdWords Qualified Company Delivering Profitable PPC Results: http://www.roirevolution.com/blog/

Handling Email Referrals in Google Analytics

Posted by Jeremy Aube on January 24, 2011 · Leave a Comment

If you've spent any time looking through your traffic sources in Google Analytics, particularly your referral sources, you may have noticed a lot of your traffic coming various mail sources:

Clearly it's not terribly useful to see your traffic broken out this way. At the very least, you would want to consolidate all of those mail.yahoo.com sources.

But if you think about it, it probably doesn't matter a whole lot which email service provider a visitor happened to be using when they clicked to your site. Perhaps it'd be better if we just consolidate all of those email sources into one entry. Not only would this significantly clean up reports, but it would also allow you to see the overall impact of traffic coming from email to your site.

The easiest way to handle this is by using filters:

While this is called a custom advanced filter, it's fairly straightforward. If you noticed in the first screenshot, all of traffic coming from email had "mail" somewhere in the source and "referral" as the medium. So this filter takes all of that traffic and changes the source of that traffic to webmail.

Also note that we set "Field B Required" to "Yes" and "Override Output Field" to "Yes". Both of these settings are necessary in order for this filter to work. The first setting ensures that we only change data for visits that fit the requirement we set in Field B, while the second one ensures that all visits that meet the filter requirements will have their source overridden with "webmail".

Once you've applied this filter to your reports, your email visits going forward will be consolidated into a single entry:

webmail / referral

Now if you tend to look at your traffic sources by medium, you'll notice that even after this filter, webmail traffic is still included with the rest of your referral traffic:

If you're OK with this, that's fine, but it is possible to separate your email traffic out by adding a second filter in addition to the first filter:

This is similar to our previous filter, but here we specify that we want to filter on visits with a source of "webmail" and change the medium of those visits to "webmail". Filters build on each other, so it's important that this filter come after the previous filter, otherwise it won't find any visits with "webmail" as the source.

After you make this change, your report on mediums should look more like the following:

This makes it much easier to differentiate between true site referrals and traffic that's coming from email.

Here are a couple final considerations:

1. It's possible to use advanced filters to break out webmail traffic by source. That is, you could have yahoo / webmail, aol / webmail, etc. The filters for this are much more complicated, however, and you may have trouble finding a good reason for knowing that an email visit came from aol instead of yahoo. But if you decide you need help with this we can help you via one of our Google Analytics technical support plans.

2. Getting a lot of webmail traffic may also be a sign that you aren't properly tagging your emails. If these are emails that you are sending out, especially from some type of autoresponder, then you should consider tagging these in some way. Click here to find out how we usually tag these emails.

As always, feel free to ask questions in the comments about this topic or let us know if you found this technique useful and/or how you used it.

This post is brought to you by ROI Revolution: A Data Driven Google AdWords Qualified Company Delivering Profitable PPC Results: http://www.roirevolution.com/blog/

Handling Email Referrals in Google Analytics

Posted by Jeremy Aube on January 24, 2011 · Leave a Comment

If you've spent any time looking through your traffic sources in Google Analytics, particularly your referral sources, you may have noticed a lot of your traffic coming various mail sources:

Clearly it's not terribly useful to see your traffic broken out this way. At the very least, you would want to consolidate all of those mail.yahoo.com sources.

The easiest way to handle this is by using filters:

Once you've applied this filter to your reports, your email visits going forward will be consolidated into a single entry:

webmail / referral

Now if you tend to look at your traffic sources by medium, you'll notice that even after this filter, webmail traffic is still included with the rest of your referral traffic:

If you're OK with this, that's fine, but it is possible to separate your email traffic out by adding a second filter in addition to the first filter:

After you make this change, your report on mediums should look more like the following:

This makes it much easier to differentiate between true site referrals and traffic that's coming from email.

Here are a couple final considerations:

As always, feel free to ask questions in the comments about this topic or let us know if you found this technique useful and/or how you used it.

This post is brought to you by ROI Revolution: A Data Driven Google AdWords Qualified Company Delivering Profitable PPC Results: http://www.roirevolution.com/blog/

Google Analytics Subdomain Tracking

Posted by Jeremy Aube on January 5, 2011 · Leave a Comment

If you do a quick search on "Google Analytics Subdomain Tracking", you may have noticed that many of the top results are either woefully out of date or rather confusing. The purpose of this post is to provide my recommendations for Google Analytics subdomain tracking as of the current version of the asynchronous Google Analytics Tracking Code.

Currently there's no specific article on Google Code dedicated to Google Analytics subdomain tracking. The closest is this, which recommends the following:

//Tracking code customizations only
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-12345-1']);
_gaq.push(['_setDomainName', '.example-petstore.com']);
_gaq.push(['_setAllowHash', false]);
_gaq.push(['_trackPageview']);

I propose that instead, for the vast majority of sites with subdomains, you should use the following:

//Tracking code customizations only
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-12345-1']);
_gaq.push(['_setDomainName', 'example-petstore.com']);
_gaq.push(['_addIgnoredRef', 'example-petstore.com']);
_gaq.push(['_trackPageview']);

So what's wrong with the code recommended on Google Code? It turns out there are three issues with the code that cause unnecessary problems:

1. Turn off hashing is bad.

Turning off the hash, either by ['_setAllowHash', false] or ['_setDomainName', 'none'], is necessary for cross-domain tracking to work correctly with Google Analytics. It's an unfortunate necessity, however, because domain hashing is actually quite useful.

By default, a script cannot identify the domain of a cookie; this information isn't available unless it's part of the cookie name or value itself. Including the hash provides that information so that the Google Analytics Code can read the correct set of cookies in situations where there might be more than one set.

Turning off the hash mean the Google Analytics Tracking Code has no way to tell which set of cookies is the right set. Most of the time there is only one set of cookies, so it's not that big of a deal.

But if you were previously using Google Analytics without subdomain tracking, then you may end up with two sets of cookies for return visitors: one set created by your old code, and one created by your new code. This happens most often on subdomains, but could also happen on your main domain if you use ['_setDomainName', 'none'] instead of ['_setAllowHash', false].

It's also possible that instead of creating two sets of cookies, your new Google Analytics Tracking Code will destroy the cookies from your old Google Analytics Tracking Code because the hash codes don't match. This would typically happen on your main domain rather than on a subdomain.

Eduardo Cereto has a post that looks into this issue in more detail and provides another use case where _setAllowHash causes issues. The bottom line here is that you need _setAllowHash to track across domains, but if you're only doing subdomain tracking, it's unnecessary and may cause problems.

2. The leading period causes cookie resets.

Google Code offers the following explanation for using the leading period when using _setDomainName:

"...if you want tracking across lower-level sub-domains:

* dogs.petstore.example.com and
* cats.petstore.example.com,

a leading period is required."

If your site does use lower level subdomains, then you definitely need to use a leading period in order for subdomain tracking to work. If your site does not use lower level subdomain, however, then you're actually better off not using a leading period.

The reason goes back to the hash again. The hash code that the Google Analytics Tracking Code generates when you use the leading period is different than the hash code generated when you don't use the leading period. But the hash code generated when you don't do any subdomain tracking on your main site is actually the same as the hash code generated when you use subdomain tracking without the leading period.

What this means is that if you weren't doing subdomain tracking previously, using the leading period will cause your new Google Analytics Tracking Code to destroy your old cookies because the hash codes don't match. This is similar to what happens when you turn hashing off.

Simply not including the leading period, if you don't have to, means you'll have less cookie reset, which will ease the transition to subdomain tracking.

3. Subdomain tracking without _addIgnoredRef causes self-referrals.

If your site has no subdomains the Google Analytics Tracking Code is able to detect when a visitor's session has expired between pageviews and avoid overwriting their existing referral information with a self-referral or internal-referral from your own site.

That safe guard is removed, however, when you have subdomains, even if your code has the standard subdomain tracking code. This can result in a rather high percentage of self referrals, even though it seems like you've done everything right.

The solution is to use _addIgnoredRef, but how to use it is often misunderstood. The Google Code recommendation is to use something like this:

_gaq.push(['_addIgnoredRef', 'www.sister-site.com']);

I took a very close look at the ga.js code base and observed that something like this won't actually work. The reason is because the Google Analytics Tracking Code considers www.sister-site.com to be the same as sister-site.com, so adding www.sister-site.com as an ignored referral doesn't accomplish much. Using a leading period here also fails. But this works just fine:

_gaq.push(['_addIgnoredRef', 'sister-site.com']);

and in fact, so does this:

_gaq.push(['_addIgnoredRef', 'sister-site']);

The Google Analytics Tracking Code checks each ignored referral string you add and uses the indexOf method to determine whether or not that string is contained within the referring domain. If any of those checks return true, then the referral is ignored. Since the root level domain without the leading period will be contained in any of your subdomains, then passing that to _addIgnoredRef works just fine. This also eliminates the need to add a separate _addIgnoredRef statement for each subdomain.

You may still get self-referrals with _addIgnoredRef, however, though not any more than you would without subdomains. The reason is that _addIgnoredRef only works when the cookies contain existing referral information. If a new visitor comes to your site via a page without Google Analytics Tracking Code, then navigates to a page with Google Analytics Tracking Code, that should result in a self-referral, regardless of whether or not they crossed subdomains.

These types of self-referrals, however, can be avoided by making sure to tag any page of your site. Then, if there are any pages that have this issue, you can dig into your Google Analytics report data and determine exactly which pages are responsible for the issue. And, since you're using _addIgnoredRef, it will be easier to find these pages since you won't have to deal with the noise of self-referrals that occur for no apparent reason.

The important key takeaway here is that _addIgnoredRef should be included standard every time you do subdomain tracking, not just if you notice self-referrals. This will help you avoid needless self-referrals in the first place.

Hopefully this clears up some of the confusion surrounding subdomain tracking with Google Analytics. Feel free to leave any comments or questions.

This post is brought to you by ROI Revolution: A Data Driven Google AdWords Qualified Company Delivering Profitable PPC Results: http://www.roirevolution.com/blog/

Google Analytics Subdomain Tracking

Posted by Jeremy Aube on January 5, 2011 · Leave a Comment

Currently there's no specific article on Google Code dedicated to Google Analytics subdomain tracking. The closest is this, which recommends the following:

I propose that instead, for the vast majority of sites with subdomains, you should use the following:

So what's wrong with the code recommended on Google Code? It turns out there are three issues with the code that cause unnecessary problems:

1. Turn off hashing is bad.

2. The leading period causes cookie resets.

Google Code offers the following explanation for using the leading period when using _setDomainName:

"...if you want tracking across lower-level sub-domains:

* dogs.petstore.example.com and
* cats.petstore.example.com,

a leading period is required."

Simply not including the leading period, if you don't have to, means you'll have less cookie reset, which will ease the transition to subdomain tracking.

3. Subdomain tracking without _addIgnoredRef causes self-referrals.

The solution is to use _addIgnoredRef, but how to use it is often misunderstood. The Google Code recommendation is to use something like this:

_gaq.push(['_addIgnoredRef', 'www.sister-site.com']);

_gaq.push(['_addIgnoredRef', 'sister-site.com']);

and in fact, so does this:

_gaq.push(['_addIgnoredRef', 'sister-site']);

Hopefully this clears up some of the confusion surrounding subdomain tracking with Google Analytics. Feel free to leave any comments or questions.

This post is brought to you by ROI Revolution: A Data Driven Google AdWords Qualified Company Delivering Profitable PPC Results: http://www.roirevolution.com/blog/

GARE: Updated Google Analytics Dimensions Drop-down

Posted by Jeremy Aube on August 9, 2010 · Leave a Comment

If you've been following GARE since the beginning, you know that the very first thing GARE ever did was add additional dimensions to the segment (now dimension) drop-down and make these available for nearly every report. As time moved on, more and more segments were added, and the list began to get rather long and unwieldy.

Well, a few weeks back, the dimensions drop-down in Google Analytics underwent a fairly major overhaul. If you haven't seen it yet, it looks something like this:

Clicking the above image will display a larger, more readable image.

I'd like to point out several excellent features in the new drop-down:

1. Categories:

Clicking on any of the categories will show you a column of all the available dimensions just for that category. This new level of organization also makes the dimension drop-down more tight and compact.

2. Descriptions:

This saves you from having to click a dimension and guess what it is based on the entries that show up. Segmenting is now much friendlier.

3. Searching:

Type a few letters in the dimension you want and you'll see only the dimensions that match those letters. Pretty slick.

Needless to say, when all of these great usability enhancements were added to the dimension drop-down, it broke GARE's additions to the list. Because the changes were so significant, it ended up requiring a complete rewrite of the dimension code.

Now GARE is even better! Take a look:

No more ridiculously long list of dimensions! Now, not only does the modified list actually fit on the page, but it integrates fully into the new features of the dimension drop-down:

Every added dimension is placed in appropriate categories. If there was no appropriate category, I created a new one.
Nearly all of the dimensions also include descriptions automatically; I didn't have to write a single description.
When you search for a dimension, the added dimensions are included if they match your search.

As you can see, now is a great time to get the latest version of GARE. Here's how you do it:

I'd like to thank Olivier at Resoneo, who suggested making additional AdWords dimensions available outside of the AdWords reports, and everyone else who expressed a wish to see GARE fixed. I also want to officially welcome any comments regarding broken GARE features, new features you'd like to see in GARE, or anything else related to GARE or the newly-enhanced Google Analytics dimension drop-down.

This post is brought to you by ROI Revolution: A Data Driven Google AdWords Qualified Company Delivering Profitable PPC Results: http://www.roirevolution.com/blog/

Converting To Asynchronous Code

Posted by Jeremy Aube on June 30, 2010 · Leave a Comment

A sinking bowl: fill it with water and use it to track time

There's a pretty strong push now for everyone to move to the new Asynchronous Google Analytics Tracking Code. It's the only code that's available from the interface now, and nearly all of the documentation includes examples of this as the primary code to be used. Converting your code to the new async code might seem like it's just a hassle, but there are benefit to using the new code. Because the code loads asynchronously, there's no longer any danger that it will interfere with the loading of the rest of your page. This means that the code can now be placed up in the header of your pages rather than right before the closing </body> tag. The result is that you'll be able to track a greater percentage of your visitors than your were previously, which will improve the accuracy of your reports in Google Analytics. Now if your setup isn't too complex, converting won't be too big of an issue. Your old code might look something like this:

Notice that the only modification on this code from the standard code is the line for subdomain tracking. The approach to converting something like this to the new asynchronous code is pretty standard:

Google has provided several migration examples if you need more information. But what if your code is a bit more complicated? Perhaps you've added initial referrer tracking to your Google Analytics Tracking Code:

The trouble with this type of modification is that it includes a bit of logic in addition to the standard tracking method calls. Something like this certainly looks possible:

This will work just fine for this example. But your code most likely looks very different and may have even more modifications. The benefits of the asynchronous code certainly sound nice, but do you really have the time and resources to change the code, test it, and then figure out where you missed a bracket or comma? Fortunately, there's a fairly straightforward way to convert just about any traditional Google Analytics Tracking Code snippet to the asynchronous code:

I personally like this style a lot for several reasons. It can turn the conversion process from a 1 to 2 hour project to a 10 to 20 minute project. There are also far fewer chances to make mistakes. Rather than having to change every single line, you can follow a few simple steps: 1. Start with the following code:

2. Copy everything between "try {" and "} catch(err) {}" from your old code and put it where it says "// Put your code here." If your code is old enough that it doesn't have a try...catch block, just copy everything between the the last opening tag of your Google Analytics Tracking Code. 3. Replace "_getTracker" with "_createTracker". If you have multiple tracking objects, in addition to pageTracker, like a secondTracker, then you'll need to change the _getTracker lines for these objects a bit more. Something like this should work: secondTracker = _gat._createTracker("UA-XXXXXXX-Y", "secondTracker"); The "secondTracker" in quotes could be anything at all, but using "secondTracker" might make it easier if you have to reference this later on. If you have additional code, such as ecommerce code, you can convert these according to the migration examples. You can also follow the following steps: 1. Start with the following code:

2. Copy your additional code, minus any script tags, and paste it where it says "// Put your code here." 3. If the code used pageTracker as an object, then you're done. If the code uses secondTracker instead, then you'll need to change the "var pageTracker._getTrackerByName();" line to the following: var secondTracker = _gat._getTrackerByName("secondTracker"); You can also just add this line if your additional code uses both pageTracker and secondTracker. One thing that's worth noting in the all of the above async examples is that no where is pageTracker or any other tracking object declared as a global variable. This means that if you have any onclick events that use pageTracker, you'll need to update them as well. While this might seem like another pain to go through, it's actually very necessary to ensure that ga.js has loaded, the tracking object has been created, and all methods already applied to it have been run, in order, before the onclick event can run. The benefit is that you no longer have to use try...catch blocks, checks for object existence, and recurring setTimeout statements to ensure that everything works properly; it's all taken care of for you in a much more robust way. So let's say you had an onclick event like this: onclick="pageTracker._trackEvent('Videos', 'Play', 'Marketing Video', 10);" You would have two options for converting this to async: 1. onclick="_gaq.push(['_trackEvent', 'Videos', 'Play', 'Marketing Video', 10]);" 2. onclick="_gaq.push(function () { var pageTracker = _gat._getTrackerByName(); pageTracker._trackEvent('Videos', 'Play', 'Marketing Video', 10); });" Which option should you go with? Option #1 is usually best for simple onclick events like the one above. For longer, more complex onclick events, especially if you're setting them dynamically, option #2 makes a lot of sense since you can simply wrap all of your statements and simplify your conversion process. As a final note, if you need to use secondTracker or some other tracking object, this can be done option #1 style like this: onclick="_gaq.push(['secondTracker._trackEvent', 'Videos', 'Play', 'Marketing Video', 10]);" The name preceding _trackEvent in the must match the name you passed to _gat._getTrackerByName. For example, suppose your converted Google Analytics Tracking Code had the following statement: secondTracker = _gat._createTracker("UA-XXXXXXX-Y", "tracker2"); The correct way to reference this in your option #1 style onclick event would be the following: onclick="_gaq.push(['tracker2._trackEvent', 'Videos', 'Play', 'Marketing Video', 10]);" The reason you use tracker2 instead of secondTracker is that tracker2 is the name that the tracking object was registered under, while secondTracker is simply a local reference to the tracker2 tracking object. You can avoid this confusion by simply using the same name for both as shown earlier. Also note that we didn't register a name for our local pageTracker objects, so these use the default tracking object, which is referenced without a name in option #1 style statements. Feel free to leave comments if you have additional situations that steps don't seem to address. Also, while the above steps may be enough to fully convert your code, you may still want to consider purchasing support to do this, especially if you have a more complicated setup.

This post is brought to you by ROI Revolution: A Data Driven Google AdWords Qualified Company Delivering Profitable PPC Results: http://www.roirevolution.com/blog/

GARE: Default Applied Advanced Segments

Posted by Jeremy Aube on April 6, 2010 · Leave a Comment

I was thinking the other day about some of the problems with Advanced Segments in Google Analytics. Don't get me wrong, I like the feature quite a bit and use it all the time. The main problem I have is that advanced segments require an extra step.

What I mean is that when you view a profile's report, if you want to apply an Advanced Segment, you have to expand the drop down or click the link in the left nav, click a few more things, and then finally it's applied.

That's OK if you need that advanced segment infrequently. But what if you have an Advanced Segment you use constantly, all the time, maybe even every time you view a particular profile? Then this process becomes a bit of a hassle.

Enter Default Applied Advanced Segments.

This new feature gives you the ability to set a particular advanced segment or segments as the default segment that will be applied to the profile every time you go to view that profile. Once you're viewing the profile, you would still have the ability to remove that advanced segment or apply a different advanced segment altogether as usual. What this feature does that's nice is offer a "recommended view" of the profile.

Currently, Default Applied Advanced Segments are both login based and browser based. Custom Advanced Segments are already login based, so that's no big deal. But if you access Google Analytics from multiple machines on a frequent basis, you might be frustrated if you have to set up your Default Applied Advanced Segments on each machine.

Eventually I would like to overcome this limitation, but this is a bit beyond what I've done so far, so it will likely be a while before I can come out with the update. I would also like to create a version of this that is managed at the admin level. That way, any admin will be able to set up which advanced segments are applied to the profile by default, and can change this for other users.

You can get in on the action by:

Of course, if you already have Firefox or Greasemonkey, you can bypass the appropriate step(s).

I would also like to get some feedback as to how useful this feature is so far. This blog post is intentionally devoid of details on how to use this feature. I'm hoping that this feature will be both obvious and discoverable. So let me know what works, what doesn't, or what else you might like to see, and I'll see what I can do.

This post is brought to you by ROI Revolution: A Data Driven Google AdWords Qualified Company Delivering Profitable PPC Results: http://www.roirevolution.com/blog/

State Popularity: the latest addition to the GARE

Posted by Jeremy Aube on February 22, 2010 · Leave a Comment

We have another new addition to the Google Analytics Report Enhancer, thanks to Ophir Prusak of Google Analytics Authorized Consulting firm POP. This metric helps to interpret the significance of visit counts at the US State level. You can hear the rest of the story by reading Ophir's excellent post on the metric.

Now that State Popularity has joined the GARE family, it's a great time to download the latest version of the Report Enhancer. Here are the steps:

In addition to the new metric, I've also been able to improve the way additional metrics are added to tables, including better sorting and handling of advanced segments and compare to past.

So how is State Popularity calculated anyway? I'm glad you asked!

First, the number of visits for each state is divided by the population of that state, according to the latest estimates. That's the easy part. What you're left with are some very small numbers that don't really give a good idea of significance.

The obvious way out of this is to multiple each ratio by the same number to make them more human friendly. I decided that rather than picking a static number, like 1,000 or 100,000, I would multiply each ratio by a number so that the total of all adjusted ratios would be equal to the number of visits. To do this, I divided each ratio by the sum of all ratios, then multiplied by the total number of visits.

The main benefit to multiplying the ratios by this number is that you can tell whether you are getting a high number of visits even from a smaller state by comparing the State Popularity number to the number of visits.

For example, if the State Popularity is higher than the number of visits for a particular state, then you know that you're getting higher than average visits from that state based on its population. If it's lower, then the number of visits from that state is less significant.

The problem with this method, from a Google Analytics standpoint, is that it's difficult to calculate the sum of all the ratios unless they're visible, that is, at least 50 rows are showing (though usually more because of D.C. and (not set)). To handle this, I had to make my own requests for the data that included all of the rows and pre-calculate the totals. The map overlay also has its own peculiarities that make it difficult to make table additions persistent.

What makes this significant is that it in the past, I could only create new metrics based on metrics in a single table. But now, theoretically, I should be able to calculate metrics based on more than one table.

I'll probably be able to think of some good use of this technique before too long, but if someone else has an idea of what metric they might like to see, let me know! You never know, your new metric may be the next addition to the GARE.

This post is brought to you by ROI Revolution: A Data Driven Google AdWords Qualified Company Delivering Profitable PPC Results: http://www.roirevolution.com/blog/

Our 8 Most Popular Analytics Posts of 2009

Posted by Jeremy Aube on December 29, 2009 · Leave a Comment

The end of the year is a nice time to take a look back over all that was accomplished throughout the year. To that end, I'm going to give you a list of our top 8 Analytics Blog Posts of 2009. As we go through the list, I'll give you a short description of each post as well as any random thoughts I have about the post.

Enjoy the posts and have a Happy New Year!

#1. 6 Tools Every GA User Should Have

Shawn Purtell

Random Thoughts:

This was by far the most popular post of 2009. It did so well that I decided to steal its format in hope of boosting the popularity of this post. It now includes 7 tools instead of 6 for added tool enjoyment. Looking over this list, even though this post was written back in January of '09, most of these tools are still very useful enhancements of the Google Analytics Interface and have even been updated since the writing of the post. GANotes, on the other hand, has achieved what every Google Analytics Tool dreams of becoming one day: it is now a Google Analytics fully-fledged feature known as Annotations.

#2. Tracking Transactions back to Initial Referrer

Jeremy Aube

Random Thoughts:

What's up with that frog? Apparently the idea is that considering the size of that frog, this is probably the first time it's been touched by human hands, i.e. first touch. There's a lot of talk about first-touch attribution vs. last-touch attribution. This post explains a way to get both in Google Analytics.

#3. Five Google Analytics FAILS

Michael Harrison

Random Thoughts:

We've seen people do a lot of crazy Google Analytics setups. Unfortunately, many of these fails are all too common. This post is worth reading just for the laughs alone (well, OK, it's GA humor, but it's still pretty funny), but it also serves as a much needed warning sign. Most of these fails resulted in permanent damage of one sort or another to Google Analytics data.

#4 ga.js code for GWO

Jeremy Aube

Random Thoughts:

Yet another update to GARE. This particular update was nice because allowed you to get the appropriate modifications for subdomain and multiple domain tracking. I'm not sure if this particular GARE feature still works (Update 12/30/2009: just fixed this. It should work fine now.); Google updated the Google Website Optimizer Interface so that ga.js code is provided by default.

#5. 5 Advanced Segments for Ecommerce

Michael Harrison

Random Thoughts:

Another list post, this one dealing with using the fairly-new, enterprise-level feature, advanced segments, to uncover more than ever before about your ecommerce data. My particular favorite advanced segment is #2. It used to be very difficult to determine the influence of a landing page on your site, but advanced segments makes this easy (and maybe even fun!).

#6. 6 Tools to Troubleshoot GA

Shawn Purtell

Random:

For some reason, I'm reminded of a quote: "So far alls I've come up with is the effects of gasoline. {pauses a bit} On fire." There are a lot of things on fire in this post too. We use most of these tools every day. Personally, my life would be pretty much over if I didn't have FireBug.

#7. Stressing About Ecommerce Variables?

Caitlin Cook

Random Thoughts:

Yes, those ecommerce functions sure do ask a lot of you. Fortunately you don't have to give into their demands. This post tells you exactly which variables you need to make Google Analytics ecommerce tracking work for you.

#8. Viewing A/B Experiments in Google Analytics

Shawn Purtell

Random Thoughts:

Getting Google Website Optimizer data for multi-variate tests into Google Analytics takes a little bit of work. For A/B tests, this data is available by default in Google Analytics since each combination in your test is a separate page. This post tells you how to further unlock your A/B test data in Google Analytics using advanced segments. It also has a really nice screenshot of GARE in action.

This post is brought to you by ROI Revolution: A Data Driven Google AdWords Qualified Company Delivering Profitable PPC Results: http://www.roirevolution.com/blog/

Page 1 of 212 »

Mixed Type Custom Variables in Google Analytics

Handling Email Referrals in Google Analytics

Handling Email Referrals in Google Analytics

Google Analytics Subdomain Tracking

Google Analytics Subdomain Tracking

GARE: Updated Google Analytics Dimensions Drop-down

Converting To Asynchronous Code

GARE: Default Applied Advanced Segments

State Popularity: the latest addition to the GARE

Our 8 Most Popular Analytics Posts of 2009

#1. 6 Tools Every GA User Should Have

Shawn Purtell

Random Thoughts:

#2. Tracking Transactions back to Initial Referrer

Jeremy Aube

Random Thoughts:

#3. Five Google Analytics FAILS

Michael Harrison

Random Thoughts:

#4 ga.js code for GWO

Jeremy Aube

Random Thoughts:

#5. 5 Advanced Segments for Ecommerce

Michael Harrison

Random Thoughts:

#6. 6 Tools to Troubleshoot GA

Shawn Purtell

Random:

#7. Stressing About Ecommerce Variables?

Caitlin Cook

Random Thoughts:

#8. Viewing A/B Experiments in Google Analytics

Shawn Purtell

Random Thoughts:

AdWords Resources:

Recent Posts

Blog Archives