Website Optimizer Tricks

Website Optimizer Tricks Index

2050-01-30T13:35:00.000-08:00

Current Articles:

Multiple Goals - Test more than one goal by creating multiple experiments for the same test!
GA Integration - Get experiment information into GA.
Control Script Placement - Where should you place the control script in your test page?
Advanced A/B Experimentation - Techniques for obtaining more control or A/B redirection.
Advanced Test Page Functionality - Functionality for writing customized tests.
Fragmented Sections - Test non-contiguous pieces of your page with Fragmented Sections.
Server-Side Dynamic Section Variations - How to generate dynamic section variations on your web server.
New! Tracking Outbound Links -- The Right Way - How to correctly track outbound links

Future Articles:

Client-Side Dynamic Section Variations - How to include dynamic content in a section.
Techniques for Debugging Experiments - How to check to see if your experiment is running properly.

Tracking Outbound Links -- The Right Way

2009-07-19T22:22:00.001-07:00

Let's say you want to run an experiment on a page in the foo.com domain, but you want to
register conversions in some outbound domain, say, bar.com. One way to handle this is to implement a
strategy called Google Analytics Cross Domain Linking as described in this Analytics Help Center Article.

This is a fine solution, but it suffers from two major problems. First, it requires that you have the rights to modify pages in the outbound domain. Secondly, and frankly (IMHO), it's kinda a pain in the ass to implement as well as being very error prone.

An alternative to tracking the loading of the outbound page, is to track the user's action of clicking the link to the outbound page. This is neatly described in this Analytics Help Center Article.

The only problem with this technique is that it really does not work very well. It suffers from what we in the industry call a Race Condition. To understand this particular race condition, allow me to describe a little about how browsers work.

When a web browser is loading a page and it encounters something like the following:

... la la la
<img src="a.jpg">
la te da ...

The browser does not stop at the image tag in order to load the image. In fact it does not even stop at the image tag to even start loading the image. It simply queues up a request to load that image at some later time. Later in this case means really quick; probably in the next few milliseconds. It may do this with another thread, or simply schedule it within the same thread. The important point is that the HTTP request to the server which services the image does not take place right away.

Now, consider the following HTML:

... One two three
<a href="target.htm">Click Me!</a>
... four five six ...

Here, when a visitor clicks on this link, the mechanism for loading and displaying the target page is very similar to the loading of the image above. A request to start loading that page is queued up, and when the bytes of that response start arriving, the browser erases the current page and starts rendering the new page. This is why after clicking on a link to a "distant" and slow site, you will continue to see the current page until the other responds -- there is no good reason to clear the screen on the current page until you have something new to display.

One more vital piece of information needs to be mentioned here. When a page is closed, in this case in favor of loading a new page, all the outstanding resource requests for the current, closing, page (like images) are abandoned. This fact will place a crucial role in our race condition.

Now, let's look at the code mentioned in the How do I manually track clicks on outbound links? article:

<a href="http://www.example.com" onClick="javascript: pageTracker._trackPageview('/outgoing/example.com');">

The script in the onClick handler is intended to create a Google Analytics event (called /outgoing/example.com) with the _trackPageview operation. The way that _trackPageview works is that it makes a request to Google for an, essentially, empty image. Along with that request, is the information about the visitor and what should be tracked. It's how Google Analytics gets its information in order to create reports. Now, just like the loading of an image tag, this request is also queued up by the browser -- It's not immediately requested.

Once the call to _trackPageview returns, the browser then starts the request for the outbound resource, "http://www.example.com", in this case. This too is queued up, and when it start to come in, the page will clear and the new page will be rendered.

Now, we have enough information to see where the race condition exists.

If the request for example.com comes back really quickly, it is quite possible that the request for the Google Analytics tracking image has not yet taken place. In fact, some browsers may prioritize requests for images below other requests, like those for other sites. When this happens, all outstanding resource requests for the current page, and I'm thinking about the Google Analytics tracking request in particular, are abandoned. This means that the event which was to be tracked via Analytics is lost to Analytics, as though it never happend.

Bummer.

Give It Some Time ...

So, how does one track outbound links properly?

The trick is to give the request for the Google Analytics tracking image enough time to take place. This can be done by delaying the request for the outbound page with the following technique:

<script type="text/javascript">
function doGoal(that) {
  try {
    var pageTracker=_gat._getTracker("UA-123456-1");
    pageTracker._trackPageview("http://www.example.com");
    setTimeout('document.location = "' + that.href + '"', 100)
  }catch(err){}
}
</script>

<a href="www.example.htm" onclick='doGoal(this);return false;'>Click me</a>

Here, notice that the onClick handler calls a function which, first, does not rely on the presence of a global pageTracker object to have been already set up. It creates it's own tracking object. This reduces the dependency on other scripts running on the page.

Secondly, the return value from the onClick handler is false. This prohibits the browser from following the link as a consequence of the user clicking on the link. This stops the browser from immediately navigating to example.com.

Thirdly, notice the call to the setTimeout function. The setTimeout function's job is to execute a piece of code at some time in the future, without blocking the current script from continuing executing. In this case, it's 1/10 of a second into the future, and the code to execute is that which is, essentially, the same as what the browser would have done if true (or nothing) had been returned by the onClick handler. Setting the location property of the document object with the outbound href will cause the page to navigate to that link.

By delaying the outbound navigation by 1/10 of a second (which is generally not noticed by the user), the browser now has much more time to make the Google Analytics tracking request and the tracking event will be noticed and reported on by Google Analytics.

Spiffy.

The example above applies to tracking outbound links in Analytics, and is trivially adapted to tracking Google Website Optimizer goals as well. You can see an example of a test page taking advantage of this technique here to track as the goal, clicking on a link.

The essential code in the GWO sample page follows. All that is really different is that the argument to _trackPageview is the token string for the GWO goal.

