Google Website Optimizer tips and hacks

This post could make you tons of money. Seriously. If you have an ecommerce web presence of any kind, you are nuts if you are not taking advantage of Google Website Optimizer. This post will show you some of my personal hacks and developer tips I’ve whipped up for using this tool on a real-deal fully dynamic SEO-ed site (we’re talking 2 million + unique visitors a month).

For anyone who doesn’t know, Google Website Optimizer, is a slick, designed from the ground up multivariate web testing suite that Google, as is their custom, gives away for *free* (this is a free product in a space where the usual players run you around 40K a year, all you need is an Adwords account).

In simplest terms for those not familiar with multivariate testing, Optimizer lets you carve up different areas of a given page you want to test by enclosing said areas with simple javascript tags. You add another javascript snippet to a second page that serves as the goal for what your tested page is trying to accomplish (ex. your checkout page might be the goal for the product page you are testing). You then submit through the Website Optimizer interface different alternatives for content to be displayed in each area you have specified, say three different header variations, two different footers, and maybe two different product-pitch-blurbs like a hard sell and soft sell. Once you have it all wired up and turned on, distinct users are served a different ‘recipe’ of the different possible combinations, and Google logs their relative success in making it to your goal page vs. your original content. Run those tests until a statistical conclusion can be draw, implement the best scoring recipe, and there are potentially HUGE conversion gains to be had.

The website optimizer diagram Google shows at SEO conferences.

First here are some quick tips of information that aren’t immediately obvious when reading the weak online documentation.

——————— Three Tips ———————

Experiment time = performance more than alternatives.

As you might imagine, the more combinations possible from your alternatives, the longer it may take for Optimizer to come to a statistically significant conclusion about anything. This is true in general but there is a bit more to it than that. While there is a dependency on enough traffic allocation to each of your recipes, what really drives experiment time is the difference between how well your best recipe performs vs. your original vs. your worst recipe. An experiment with 144 combinations, which Google does *not* recommend, can actually return results within a couple days so long as your best recipe clearly outperforms your original version of the page. On the flip side, an experiment between only 2 alternatives can cause Optimizer to spit out “28 days remaining” if the conversion difference between those two alternatives is very slim. The lesson? Don’t start with tests of subtle phrasing differences in the copy or a tiny difference in graphic look and feel, brainstorm and test real *alternatives* to your flow or offering first.

Don’t worry about dynamic URLs.

While the Optimizer interface will ask you for an URL for your test page, your test is really of course determined by your javascript placement. If you have dynamic querystring action, or more likely in ecommerce, massive url-rewriting where one one aspx page answers to 30,000 totally different URLs, Optimizer will roll with that just fine. When setting up the experiment, simply use the “upload flat html” option when submitting the test or goal page. Nothing about the experiment is actually tied to any urls other than the preview-your-recipe mode of Optimizer, so just so long as your test page emits the test javascript and your goal emits the goal javascript, you are in business.

Use Javascript in your variations!

Examples of this make up the hacks section that follows. Javascript *is* allowed in variations; you can call functions in the main tested page from your variation or use Javascript in the variation to read DOM elements in the test page.

——————— Two Dynamic page hacks ———————

The following tricks are bits of code you as the developer can implement in your experiment pages that will help with dynamic data in your experiments as well as keeping the experiments themselves as straight-forward as possible so you can let your creative team autonomously plug in alternatives without developer help.

Pull variables from your page into your experiment.

Sometimes you will want to pull out some dynamic data from the page to add to your variation’s content. Maybe you need to grab the current page’s product name and model number to incorporate them into some alternate sales copy. With url rewriting or just highly dynamic pages you can’t very well have this info hard-coded into your variation. One hacky solution I’ve used with success is to backfill the dynamic content into the experiment with Javascript InnerHTML swapping.

In this example, I would set up two input type = “hidden” fields in the page code and set their values to the model number and product name respectively like so (ASP.net):

<input id="HiddenModelNumber" value="<%=ModelNumber%>" type="hidden" />
<input id="HiddenProductName" value="<%==ProductName%>;" type="hidden" />


Next, we implement a little quick Javascript that when called will swap the InnerHTML of all elements with a certain class with the value of our hidden field:


function PopulateInnerHTMLByClass(classNameOfElementToInject, hiddenValueID)
{
if (document.getElementById(hiddenValueID) != null)
{
searchClass = classNameOfElementToInject;
var classElements = new Array();
node = document;
tag = '*';
var els = node.getElementsByTagName(tag);
var elsLen = els.length;
var pattern = new RegExp('(^|s)'+searchClass+'(s|$)');
for (i = 0, j = 0; i < elsLen; i++) {
if ( pattern.test(els[i].className) ) {
classElements[j] = els[i];
els[i].innerHTML = document.getElementById(hiddenValueID).value;
j++;
}
}
}
}


Push variables from your experiment into other parts of your page.

Say you have a long list of 200 items on your page, each with a button that says “Buy” and you want to test how that page would convert if the button instead said “Add to cart”. A good way to accomplish this is create an experiment area that *encloses nothing*. In your test page, code up a Javascript function that replaces the InnerHTML of everything that has a certain class, in this case the class of our button. (see snippet below). Whatever is passed into the function will becomes the new button text on the fly. From there your button-text variations are very easy to administer, simply have each one break into a script block and call your swapper method. Ex swapButtonText(’add to cart’); , swapButtonText(’fork it over’); etc.


function swapButtonText(newInnerHtml) {
searchClass = 'buttonClass';
var classElements = new Array();
node = document;
tag = '*';
var els = node.getElementsByTagName(tag);
var elsLen = els.length;
var pattern = new RegExp('(^|\\s)'+searchClass+'(\\s|$)');
for (i = 0, j = 0; i < elsLen; i++) {
if ( pattern.test(els[i].className) ) {
els[i].innerHTML = newInnerHtml;
j++;}
}
}

——————— The next step, AJAX ———————

Of course the next natural progression of this DOM javascript swapping is to make AJAX calls conditionally fetching custom dynamic information per experiment type. This has a lot of potential but is pretty custom to your given workflow so I’ll just leave it at that for you to mull over.

For more developer thoughts on Google Website Optimizer check out google’s own forum dedicated to this tool.

Have some other good Google Website Optimizer tips and hacks? Post them in the comments!!