Converting To Asynchronous Code
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.
GARE: Default Applied Advanced Segments
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.
State Popularity: the latest addition to the GARE
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.
Our 8 Most Popular Analytics Posts of 2009
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.
Get More from the Navigation Summary and Pivot Tables
Back in August, a tip was released on the Official Google Analytics Blog that allows you to export more than 500 rows from a report. In the post, this technique was used to export more than 500 rows worth of keyword data. Here we often use this technique to export more than 500 rows worth of pages from the Top Content report.
What you may not realize is that you can also use this trick to export more than 10 previous and next pages from the Navigation Summary report. As you may recall, the navigation summary report looks something like this:
In some case, 10 previous and next pages may be just what you need. But what if you want more?
First, look up at the address bar. For Google Analytics reports, you will often see some anchor text at the end of the URL. For example, this URL:
https://www.google.com/analytics/reporting/content_detail_navigation?id=3125976&pdr=20091031-20091130&cmp=average&d1=%2Findex.htm#lts=1259675463422
contains the following anchor text:
#lts=1259675463422
The first step is to remove this, including the pound symbol (#) from the URL. Next, add the following to the end of the URL:
&limit=50000
You cannot export more than 50,000 rows, so it's usually a good idea just to set the limit to this to get as many rows as possible. If you only want the first 1000, you can always set limit=1000 instead.
After adding this to the URL, hit enter and wait for the page to reload. Note that the page will not look any different than before. Adding limit=50000 only affects what you get in the export, not what you see in the interface. Also, only the CSV and TSV exports are affected. You can't get a PDF or XML with more than 10 previous and next pages. You can't even use the CSV for Excel export. But plain, old CSV and TSV work just fine.
There's not much more to say about this, so we'll move on to the next technique.
Pivot tables in Google Analytics are pretty neat. They allow you to see a two dimensional view of your data for a given metric or two. One way we might want to use pivot tables would be to see the number of visits made for each of our keywords, grouped by the hour of day:
What's this? You can't pivot by the hour of day? Download GARE and then come back quick!
So as you'll notice, you can only see the first 5 hours. And by first 5 hours I mean the 5 hours that had the highest number of visits. You can also cycle through the rest of the hours in chunks of 5.
Or you can add this parameter to the URL in the address bar:
&tcols=50000
You should remember to remove the anchor text and hit enter when you're done like before. Unfortunately, the report will now revert to a previously unpivoted state. You'll need to get back to the report you were looking at previously, but once you're there, you should see as many columns as are available. In this case, there should be 24 columns (though you may have less if you have hours without visits):
Note, if try to filter the report, you'll lose the extra pivot columns and revert back to only 5. There is a way to get around this. For example, let's say you filtered by "cheese" to only show keywords containing cheese. instead of just adding &tcols=5, add the following:
&tcols=50000&q=cheese&tpivk=hour
This will result in a pre-filtered report. You can then select pivot as before and see as many pivot columns as you like for keywords containing cheese. Note that we also added &tpivk=hour to pivot by hour of the day. That's because as soon as you change what you're pivoting by, you'll lose the filter. So there's quite a bit more involved if you need a filtered report, but it's still doable.
Now the only problem remaining is that there's no good way to sort by hour. At least not from the interface. You can export to CSV and do a vertical sort on the columns to get everything in order by hour. And if you're needing more than 500 rows worth of keywords containing cheese, pivoted by hour, you can also add &limit=50000:
&tcols=50000&q=cheese&tpivk=hour&limit=50000
If you were able to make good use of one of these tips, let me know! I'd also like to hear any suggestions for improvement or other things you might like to be able to do with the Google Analytics Interface, but aren't sure if it can be done. Maybe you'd like to see this made into a Greasemonkey script or add-on? Let me know!
Need Your Own Google Analytics Greasemonkey Script?
I write most of my Greasemonkey scripts with the idea that they will be useful to as many Google Analytics admins and users as possible.
But what if you need a script that's very specific to your business needs? Or maybe you've heard about the Google Analytics API and you'd like to use it to tie your Google Analytics report data with data from your back end. You might even just need some custom modifications to your Google Analytics Tracking Code and general setup to get that one bit of data that can make or break your business.
At ROI Revolution, we offer support plans that can be used for nearly any type of Google Analytics project you can think up. You can also use your support time to have us help you effectively configure optimal tracking for your business goals, get a second opinion on that those thorny configuration issues, or just to audit your Google Analytics account setup and make sure everything's working just as it should.
And if you just want your own Greasemonkey script, we can make that happen too.
Learn more about our Google Analytics technical support offerings.
Universal Conversion Code For Google Website Optimizer
We've been using a piece of code for a while that makes it easier to set up multiple Google Website Optimizer experiments. These experiments could be one right after the other, or even several experiments running simultaneously. The only requirement is that you should have a single conversion point for all of your Google Website Optimizer experiments. You may be able to adapt this code to situations with multiple conversion points, but that's likely to get rather complicated. So why use this code? Oftentimes your conversion point is a page that you're not really wanting to edit a lot, or may even be able to edit a lot. Instead of having to update your conversion page every time you set up a new experiment, you just add this code to your conversion page once and forget about it. It will register a conversion for all current and future experiments, and will even accommodate visitors who may be part of more than one experiment. So here's the code:
A few things to keep in mind:
- If you have your own functionally equivalent readCookie function, you can use that instead.
- This code will probably work best if it comes after your Google Analytics Tracking Code.
- If you have any kinds of modifications to your Google Analytics Tracking Code, you'll need to make those same modifications to your Google Website Optimizer code. See Shawn's post on this.
- This code is meant to replace the Google Website Optimizer conversion script that's provided with your instructions.
