A/B-тестирование Google Website Optimizer с кодом на стороне сервера

По сути, мы хотим провести A/B-тестирование двух разных заголовков макета страницы. Есть некоторые структурные различия (это не просто переключение CSS).

У меня получилось так много работать: наш Zend Framework (серверный PHP) ищет определенную логическую переменную, чтобы решить, какой HTML-файл использовать в качестве макета (оригинал или вариант). Этот двоичный переключатель прекрасно работает. Каждый другой макет может хорошо загружаться.

Я просто не смог получить 0 или 1 из вашей функции GWO utmx("combination").

Когда во время загрузки страницы доступен результат этой функции? Для меня кажется, что он всегда возвращает 0 независимо от того, когда я его вызываю. Или когда устанавливается файл cookie __utmx? Я мог бы просто обновить страницу после того, как это установлено. Есть ли обратный вызов для функции utmx()?

Я пробовал несколько стратегий, но мой последний план был таким:

В коде PHP проверьте файл cookie __utmx, чтобы получить назначенный номер варианта. Сохраните это в пользовательский файл cookie. Решите, какой макет отображать на основе этого числа. Затем в javascript после загрузки страницы он просто проверяет наличие пользовательского файла cookie, и если он отсутствует, он просто немедленно обновляет страницу (предлагая коду на стороне сервера просмотреть файл cookie __utmx, как описано выше). Таким образом, при втором посещении пользователя мой пользовательский файл cookie уже существует (содержащий значение варианта) и может сообщить коду на стороне сервера, какой макет использовать. При первом посещении пользователя, сразу после того, как GWO присвоит варианту 0 или 1, я бы использовал javascript для обновления страницы, чтобы мой код на стороне сервера мог прочитать файл cookie __utmx.

Я не понял, когда/как устанавливается файл cookie __utmx (или когда будет работать utmx("combination")).

A/ B-тест с Google Web Optimizer; какой файл cookie сообщает мне, что посетитель получил A или B, не помог.

Код на стороне сервера:

    $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.

person Ryan    schedule 25.06.2012    source источник
comment
@ Эрик Василик, мне нравится твой блог, но я не смог найти ответ и надеюсь, что ты мне поможешь!   -  person Ryan    schedule 25.06.2012
comment
Теперь, когда вместо этого я использую Google Analytics Content Experiments, у меня есть новый вопрос: stackoverflow.com/questions/11403778/   -  person Ryan    schedule 10.07.2012


Ответы (1)


Вот как устанавливается файл cookie utmx. Сначала ваша страница загружается с сервера. Ваша страница содержит скрипт управления. Сценарий управления выполняется синхронно, и document.write записывает ссылку на размещенный в Google ресурс siteopt.js. Когда siteopt.js загружается, анализируется и выполняется, устанавливается файл cookie utmx. Таким образом, любой код на вашей странице после скрипта управления увидит файл cookie utmx. Однако при тестировании типа a/b существует дополнительный сценарий, который следует сразу за стандартным управляющим сценарием, который вызывает функцию utmx, которая потенциально вызывает перенаправление. Это означает, что любой код на исходной странице, который предназначен для опроса файла cookie utmx и установки вашего собственного файла cookie, не будет выполнен, когда для этого посетителя будет выбрана альтернативная страница.

Если я понимаю, что вы пытаетесь сделать правильно, вот что вам нужно сделать. На сервере вам нужно проверить наличие файла cookie (конечно, в вашем домене) и его значение. Либо 0, либо 1, указывающее, какую версию страницы обслуживать. Если файл cookie установлен, то выводить соответствующую страницу, но не выдавать управляющий сценарий. Служите управляющему сценарию только в том случае, если ваш файл cookie не установлен. Таким образом, когда посетитель впервые увидит вашу страницу, он получит исходную страницу с управляющим скриптом. Теперь вы должны убедиться, что последняя часть сценария управления не является частью этого сценария управления. Это будет выглядеть как utmx("URL", .... Вы должны убедиться, что это не присутствует в вашем сценарии управления, иначе страница будет перенаправляться, когда вы этого не хотите.

Итак, в случае, если посетитель там впервые и вы подаете измененный сценарий управления. После сценария управления у вас есть встроенный сценарий, который устанавливает ваш собственный файл cookie. Обратите внимание, что вам не нужно устанавливать собственный файл cookie, потому что ваш сервер все равно должен получать файл cookie utmx, если он установлен в правильном домене и пути. Вы можете запросить значение файла cookie utmx для файла 0/1. В любом случае, после того, как вы опросите страницу, выбранную для этого посетителя, с помощью utmx("combination") и установите cookie, вам необходимо перенаправить обратно на ваш сервер. Обратите внимание, что функция utmx поставляется как часть файла siteopt.js и будет присутствовать только после управляющего скрипта.

Эта техника должна работать довольно хорошо. Единственным недостатком является то, что для посетителей, выбранных для просмотра исходной страницы, будет выполнено перенаправление в первый раз, в то время как при стандартной конфигурации a/b это перенаправление не потребуется. Однако, с другой стороны, это хорошо, потому что независимо от того, какая версия предоставляется посетителю, все они будут перенаправлены. Это устранило преимущество во времени для пользователей, которые видят оригинал. Другим преимуществом этого метода является то, что URL-адрес для страниц a и b одинаков, а последующие загрузки страниц не имеют переадресации.

person Eric Vasilik    schedule 26.06.2012