Google Website Optimizer Tricks

Tracking Outbound Links -- The Right Way

noreply@blogger.com (Eric Vasilik) — Thu, 16 Jul 2009 06:17:00 +0000

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

noreply@blogger.com (Eric Vasilik) — Tue, 19 May 2009 05:05:00 +0000

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 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 after. 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>
Default 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 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>
Default 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!

Fragmented Sections

noreply@blogger.com (Eric Vasilik) — Fri, 10 Apr 2009 06:07:00 +0000

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.

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. I have a web page illustrating this very technique.