<script type="text/javascript">
function doGoal(that) {
  try {
    var pageTracker=_gat._getTracker("UA-7250447-1");
    pageTracker._trackPageview("/2353623095/goal");
    setTimeout('document.location = "' + that.href + '"', 100)
  }catch(err){}
}
</script>

<a href="anotherpage.htm" onclick='doGoal(this);return false;'>Click me</a>

Happy Clicking!

Server-Side Dynamic Section Variations

2009-05-19T01:07:00.001-07:00

This technique is one of my favorites because it involves some pretty "clever" (euphemism for twisted) JavaScript. But don't let this scare you, the script works on all the browsers and is as fail-safe as the scripting that Website Optimizer requests you place on your sites by default.

Multi-Variate Experiments "Out of the Box"

First, let's revisit certain aspects of GWO pertinent to this technique. By default, GWO handles multi-variate experiments in the following way:

Your test page and the default content for your experiment sections are served directly from your web server. If alternative content has been chosen to be displayed to a visitor, that alternative content is served from a Google server.

Now, this poses a particular limitation: the alternative content must be static in nature. The reason behind this is in the fact that, in the default setup process of a multi-variate experiment, you are requested to input the alternative content into GWO's user interface, and that content is simply served back to your test page on demand where it replaces the default content in the page for visitors selected to see the alternative content.

This means that if you wanted to customize that alternative content differently for each visitor, you don't get a chance to do so. For example, you might want to include the customer's name in the alternative content. Or, you might want to serve a promotion customized for the given customer.

Alternative Content Served from Your Webserver

The technique I am about to discuss allows you to serve all content, default and alternative, directly from your web server:

Here, the Google server does not serve any alternative content. It only serves back an indicator (an integer) of which content should be show to a given visitor. All the possible variations for the sections are rendered into the web page by your web server where you have complete dynamic control over the content of those variations. In the following, I will show you the scripts you need to generate along with that content in order to show one of either your default content or variations.

Size of Alternatives

That said, one should be careful when using this technique because it requires you to render all possible section variations into the page. Because even though your web server knows what the content of the alternatives are, it does not know which alternative will be chosen for a visitor to your test page. Contact with the Google server is required for that, and the logic about which content to show to the visitor must be executed in the browser client.

So, if the number and size of all the alternative section variations is not too large, you can use this technique. Many times, this is the case. Even if you define your entire page to be a single section, this technique may work for you because only the HTML of the alternative need be present in your page. Any other resources, like images, scripts or style sheets, which are specific to an alternative variation will be loaded if that alternative variation is chosen for a visitor. Content which was not chosen for the visitor will not even be parsed by the browser, it will essentially be thrown away.

Creating the Experiment

To use this technique, you begin by creating a regular multi-variate experiment. Give the experiment a name, test page and goal page. When asked to add the GWO scripts to the page, add the control script in the normal way. And, add the tracking scripts in the normal way.

However, do not follow the default instructions for adding section scripts. I have prepared an example test page you can look at which illustrates the alternative to the default section scripts which allows you to serve alternative section variations from your web server:

Server Side Sections Example

First, you will want to declare the number and names of the server-side dynamic experiment sections you plan to test. Sections are normally declared as a result of surrounding the default content of a section with the standard GWO sections scripts. But, because we are not using those, you need to use an alternative. So, to declare a single section with the name "Section1", place the following immediately after the Control Script:

<!-- utmx section name="Section1" -->

You can repeat this kind of comment to declare up to 8 sections. For example:

<!-- utmx section name="Section1" -->
<!-- utmx section name="Section2" -->
<!-- utmx section name="Section3" -->

Note that you can mix regular GWO multi-variate section with server-side dynamic sections. Simply include the standard GWO style sections as described in the default install instructions.

Instrumenting the Sections

The following script is the entire definition of the section from my example page. I show you in its entirety here, and will dissect it later. Note that the dynamic content for each variation is highlighted. These are the parts of the page you get to dynamically generate. Only one of them will be show to a given visitor, the others will be stripped away.

<script>
var GWO_Section1 = utmx("variation_number", "Section1");
if (GWO_Section1 != undefined && GWO_Section1 != 0) document.write('<no' + 'script>');
</script>
Original content - shown by default<br>
</noscript>

<script>
if (GWO_Section1 == 1) document.write('</noscript a="');
</script><!--">
Alternative content 1<br>
<script>document.write('<'+'!'+'-'+'-')</script>-->

<script>
if (GWO_Section1 == 2) document.write('</noscript a="');
</script><!--">
Alternative content 2<br>
<script>document.write('<'+'!'+'-'+'-')</script>-->

The basic idea with this technique is that each of these script blocks controls a piece of content. The first controls the original content. By default, the original content is show to the visitor. The other script blocks control the alternative pieces of content, one of which, is meant to replace the original content. By default the alternatives are hidden from the visitor. If an alternative is chosen to be shown to the visitor, then the script blocks will work together to hide the original and show only one of the alternatives to the visitor.

The content contained in each of these script blocks is totally under your control in your web server. Which one of them is shown to the visitor is under the control of Website Optimizer.

The Default Content

Like any GWO experiment, the default content is encoded in your test pages, and if JavaScript is not present or disabled, or there is any malfunction anywhere, the default content will be presented to your visitors. With this technique, the default content is handled with this script:

<script>
var GWO_Section1 = utmx("variation_number", "Section1");
if (GWO_Section1 != undefined && GWO_Section1 != 0) document.write('<no' + 'script>');
</script>
Original content - shown by default<br>
</noscript>

Here, the script code firsts obtains the number of the variation for the section named "Section1" chosen for the current visitor:

var GWO_Section1 = utmx("variation_number", "Section1");

