A/B-тестирование Оптимизатора веб-сайтов с использованием серверного кода

Question

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

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

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

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

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

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

Я не выяснил, когда / как будет установлен cookie __utmx (или когда utmx ("комбинация") будет работать).

A / B-тест с Google Web оптимизатором; что 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.

Answer 1

Вот как устанавливается файл cookie utmx. Сначала ваша страница загружается с сервера. Ваша страница содержит скрипт управления. Сценарий управления выполняется синхронно, и document.writs ссылается на размещенный в 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 ("комбинация") и установите свой cookie, вам нужно будет перенаправить обратно на свой сервер. Обратите внимание, что функция utmx поставляется как часть файла siteopt.js и будет присутствовать только после управляющего скрипта.

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