A while back, ROI Revolution (a Google Website Optimizer Authorized Consultant) came up with a technique for importing GWO information into GA (Google Analytics). This way, you can see how different variations of a web page/site will affect the various numbers that GA measures.
The original technique relied on munging through the __utmx cookie that the control script sets. I improved upon this by describing a technique which uses some new functionality I incorporated into siteopt.js. Their most recent description of this technique is here.
I’ve been giving some thought to this technique and wanted to 1) Improve the technique a bit, and 2) Suggest an alternative which has some significant advantages.
First, an look at my script for the ROI technique. The script I suggested is (note, all these scripts assume that ga.js and the control script have already been included on the page):
<script type="text/javascript">
if (utmx('combination') != undefined) {
var l = document.location, s = l.search;
s = s + (s.length ? '&' : '?') + 'combination=' + utmx('combination');
var pageTracker = _gat._getTracker("UA-XXXXXX-Y");
pageTracker._trackPageview(l.pathname + s);
}
</script>
This suffers from two things. First, global variables are introduced into the namespace of the page and, second, there is no specification of which experiment is annotating the hits. So, consider the following, modified, script:
<script type="text/javascript">
(function(){try {
if (utmx('combination') != undefined) {
var l = document.location, s = l.search;
s = s + (s.length ? '&' : '?') + 'combination=' + utmx('combination');
s += '&experiment=MyExperiment';
var pageTracker = _gat._getTracker("UA-XXXXXX-Y");
pageTracker._trackPageview(l.pathname + s);
}
}catch(err){}})();
</script>
Here I’ve enclosed the script in an anonymous function and a block to catch exceptions (should ga.js fail to load), and also added a query param describing the experiment being tested to disambiguate one experiment from another.
With this technique, you can go into your content report in GA and see how many visitors assigned to the various experiment variations actually end up visiting pages on your site.
This technique requires you to modify the GA tracking script on each page of your site which you want to track against an experiment. If you’ve already instrumented your whole site with GA tags, it might be cumbersome to edit them all, especially when you’ll need to modify them again when you end and experiment, or start a new one.
Experimenting on the entire Site
The answer I’ve come up with to deal with these issues is to integrate GWO experiment information a different way. Instead of modifying each page URL with the experiment information, you can set the GA user variable with experiment information (assuming you are not already using the variable for other purposes). Consider the following script:
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-XXXXXX-Y");
pageTracker._setVar("MyExperiment-" + utmx('combination'));
} catch(err) {}
</script>
First note that this script does not call _trackPageView. Its job is not to track anything, but to set up the user variable to contain information about an experiment. This variable is stored in the __utmv cookie, and every subsequent call to _trackPageView in a tracking script will communicate the value of this cookie to Google servers and annotate the page view with the value in the cookie.
This script needs to placed in a particular place in your pages. First, it must only be located in GWO test pages which have already executed the control script. The script uses the function utmx, which is defined by siteopt.js, which is obtained through the control script. Next, this script needs to be executed before any calls to _trackPageView in any other GA tracking scripts. It also needs to be after the inclusion of ga.js.
I recommend that you place this script after the ga.js inclusion script and before the GA tracking script in the following manner:
<script type="text/javascript"><script type=”text/javascript”>
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "https://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
try {
var pageTracker = _gat._getTracker(“UA-XXXXXX-Y”);
pageTracker._setVar(“MyExperiment-” + utmx(‘combination’));
} catch(err) {}</script>
<script type=”text/javascript”>
try {
var pageTracker = _gat._getTracker(“UA-XXXXXX-Y”);
pageTracker._trackPageview();
} catch(err) {}</script>
This way, the variable gets set before the tracking script which will use the variable annotate this page visit. Furthermore any visits that this visitor makes in the future (for up to an absence of two years) will also be annotated.
You can see this in action here:
Special Consideration for A/B Experiments
The technique described above works for multi-variate experiments. That is, experiments which do not use redirection to present different pages to visitors. If you were to use this technique on GWO A/B experiment, the code which sets the user defined variable would sometimes not get executed because the original page would redirect to an alternate page, skip the setting on the original page for one which does not have the Control Script, and can’t use the “utmx” function.
Now, there are is a way to have the Control Script on A/B alternate pages. I’ll save that technique for another article. However, there is a way to get the above technique to work A/B (redirection) experiments. The idea is to set the user defined variable before the redirection on the original page takes place. To do this, consider the following A/B Control Script:
<script>
function utmx_section(){}function utmx(){}
(function(){var k='3923492669',d=document,l=d.location,c=d.cookie;function f(n){
if(c){var i=c.indexOf(n+'=');if(i>-1){var j=c.indexOf(';',i);return c.substring(i+n.
length+1,j<0?c.length:j)}}}var x=f('__utmx'),xx=f('__utmxx'),h=l.hash;
d.write('<sc'+'ript src="'+
'http'+(l.protocol=='https:'?'s://ssl':'://www')+'.google-analytics.com'
+'/siteopt.js?v=1&utmxkey='+k+'∓utmx='+(x?x:'')+'&utmxx='+(xx?xx:'')+'&utmxtime='
+new Date().valueOf()+(h?'&utmxhash='+escape(h.substr(1)):'')+
'" type="text/javascript" charset="utf-8"></sc'+'ript>')})();
</script>
<script>utmx("url",'A/B');</script>
Notice that this is really two scripts. The first script is that which, among other things, defines the “utmx” function. The second, using the “utmx” function, is the one responsible for performing the redirect to an alternative page, should it be required.
It is between these two scripts where you will need to include ga.js and set the user defined variable in order for this technique to work for A/B experiments. So in the A/B case, move that code from just before the tracking script to be between these scripts.
Experiment without GWO reports
When you normally set up a GWO experiment, you are asked to place test and goal page tracking scripts on your test page and goal page. This allows GWO to track when visitors hit your test and goal pages, and render a GWO report.
If you only plan to look at the GA reports for this experiment, you can forgo placing the GWO tracking scripts. Instead, you need only place the control script and user defined variable script in any pages which have experiment variations. In fact, you can place these scripts on pages which do not have any experiment variations. The effect of doing this is that visitors to these non-variation pages will have their experiment variations chosen for them before they encounter any test pages. This means that you will be able to track their activity before they encounter experiment variations.
This is useful in that, if you do this at every entry point to your site, all tracking events will be tagged with experiment information.
Report Segmentation
So, once you get all this set up, how do get experiment segmented reports? On each report, there is a Dimension dropdown:
This will show a report broken down by the values of the user defined variable. You can use this to get an idea of how individual variations of your site influence this GA stat.
Note that this is not like a GWO report. These are just raw numbers and are not analyzed for confidence with respect to which variation is statistically significant.
Comments:
Hi Erik,
Thank you for the excellent post. I’ve been using ROI Revolutions getCombo script, but your edits and using User Defined field would result in an overall cleaner output (not duplicating pageviews for example)
I’ve tried to implement your method using external files but with no luck as of yet (please forgive my ignorance).
I’ve 1) Activated the var _utcp 2) Run the MVT Head Script 3) Started and Ended the section swap 4) Run the standard GA 5) GWO Track Variation Pageview.
However, the custom variable does not seem to pass: https://www.geocities.com/nik7k7/set_var/test1.html
Nik K. : March 3, 2009 12:25 PMHey Eric,
What do you think about using Event Tracking once it is available for everyone?
Also nice updates to the ROIRevolution code, but I’m woundering if it should be altered by removing the query params which represent the combination and experiment (and be replaced with some made up virtual path name), because if the “Exclude URL Query Parameters:” GA feature is used there will be multiple pageviews recorded for a single pageview of the test I believe.
Erik Vold : March 26, 2009 12:05 AMVery interesting post!
I’m curious, how would this code need to be modified to accomodate the Website Optimizer tracking script being executed via an onclick event, such as from clicking a link? In that case, the ga.js tracking would already have occurred, right?
Am I correct in presuming this method would not work with onclick?
If not, what method would allow you to track onclick to Website Optimizer and both onlick and page views to Analytics?
David : April 20, 2009 6:04 PMThis method is not intended to work with the GWO tracking scripts. It is meant to tag GA tracking events with the variation chosen for a visitor to an experiment. If you want to track links in GA, you can do that with event tracking or call trackPageView with a synthetic URI. The GWO visitor information will travel along with that GA event and you will able to track the performance of those events per variation in GA.
Eric Vasilik : April 20, 2009 9:42 PMUsing this experiment with the old Urchin GWO allows you to track both the GWO Conversions and Google Analytics User Generated Fields.
Also, I found that it was possible to track conversions for GWO and GA by using GA onclick for example, and placing the GWO conversion code in a div wrapper around the GA Code.
Vengeful : June 8, 2009 11:23 AMAs I understand this trick will not track multiple experiments that might be running in parallel, since only one combination id is recorded.
I’ve been thinking of using the __utmv cookie value instead, so that’s set with setVar. This value records all experiment ids and combinations. A small catch though is that is doesn’t include the combination id, but the permutation string, e.g. 1-3-2 for a test with 3 sections and where each number represent the chosen section variant.
What do you think about this suggestion?
devteam : June 10, 2009 6:42 AMThis is a fine idea. You can get the combination ID by calling utmx(“combination”).
Eric Vasilik : June 12, 2009 1:14 PMHello Eric,
have you ever tried to get equivalent reports from IndexTools (Yahoo Web Analytics) instead of GA?
kind regards,
Toepper
: July 10, 2009 5:36 AMI have not tried other analytics products, but as long as you can inject segmentation information, you should be able to do something similar.
Eric Vasilik : July 10, 2009 3:14 PMHi Eric,
I would suggest moving the pageTracker function outside of the utmx function check. That way if they have GA on the page but GWO failed, they still get a GA tracking hit.
Here is the code:
(function(){try {
var l = document.location, s = l.search;
if (utmx(‘combination’) != undefined) {
s = s + (s.length ? ‘&’ : ‘?’) + ‘combo=’ + utmx(‘combination_string’);
s += ‘&test=TestName’;
}
var pageTracker = _gat._getTracker(“UA-XXXXXX-Y”);
pageTracker._trackPageview(l.pathname + s);
}catch(err){}})();
Thoughts?
Ophir Prusak : September 23, 2009 3:11 PMNice input Erik
I have a couple of comments:
using _setVar
As you know this is a persistent cookie, so when the visitor is labelled on their first visit as e.g. “MyExpertiment-0-1-3”, on their next visit they will already have this label – even if they receive a new combination. So returning visits must be discarded with this method.
Experiment without GWO reports
“This means that you will be able to track their activity before they encounter experiment variations.”
With this method, have you given any thought to catering for visits who do NOT go on to see a test page?
Brian Clifton : October 4, 2009 7:50 AMAs a response to those above who are talking about the duplicate pageviews that result from adding the combination as a query parameter (via the original ROI Revolution code that I wrote):
First, our code did not inflate pageviews (the very first version two years ago may have), as it simply adds a query parameter to the end of the GA code that’s already on the page. Second, we have always recommended excluding this information from your main profiles and only looking at the data in a separate profile used only for GWO – preferably using the Site Search report.
We’ve certainly used the User Defined variable as well, although we tend to use that variable for other things.
Thanks for the code updates Eric! It’s nice to see this go from a hack to a cleaner and more official implentation.
Shawn P. : October 13, 2009 3:48 PMIn response to Brian’s post on Oct. 4: GWO does not choose a different variation for returning visitors. So setting the var again does not hurt. And, if a visitor does not go on to a test page after executing the control script, the visitor does not see a variation, so I see no need to track them.
Eric Vasilik : October 16, 2009 1:28 PMIn response to Ophir on Sept. 23:
That seems like a fine idea!
Eric Vasilik : October 16, 2009 1:56 PMIs this happening only to me? The last few days integration does not work as it used to work.
netstudio.gr : November 1, 2009 1:25 PM