This call to the utmx function will return a 0 (zero) or undefined if the visitor should see the default content. This value is saved in a global variable for use in subsequent alternative content scripts. Note that the utmx function is defined by the Control Script which needs to have been executed before the call to the utmx function in this script.

Then, if alternative content has been chosen for this visitor, the default content is hidden from the visitor with the second line of code:

if (GWO_Section1 != undefined && GWO_Section1 != 0) document.write('<no' + 'script>');

By document.writing a beginning <noscript> tag, the content after the script and up to the first </noscript> tag will be consumed and ignored by the parser. This requires that your default content not contain any noscript tags (beginning or ending). This is exactly the same technique used by GWO for standard installations of multi-variate experiments. The only difference is that here we are just removing the default content, but the standard GWO multi-variate technique document.writes the alternative content to replace the default content before writing the <noscript> tag to eliminate the default content.

The Alternative Content

Now, for each variation of alternative content for a given section, you will need a script like this:

<script>
if (GWO_Section1 == 1) document.write('</noscript a="');
</script><!--">
Alternative content 1<br>
<script>document.write('<'+'!'+'-'+'-')</script>-->

Note that the 1 indicates that this script is customized for the first alternative. The second alternative will have the number 2, the third 3, etc. The larger highlighted part is your dynamically generated alternative content for the first alternative. Simply have your web server surround the alternative content with the other text.

The first line of the script determines if this alternative was chosen to be viewed by the visitor and document.writes some content designed to cause the variation to be shown to the visitor:

if (GWO_Section1 == 1) document.write('</noscript a="');

To understand this better, consider what this content would look like if scripting is disabled, or the value of GWO_Section1 does not have the value 1. That is, there is no script:

<!--">
Alternative content 1<br>
<script>document.write('<'+'!'+'-'+'-')</script>-->

This entire block of HTML is nothing more than one large comment. In fact, the alternative content is hidden by default by the fact that it is embedded inside a comment. This means that the alternative content must not have any comments in it. Note that even the script at the end of the HTML is also inside the comment.

Now, look carefully at what is written if this section variation has been chosen to be displayed to the visitor:

</noscript a="

This is the beginning of an ending noscript tag. Note that there is no > terminating the tag. Also, in this tag there is the beginning of an attribute. Notice, also, that the value of the attribute is not present and that the ending double quote is not present. That is not two single quotes. It is a single double quote.

Recall that the way that document.write works is that the written text is, essentially, inserted after the end of the script where the browser parser will resume its parsing after the script has executed. Again, by stripping away the first script tag, let's look at what the parser will encounter:

</noscript a="<!--">
Alternative content 1<br>
<script>document.write('<'+'!'+'-'+'-')</script>-->

Here the parser sees an ending noscript tag with an attribute whose value are the characters which begin a comment. The thing to know here is that HTML parsers allow beginning comment sequences inside attribute values. This is the clever (twisted) part I eluded to earlier.

Now, it should be apparent why there was the "> characters immediately after the beginning comment character sequence: <!--. It is there to terminate the dynamically written ending noscript tag. This tag "eats" the beginning comment token. Yummy.

This allows the parser to parse and display the alternative content. Now, all we need to do is deal with the remaining ending comment token! This is done by the last part of the script:

<script>document.write('<'+'!'+'-'+'-')</script>

Which injects a beginning comment token which is terminated by the remaining ending comment token, statically present in the page. Without this document.write, the "-->" would appear in the page when this alternative content was chosen for the visitor.

This is how each alternative variation is handled. Simply do the above for each alternative section. Each one will have the server generated content of the variation. Each script will have the number of the variation encoded in it. 1 for the first alternative, 2 for the second, etc.

You can repeat this sequence of scripts for a section as many times on your page(s) as you want to hide/show the default/alternative content for that section.

Setting Up the Variations in GWO

Even though this technique requires you generate all your alternative content into the page, you will still need to create section variations in Step 3 of the GWO user interface for each section in your test. The only difference is that you do not supply any content for these variations. The reason for this is that GWO still needs to know how many variations each server-side dynamic section has for the purposes of choosing which variation visitors will see and reporting results. For example:

Shows the section named "Section1" with two (2) variations created for it. I give each variation a name for reporting purposes, but I do not need to give it any content.

After Doing this, all that is left to do is preview the experiment to make sure the scripts are working and launch the experiment!

Test non-contiguous pieces of your page with Fragmented Sections

2009-04-09T22:29:00.000-07:00

The default setup for a multi-variate experiment asks you to place what are called "Section Tags" on your test page. For example consider a header for a fictitious pet food web site:

<script>utmx_section('Heading')</script>
World's best pet food!
</noscript>

The purpose of these tags is to identify a contiguous span of HTML on your test page with which you would like to experiment. In the GWO online tool, you would enter the alternative variations for this section. For example:

This allows you to specify an alternative which will replace the original content on your test page. In fact, everywhere this pet food website mentions the phrase "World's best pet food!", you could instrument that phrase with the scripts above to have a visitor to your site experience every instance of the phrase on the site with the same alternative variation.

But, what if you want to vary multiple parts of a page (or pages) on your site in concert with each other? For example, let's say that our fictitious pet food web site shows a letter to visitors, like so:

Then let's say that you want to have multiple variations of the letter, each with a different tone in the salutation and signature. For example, an informal tone:

Or, a formal tone:

Now, you could implement this in the same manner as the section shown above. However, because the salutation and signature are separated by the body of the letter, you would have to include an entire copy of the body in each variation of the section, where the different variations differ only by the salutation at the beginning and the corresponding signature at the end.

Now, in this simple example the body is not that large, but the redundancy runs the risk of introducing different bodies which would foil the experiment. And, in the case where the body is not small, you would not want to replicate the body. Furthermore, it might be the case that the two parts of your site you want to vary in concert with each other are not on the same page. The standard section tagging technique breaks down entirely in this case.

