Question

Basically, we want to A/B test 2 different page layout headers. There are some structural differences (it’s not just switching out the CSS).

I’ve been able to get this much working: our Zend Framework (server side PHP) looks for a certain boolean variable to decide which HTML file to use as the layout (the original or the variation). This binary switch works beautifully. Each different layout is able to load nicely.

I just haven’t been able to get the 0 or 1 from your GWO utmx(“combination”) function.

When during the page load is the result of that function available? For me, it seems like it always returns 0 regardless of when I call it. Or, when does the __utmx cookie get set? I could simply refresh the page after that is set. Is there a callback for the utmx() function?

I’ve tried multiple strategies, but my most recent plan was this:

In PHP code, check the __utmx cookie to get the assigned variation number. Save that to a custom cookie. Decide which layout to render based on that number. Then, in the javascript, after page load, it simply checks for the presence of the custom cookie, and if it’s absent, it simply refreshes the page immediately (prompting the server-side code to look at the __utmx cookie as described above). That way, on a user’s 2nd visit onward, my custom cookie already exists (containing the value of the variation) and can tell the server-side code which layout to use. On the user’s first visit, right after GWO assigns the 0 or 1 for the variation, I’d use javascript to refresh the page so that my server-side code could read the __utmx cookie.

I haven’t figured out when/how the __utmx cookie gets set though (or when utmx(“combination”) will work).

A/B test with Google Web optimizer; what cookie tells me visitor got A or B hasn’t helped.

Server side code:

    $cookieNameForThisExperiment = 'gwo_variation_header-and-navbar'; //This is for Google Website Optimizer split testing of the header-and-navbar 
    $variation1 = 'variation1';
    if (!isset($_COOKIE[$cookieNameForThisExperiment]) && isset($_COOKIE["__utmx"])) {
        $utmx = explode(':', $_COOKIE["__utmx"]);

        $variation = $utmx[2]; //Careful: this will not work if there are multiple Google experiments running simultaneously and might not even work for testing more than "original" vs 1 "variation".  http://productforums.google.com/forum/#!category-topic/websiteoptimizer/technical-questions/kilJ7lJU2NY
        $variationName = 'original';
        if ($variation == 1) {
            $variationName = $variation1;
        }
        Extrabux_Cookie::setCookie($cookieNameForThisExperiment, $variationName, time() + (60 * 60 * 24 * 30));
    }

    if (isset($_COOKIE[$cookieNameForThisExperiment]) && $_COOKIE[$cookieNameForThisExperiment] == $variation1) {
        $this->_helper->layout()->setLayout('main_new'); //Use new layout only in this variation.
    } //Otherwise, continue using the original layout.

Answer 1

Here’s how the utmx cookie gets set. First your page is loaded from the server. Your page contains the control script. The control script executes synchronously and document.writes a reference to the google hosted siteopt.js resource. When siteopt.js is loaded, parsed and executed, the utmx cookie is set. So any code in your page that is after the control script will see the utmx cookie. However, with the a/b style of testing, there is an additional script which immediately follows the standard control script which calls the utmx function which potentially causes a redirection to happen. This means that any code on the original page which is meant to interrogate the utmx cookie and set your own cookie will not get to executed when an alternate page is chosen for that visitor.

If I understand what you are trying to do properly, here’s what you need to do. On the server, you need to check for your cookie (in your domain of course) for existence and it’s value. Either 0 or 1, indicating which version of the page to serve. If the cookie is set, then serve out the appropriate page, but do not serve out the control script. Only serve the control script if your cookie is not set. So, the first time a visitor sees your page, they will get the original page, with the control script. Now, you have to make sure that the last part of the control script is not part of this control script. It will look like utmx(“URL”, …. You need to make sure this is not present in your control script, otherwise the page will redirect when you don’t want it.

So, in the case where the visitor is there for the first time and you serve the modified control script. After the control script you have an inline script which sets your custom cookie. Note that you should not really need to set your own cookie because your server should be getting the utmx cookie anyways, as long as it is set in the right domain and path. You can interrogate the value of the utmx cookie for the 0/1. In any case, after you interrogate the page chosen for this visitor with utmx(“combination”) and set you cookie, you need to redirect back to your server. Note that the utmx function is delivered as part of the siteopt.js file and will only be present after the control script.

This technique should work fairly well. The only down side is that for visitors chosen to see the original page, they will experience a redirect the first time, while the standard a/b configuration will not need this redirection. However, in another sense, this is a good thing because no matter which version a visitor is given they will all experience a redirect. This removed a time advantage for users who see the original. The other advantage to this technique is that the URL for both the a and the b page is the same, and subsequent page loads have no redirect.