The technique I am about to explain will allow you to experiment with your site in such a way as to only require you to alter the actual pieces of the page you want to change, but allow you to have those pieces change together. This is what I call Fragmented Sections. First, a look at what you would enter into the GWO online tool for a variation of our letter's Tone section:

What I've done here is to place what I call Fragments of a single section variation surrounded by special %% tokens which identify the fragments with monotonically increasing numbers starting with 1 (fragments cannot have %% sequences in them, or a different token will need to be chosen). Thus, the salutation (the first fragment) of the Formal variation of the Tone section is represented by:

%%Frag 1%%Dear Sir/Madam%%

and the signature (the second fragment) is represented by:

%%Frag 2%%Sincerely%%

The value for the informal variation of the section would look like:

This is a single section with multiple parts to it. Now, how does one use these multiple parts in the actual web page? Here is what the letter part of our pet food web site would look like:

<p><script>write_frag('Tone', 1)</script>Hello</noscript>,
<p>
We're so sure your pet will flip out over this food, we
offer a double your money back guarantee! If your pet
is not satisfied in 30 days of purchase, just return the
unused portion of the food and a notorized letter from
your pet explaining why the food was less than perfect.
<p>
<script>write_frag('Tone', 2)</script>Thanks</noscript>,<br>
The Pet Food Company

I've highlighted the two section fragments. They are very similar to the standard tags one would use, but instead of calling the utmx_section function, they call a function called write_frag. Also notice that the default version of the section fragments are encoded in the page, surrounded by the function call and a </noscript> tag - just like standard section tagging.

Now, the definition of the write_frag function:

<!-- utmx section name="Tone" -->
<script>
function write_frag(section, frag_num) {
var content = utmx('variation_content', section);
if (content) {
var token = '%%Frag ' + frag_num + '%%';
var start = content.indexOf(token) + token.length;
var finish = content.indexOf('%%', start);
document.write(content.substring(start, finish));
document.write('<no' + 'script>');
}
}
</script>

The first line of this block of HTML is a special comment which declares the presence of the Tone section to GWO. GWO normally detects the section of a multi-variate experiment by looking for the standard section tags. But, because those are not present, this comment is an alternative way of declaring the section.

First, the write_frag function uses functionality that is defined only after the Control Script has executed on the page. The write_frag function takes two arguments: a section name and a fragment number. What the function does is acquire the value of the the section's variation as it was entered into GWO:

var content = utmx('variation_content', section);

This call's the utmx function which is detailed in another article. This call returns one of the %%'ed variations defined for the specified section which was chosen by GWO for this visitor to see. If an alternative variation is not returned, then the function does nothing else, and the default content is displayed. However, if an alternative variation is returned, then the function searches that variation for a block of text surrounded by the special %% tokens. The start token takes the form %%Frag #%% where # is replaced with the number of the fragment. In this example, there are two fragments, but you could have as many as you want.

Then, after isolating the value of the fragment, it document.write's this along with a </noscript> tag. This is exactly what the utmx_section does for you in the standard version of section tags. This causes the browser's parser to encounter and display the fragment's value while removing the original's value.

Thus, with this technique, you can define sections which need not be contiguous. Please note that although this example shows how you can have a fragmented section influence a single page, the technique works just as well across multiple pages. Be sure to include the Control Script at the top of each page which contains a section or a fragment of a section.

I have a web page illustrating this very technique.

Advanced Test Page Functionality

2009-03-17T23:06:00.000-07:00

Recently, I added functionality to pages which contain the Control Script (these are usually test pages). This new functionality allows you to obtain more information about the variations and combination chosen for the visitor to a experiment, allowing you more flexibility in developing customized tests. I will elaborate on testing techniques which use these features in other articles. In this article, I want to simply document the new functionality in detail.

The utmx function

All the new functionality are accessed via the utmx function which is defined as a consequence of including the Control Script on a page. The utmx function is designed to be the single entry point for most current and all future functionality provided to test pages. Its signature is:

utmx( feature, arg1, arg2, ... argn )

The first argument is a string which describes the desired feature requested. The second, third, etc, arguments are dependent on the requested feature.

The value that the utmx function returns is dependent on the requested functionality. It may be a string, a number or other value. However, no matter what feature is requested, the utmx function may return undefined. The undefined return value may indicate that the utmx function was not redefined by the Control Script, and that any GWO related functionality on the page should show default (original) content or take default behavior. To illustrate this point, consider what the beginning of the Control Script looks like:

<script>
function utmx_section(){}function utmx(){}
(function(){var k='3923492669',d=document,l=d.location,c=d.cookie;function f(n){
.....

Notice that the utmx function is initially defined to have an empty body. When a function like this is called in JavaScript, the return value will be undefined. If, for whatever reason, the Control Script is unable to load siteopt.js, which redefines the utmx function, this original definition will remain and return undefined for anyone who calls it. In order to have pages not break under these circumstances, it is important to check the return from utmx for undefined and take the appropriate actions.

Variation Information

The following two features allow you to obtain information about what variation was chosen for a given section:

utmx( "variation_number", section_name )

and,

utmx( "variation_content", section_name )

In each case, the section name is the name (a string) of the section for which you want the information. This is the same value you would pass to the utmx_section function for a multi-variate experiment. In the case of an A/B experiment, GWO creates a single section called "A/B" which can be used here as well.

The "variation_number" feature returns either undefined or an integer number between 0 and N-1 where N is the number of variations defined for the given section, including the original. If 0 or undefined is returned, this indicates that the original content or behavior for the given section was chosen for this visitor. Values 1 through N-1 indicate that a non-original alternative for the given section was chosen for this visitor. In this case, the appropriate alternative action should take place.

The "variation_content" feature returns either undefined or a string. If undefined is returned, this indicates that the original content or behavior for the given section was chosen for this visitor. Otherwise, a string is returned, indicating that a non-original alternative for the given section was chosen for this visitor. The value of this string is exactly what was entered in the GWO user interface as the value of the variation chosen for the visitor. In the case of an A/B experiment, the value returned is the alternative URL entered in GWO user interface, exactly as it was entered.

Both of these features can indicate non-original alternatives for the given section for both "preview" and "live" page requests and should be used to alter the visuals or behavior of the page. A "live" request is a test page viewed by a visitor while the test is running, as opposed to a "preview" request which is one performed by the GWO preview window.

Combination Information

The following two features allow you to obtain information about what combination was chosen for a "live" visitor. Note that under "preview" requests, no combination information is available, undefined will be returned. These features apply only to "live" requests. Because of this, these features should not be used for altering the appearance or behavior of a test page. They can only be used to indicate what combination was chosen for a visitor to a running experiment.

utmx( "combination" )

and,

utmx( "combination_string" )

The "combination" feature returns either undefined or an integer between 0 and M-1 where M is the total number of combinations defined for the experiment, including the original. If undefined is returned, this indicates that this test page request was not a live request. If 0 is returned, this indicates that the original combination was chosen for the visitor. Otherwise, 1 through M-1 indicate that a non-original alternative was chosen for the visitor. Note that M is the product of the variation sizes of all the sections defined for the experiment. So, if you have an experiment with two sections, say, headline and image, and the headline has 3 alternatives and the image has 4 alternatives (each including the original), then M will be 12.

The "combination_string" feature has similar semantics as the "combination" feature. It returns undefined under the same conditions. However, the return value is a string with the variation numbers for each section separated by dashes. For example a 3 section multi-variate experiment may return "3-0-2" where 3 is the variation number for the first section, 0 for the second and 2 for the third. In this example, "0-0-0" would indicate that the original combination was chosen for the visitor. Again, undefined indicates that this was not a "live" request.

For A/B experiments, the combination features behave like a multivariate experiment where there is only one variable.

An example of using the combination information can be found in this article: Poor Man's GWO/Analytics Integration.

Declaring Multivariate Sections

When using the above functionality for implementing tests, you will probably no longer use the standard multi-variate section script. For example:

<script>utmx_section("Button")<script>
<input type=button" value="Click Me">
</noscript>

The standard section script does two things. First, it declares the section named by the argument to the utmx_section function (Button, in this case). Secondly, it implements the actual replacement of the default content should a visitor been chosen to see an alternative variation.

When implementing the more advanced techniques for experiments, you may frequently no longer use the utmx_section function. However, you will still need to declare a section so that GWO will know the schema of your experiment. To declare a section without impacting your test page, you can use a special HTML comment. For example:

<!-- utmx section name="Section1" -->
<!-- utmx section name="Section2" -->

Declares two sections, but otherwise, has no impact on the page in which it is present (because they are comments). This way, when you validate your test page in the GWO UI, GWO will see the two sections you intend to declare. Then, the implementation of those sections on your page is under your, separate, control.

Advanced A/B Experiments

2009-02-05T12:45:00.000-08:00

GWO provides for an A/B style of testing "out of the box". However, sometimes you may find it does not quite suit your needs, or, you may need more control over the URL to which visitors get redirected. This article describes how to perform an A/B test where you have much more control over how the redirection to the alternative pages takes place.

The following is a technique for performing an A/B test such that you have an opportunity to dynamically participate in the construction of the alternative URL's.

First, instead of creating an A/B experiment, create a Multi-Variate experiment. Place the control script at the top of your test (A) page. Place the test page tracking script at the bottom of your test page and alternate pages (B, C, etc). Place the goal tracking script at the bottom of your goal page.

Now, instead of introducing the multi-variate sections scripts, place the following somewhere in your test page (I recommend it go near the control script):

This HTML comment is very much like a section script in that it declares a section named "page-url", but does not modify the page or the user's experience at all.

Now, you can validate the test and goal pages and move on to specifying the alternate URLs which you want to test. Enter these into the GWO UI as the content of variations for the page-url section. Here I've specified a simple relative URL, but you can specify a complete URL if you want:

Before launching or previewing your experiment, place the following script immediately after the control script on your test (A) page:

<script>
function filter(v) {
var b = utmx('variation_content', 'page-url');
var u = v[0].contents;
if (b && u.substr(0,7) == 'http://' && b.substr(0, 7) != 'http://') {
u = u.substr(7);
}
return u;
}
utmx('url', 'page-url', 0, filter);
</script>

At this point, you can preview and launch the experiment. It will behave just like any other A/B experiment.

You can see an example of this in action here as follows.

Test (A) Page (inactive)

Note that that URL will take you to the A page without enrolling you in the experiment. In order to experience a possible redirect, remove the content after the # in the link's URL:

Test (A) Page (active)

The Filter Function

This script above will perform the redirection to alternative pages, should GWO decide that a given visitor is not to see the A page. Let's look at a bit more closely.

<script>
function filter(v) {
...
}
utmx('url', 'page-url', 0, filter);
</script>

The utmx function is defined by the control script. It is the main entry point for a variety of GWO functionality available in test pages. In this case, the first argument, 'url' tells the function that it should treat this experiment as an A/B experiment and perform a redirect if necessary. The second argument, 'page-url', is the name of the section which defines the alternative URL's. The third argument is a positional indicator and should be set to zero in this case. Otherwise, I will not describe it here.

The fourth argument is a filter function which you define and is called just before redirection takes place. It takes, as an argument, an object containing the redirection URL computed by the utmx function and returns the actual URL to which the user will be redirected. It is your opportunity to get involved in the form of the URL the visitor is redirected.

Before calling the filter function, the utmx function does a number of things to the target URL. First, it merges all query parameters of the current URL (document.location) with the query parameters of the target URL. This allows an alternate page to have the same information the A page has. For example, you might encode product ID's as a query param:

http://www.mystore.com?product=slinky

You might enter:

http://www.mystore.com/b-page.htm

As the alternative B-page URL for your experiment. Because you are testing all your product pages, you can only specify the B-page URL, sans the product. GWO will redirect to:

http://www.mystore.com/b-page.htm?product=slinky

Which allows your B-page to know which product is being queried and present that product in the context of the B-page.

The utmx('url', ...) function also looks at the URL and adds http:// to it if it does not already have it. Many times, this is fine, if you don't specify the protocol. For example:

www.mystore.com/b-page.htm

But it can sometimes get in the way. For example, you might want to specify (as I do in my example above), a simple, relative URL for the alternate pages:

b-page.htm

The the code in the custom script above will strip this away as needed:

var b = utmx('variation_content', 'page-url');
var u = v[0].contents;
if (b && u.substr(0,7) == 'http://' && b.substr(0, 7) != 'http://') {
u = u.substr(7);
}
return u;

If the "raw" version of the alternative in the variable 'b' does not begin with http:// but utmx's version does, then it will be stripped away. Finally, the URL in the variable u is returned where GWO will perform a redirection to it.

URL Customization

The filter function allows you to inspect and modify the redirection URL at will. To demonstrate this further, consider my example above where the product ID is a query parameter:

http://www.mystore.com?product=slinky

But, what if my site encodes the product in the path of the URL? Like so:

http://www.mystore.com/slinky/a-page.html

And, I want to test an alternative page, like so?

http://www.mystore.com/slinky/b-page.html

You'd might enter the alternative URL in GWO as:

http://www.mystore.com/slinky/b-page.html

But, because your test page will be called for more than one product, like:

http://www.mystore.com/tofu/a-page.html

You can't enter that URL, otherwise all users will see only the tofu product, regardless of which product they may have clicked on. Or, you might enter:

http://www.mystore.com/b-page.html

But, no product is specified here, and your web server might produce an error page.

What you need to do in cases like this is write some custom JavaScript which builds the correct URL. So, building off the last example, consider the following example. Let's say the the following URLS are two of among many products:

http://www.mystore.com/slinky/a-page.htm
http://www.mystore.com/tofu/a-page.htm

And you specify an alternative URL like so:

http://www.mystore.com/PRODUCT/b-page.htm

The idea is while computing the URL to which a redirection will take place, inspect the current URL (document.location.href) for the name of the product, and replace the word PRODUCT with the name of the current product in the a-page. Like so:

<script>
var b = utmx('variation_content', 'page-url');
function filter(v) {
  var u = v[0].contents;
  if (b && u.substr(0,7) == 'http://' && b.substr(0, 7) != 'http://') {
    u = u.substr(7);
  }

  var l = document.location.href;
  var prefix = 'mystore.com/';
  var i = l.indexOf(prefix);
  var j = l.indexOf('/', i + prefix.length);
  u = u.replace('PRODUCT', l.substring(i + prefix.length, j));
  
  return u;
}
utmx('url', 'page-url', 0, filter);
</script>

This is very much like the first example above, but instead of simply returning the URL, we get the current product name and use it to replace the place-holder token, "PRODUCT" which is present in all alternative URL's. This allows us to redirect to the proper alternative URL, while preserving the current product the visitor is interested in.

You can see this in action here:

http://www.gwotricks.com/abadvanced/slinky/b-page.htm

Happy redirecting!

Where does the Control Script belong?

2009-02-03T15:00:00.000-08:00

I frequently see test pages in which the control script is not placed in a good location. In this article, I want to talk about the things to consider when placing the control script into your test pages.

Latency

The presence of the control script in your page will introduce latency into the total load time of the page. When the control script executes, it generates a request for a Google resource called siteopt.js. The latency is attributed to the time it takes for siteopt.js to load. To demonstrate this, with Firefox, you can load siteopt.js in the presence of the Firebug add-on that can measure the amount of time that it takes the page to fetch various resources. For me, inside the Google corporate network, it takes on average about 20 milliseconds to load siteopt.js:

When I do the same thing from my home, it takes a little more time, about 36 milliseconds (I use a microwave based ISP, which adds a little bit of latency to everything):

In order to minimize this latency, Google distributes the servers that respond to siteopt.js requests all over the globe. This way, visitors from Mongolia to your test page don't have to load siteopt.js from a faraway server in the United States, they will probably get siteopt.js from a server in Asia, or Northern Europe.

Redirection

If you are running an A/B experiment, the control script may cause a redirection to happen if Google decides that this particular visitor should see a page other than the A page. This means that all the processing that the browser is doing when the redirect takes place will be aborted when the new page is loaded.

Other Resources

Given these aspects of the control script, it is very important that the control script appear before any references to external resources. These include CSS, script, image, objects, and the like. The reason for this is that if the control script decides to perform a redirect, all the time and work involved in loading these resources will be wasted and, most likely, performed again in the target of the redirect. This leads to increasing the total latency that the visitor experiences.

Displayable Content

Because the control script loads alternative content used in the display of the page, it needs to appear before the points in the page that potentially use this alternative content. Additionally, it is very important that the control script appear before any content in the page that is displayed to the user.

The reason for this is, again, latency. If the control script were to appear after, say, the first paragraph of the page, the user would see that paragraph, experience a very brief latency, and then the rest of the page would display. However, if the control script were to appear before this paragraph, then the window remains blank during the small latency, and then the page would render as a whole. This is a better experience for the user.

Also, a browser may spend less time laying out the page because there is no interruption of the display of the page.

Document Type Declaration

Many pages have a document type declaration. It may look something like this:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Browsers will change the way they parse an HTML file based on this declaration. In order to determine the type of a page, browsers will "sniff" for this declaration at the very beginning of the page. If they find a well formed declaration, then the parser for that document type will be instantiated.

It is very important that the control script appear after any document type declaration. The reason for this is that browsers will only look so far into an HTML document when sniffing for these declarations. The presence of the control script before the declaration may cause the browser to not find the declaration and to choose the wrong parser. This can have devastating effects on a page, potentially rendering it unusable.

Conclusion

So, in a well formed HTML document, the control script should be:

After any document type declaration
Before any other resources (CSS, scripts, etc)
Before any displayable content (text, tables, etc)

In a well formed document, these restrictions are usually accommodated by placing the control script as the very first element of the head element, just after the beginning <HEAD> tag.

Poor Man's GWO/Analytics Integration

2009-02-01T00:06:00.001-08:00

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">
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">
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:

Test Page

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.

Multiple Goals

2009-01-30T13:48:00.001-08:00

Today in GWO you can track, for example, when a visitor purchases something and/or signs up for a newsletter. This is done by simply executing the goal tracking script for both of these events. However, some experimenters want to track these kinds of things independently: how do site variations influence purchases independent of sign ups and vice-versa, for the same visitors.

For the purposes of the description of this technique, I will assume a multi-variate experiment is being used. Later on, I will describe how to adapt the technique to an A/B experiment.

The experiments I created for my sample test.

Begin by creating two nearly identical GWO experiments (I recommend giving them the same name, followed by '1' and '2', respectively). The first experiment should be set up normally. Assuming an MVT experiment, put the control script at the top of the test page, the tracking script at the bottom, and the section scripts throughout. Also place the goal tracking script at the bottom of the your first goal page (or wherever you want the first goal to fire).

You can then validate the first experiment. and continue on to adding the variations for the experiment's various sections. Once done with that, you can progress on to the launch page, but do not launch the experiment at this time.

Then create the second experiment for the same test page and the second goal page. Do not place the control script for this second experiment in any pages. Do place the test page tracking script from the second experiment just after the test page tracking script for the first experiment. You will not want to modify the section scripts in any way. Do place the second experiment's goal tracking script at the bottom your second goal page (or wherever you want the second goal to fire).

When you try to validate the second experiment, because the control script is not present on the test page, it will fail. Simply click continue in the validation dialog box, then click the continue button on the install page (which should now be enabled). You will be presented with a confirmation dialog because validation did not complete. You can also upload temporary test and goal pages for the second experiment to get past validation (this will be required for A/B experiments because the A/B experiment wizard does not allow for skipping validation at this time).

For the second experiment you will need to create the same number of variations for each section as the sections in the first experiment. However, you will not need to fill in any alternative content, just leave the variation content alone for variations in the second experiment, that content will not be used. You should name the variations in the second experiment the same as the first. You should then launch the second experiment. It will not yet have any effect.

Then, place the following custom script immediately after the control script for the first experiment:

<script>
(function() {
function set_cookie(name,value,timeout) {
if (_udn && _udn != "") value += ";domain=" + _udn;
value += ";path=" + _utcp;
if (timeout == 0 && _utimeout && _utimeout != "") timeout = _utimeout;
if (timeout > 0) value += ";expires=" + (new Date((new Date).getTime()+timeout*1000)).toGMTString();
document.cookie = name + "=" + value;
}

function CopyExperiment(src_key, dst_key, dst_id, dst_g, cookie) {
var cs = document.cookie.split(';');
for (var i = 0; i < cs.length; i++) {
  var c = cs[i].split('=');
  var s = c[0];
  while (s.length > 1 && s[0] == ' ') s = s.substr(1);
  while (s.length > 1 && s[s.length - 1] == ' ') s = s.substr(0, s.length - 1);
  if (c.length == 2 && s == cookie) {
    var es = c[1].split('.');
    var d = 0;
    var dv = "";
    for (var j = 1; j < es.length; j++) {
      var ek = es[j].substr(10, 10);
      if (ek == dst_key) {
        d = j;
      } else if (ek == src_key) {
        if (dst_g.length > 0) {
          dv = dst_id + dst_key + ':' + dst_g + es[j].substr(22);
        } else {
          dv = dst_id + dst_key + es[j].substr(20);
        }
      }
    }
    if (dv.length > 0) {
      if (d == 0) {
        es.push(dv);
      } else {
        es[d] = dv;
      }
    }
    set_cookie(cookie, es.join('.'), 63072000);
    return;
  }
}
}

// Custom variables, adapt them to your own experiments
var src_key = '3923492669';
var dst_key = '4234772301';
var dst_id = '0000370338';
var dst_goal = '2';

CopyExperiment(src_key, dst_key, dst_id, dst_goal, '__utmx');
CopyExperiment(src_key, dst_key, dst_id, '', '__utmxx');
})();
</script>

You can obtain a copy of this script from the source of my example test page.

First note the four customizable variables near the end of the script. You will need to modify these to adapt the custom script to your new experiments. The effect of this script will be to copy experiment information from the GWO cookies for the first experiment to that for the second. The first three numbers need to be quoted, zero padded 10 digit numbers. The last is a single quoted digit.

For the value of src_key, substitute the experiment key for your first experiment. You can find this key near the beginning of the first experiment's control script:

Remember that in the custom script above, this must be enclosed in quotes and be a 0 padded, 10 digit number.

The dst_key is similar to the src_key; it can be found at the same place in the second experiment's control script.

The dst_id and dst_goal are a bit more difficult to find. To obtain them, load the following URL into Firefox, or use the curl command (other browsers, like IE, will not show you the source of the returned script). Be sure to substitute the 10 digit utmxkey with the experiment key of your second experiment (the value of dst_key).

http://www.google-analytics.com/siteopt.js?utmxkey=4234772301&utmx=&utmxx=

This URL will return a chunk of JavaScript which, probably around the third line (which will be rather long), will contain something that looks like:

set_cookie('__utmx','00003703384234772301:2:0-1',63072000)

The single digit located between colons is the value you will need for dst_goal. In this example it is 2. Find this value and substitute it for the one in the custom script. Make sure this is the set_cookie call for __utmx, not __utmxx.

Then, locate the 20 digit, zero-padded number, just before the number for the dst_goal. The first 10 digits of this number is what you'll use for the dst_id. Substitute this number for the one in the custom script.

You can now preview the first experiment to make sure it looks good, and then launch the first experiment. You should now have two new experiments, each of which are running. If you need to pause the multiple-goal experiment, you need only pause the first experiment.

Example of GWO's __utmx cookie created when visiting sample test page.

When a visitor loads a test page, after the control script has run and has updated the GWO cookies to contain information about the first experiment (which combination the visitor is to see, most specifically), the custom script will execute and update the GWO cookie to mimic, for the second experiment, the combination chosen for the first experiment. This way, both experiments, on a per visitor basis, will be in sync with each other. However, because the two experiments have different goals, visitors will tracked differently with respect to these goals.

The report for the first experiment will show you how the first goal converts for all the users of the experiment, while the report for the second experiment will show you how the second goal converts for the exact same set of visitors.

Note that you will need to perform the preceeding customization for any page which is tested. That is, anywhere you would have placed the control script, you need to also include the custom script above, and anywhere you would have placed a test page tracking script, you will need to have both test page tracking scripts for both experiments.

With respect to goal page tracking scripts, these are treated exactly as any normal experiment. For example, you can trigger the test page tracking script in response to a click event. There is no need for customization of the goal tracking scripts.

Example Files

I have constructed an example using this technique. You should be able to visit the test and goal pages and see your cookies reflect the presence of the two experiments (which are actually running live):

Customizing A/B Experiments

If you want to use this technique for an A/B experiment, you will perform a very similar setup. The only modification you will need to make is to edit the control script of the first experiment in your test (A) page. At the end of the control script for an A/B experiment, you will find the following script:

You will need to remove this from the control script and place it to be after the custom script. This script is executed to perform the redirection to alternative pages, and needs to take place after the editing of the GWO cookies for multiple goals.

Reporting

I have noticed that the reports for the two experiments can sometimes show a different number of visitors for the same combinations. But I have found that over time the two reports synchronize.

Because the two experiments have different goals, they will probably not recognize the same winners, or have the same amount of confidence. You will have to choose which combination, on whatever experiment, satisfies you.

Also, because you are measuring two goals simultaneously, you should wait for a combination for either goal to become a particularly clear winner before acting upon it. The idea behind this is that you are waiting for two events to show significance without controlling for it. One of two events has a better chance of looking significant than one alone, so wait a bit longer for a winner to take a particularly significant lead.

Future Compatibility

This technique replies on the fact that, currently, the control script creates and edits GWO cookies (actually, siteopt.js does this, but the control script fetches siteopt.js). I have been considering changing this so that instead of the control script manipulating cookies, the test page tracking script will do this. This probably won't happen for a while, but when it does, you will have to modify this technique slightly.

How will you know when this may be the case? I will probably modify the control script to have a new version number. Here is the line from the control script which would be modified:

+'/siteopt.js?v=1&utmxkey='+k+'&utmx='+(x?x:'')+'&utmxx='+(xx?xx:'')+'&utmxtime='

The new version number will be 2 (or greater), indicating that the control script is different and may no longer be setting cookies. You can verify this by making the above request for siteopt.js for one of your new, running, experiments. I recommend the second experiment which you launch early. You will want to check to see if it still performs a set_cookie call. It is also possible that the control script's version number may not change, and siteopt.js will simply not set cookies for new experiments. Thus, you'll just need test to see what the situation is.

When the control script no longer edits cookies, there may be three ways to continue to use this technique (assuming GWO has not already built in multiple goals):

Place the custom script to come after the first experiment's test page tracking script, which will have created the GWO cookies. Then, when the second experiment's tracking script is called, the custom script will have edited them properly.
Revert the version of the control script back to the last version which still has it setting cookies.
Instead of the control script editing GWO cookies it will probably edit a the GA global variable to contain the new values to be assigned to the GWO cookies which the tracking script will set. Edit the values in the GA global variable.

In any case, until this change takes place, I'll not know what the correct workaround will be, so make sure you test this technique before using it. When I do effect the change, I'll try to remember to update this article. Remind me if I've forgotten :-)

More than Two Goals

This technique should also generalize to more than two goals. Simply create a new experiment for each additional goal and treat it in a similar fashion as the second experiment above.

Stopping, Pruning, Creating Copies and Follow Up Experiments

To stop this kind of experiment, simply stop both experiments at the same time. Also, when making copies or creating follow up experiments, simply perform the same operation on both experiments.

When pruning, one need only prune combos from the first experiment. If you want, you can prune the same combos on the second. In general, performing any operation should be applied to both experiments.

Report Discrepancies

In general, the number of impressions that one sees for variations in both experiments should be exactly the same. However, because the experiments are, essentially, being tracked independently, differences can arise. There are a variety of reasons for this which are, to a great extent, out of your control.

For example, if a visitor to your site closes the window immediately after loading the site, one of the tracking requests might get through, while the other is canceled.

However, the discrepancies should either reconcile after a couple of days, or be small. For example, my example experiments currently read:

Showing a slight discrepancy. I would not be too concerned unless it starts to differ by more than, say, 5%.

Interpreting Reports

So, what does one do if a variation is a winner in one report and and a loser in another? Well, that's up to you and how much you value each conversion. I would recommend running a multiple-goal follow up experiment. The more metrics you measure, the greater the chance that one of them may be misleading.