0

基本上，我们想要 A/B 测试 2 个不同的页面布局标题。存在一些结构差异（不仅仅是切换 CSS）。

我已经能够得到这么多的工作：我们的 Zend 框架（服务器端 PHP）查找某个布尔变量来决定使用哪个 HTML 文件作为布局（原始文件或变体）。这个二进制开关工作得很好。每个不同的布局都能够很好地加载。

我只是无法从您的 GWO utmx("combination") 函数中获取 0 或 1。

在页面加载期间，该功能的结果何时可用？对我来说，无论我何时调用它，它似乎总是返回 0。或者，何时设置 __utmx cookie？设置后我可以简单地刷新页面。utmx() 函数有回调吗？

我尝试了多种策略，但我最近的计划是这样的：

在 PHP 代码中，检查 __utmx cookie 以获取分配的变体编号。将其保存到自定义 cookie。根据该数字决定要渲染的布局。然后，在 javascript 中，页面加载后，它只是检查自定义 cookie 是否存在，如果不存在，它会立即刷新页面（提示服务器端代码查看 __utmx cookie，如上所述）。这样，在用户第二次访问时，我的自定义 cookie 已经存在（包含变体的值），并且可以告诉服务器端代码使用哪种布局。在用户第一次访问时，在 GWO 为变体分配 0 或 1 之后，我会使用 javascript 刷新页面，以便我的服务器端代码可以读取 __utmx cookie。

我还没有弄清楚 __utmx cookie 何时/如何设置（或 utmx("combination") 何时起作用）。

使用 Google Web 优化器进行 A/B 测试；什么 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.
4

1 回答 1

2

以下是 utmx cookie 的设置方式。首先，您的页面是从服务器加载的。您的页面包含控制脚本。控制脚本同步执行，并且 document.writes 对 google 托管的 siteopt.js 资源的引用。当 siteopt.js 被加载、解析和执行时，utmx cookie 被设置。因此，控制脚本之后的页面中的任何代码都会看到 utmx cookie。但是，对于 a/b 样式的测试，有一个附加脚本紧跟在标准控制脚本之后，该脚本调用 utmx 函数，这可能会导致重定向发生。这意味着当为该访问者选择备用页面时，原始页面上任何用于询问 utmx cookie 并设置您自己的 cookie 的代码都不会执行。

如果我了解您要正确执行的操作，那么这就是您需要做的。在服务器上，您需要检查您的 cookie（当然在您的域中）是否存在及其价值。0 或 1，指示要提供的页面版本。如果设置了 cookie，则提供适当的页面，但不提供控制脚本。如果您的 cookie 未设置，则仅提供控制脚本。因此，当访问者第一次看到您的页面时，他们将获得带有控制脚本的原始页面。现在，您必须确保控制脚本的最后一部分不是该控制脚本的一部分。它看起来像 utmx("URL", ...。您需要确保它不存在于您的控制脚本中，否则页面会在您不想要它时重定向。

因此，在访问者第一次出现并且您提供修改后的控制脚本的情况下。在控制脚本之后，您有一个用于设置自定义 cookie 的内联脚本。请注意，您实际上不需要设置自己的 cookie，因为您的服务器无论如何都应该获取 utmx cookie，只要它设置在正确的域和路径中。您可以查询 0/1 的 utmx cookie 的值。无论如何，在您使用 utmx("combination") 查询为该访问者选择的页面并设置 cookie 后，您需要重定向回您的服务器。请注意，utmx 函数作为 siteopt.js 文件的一部分提供，并且仅在控制脚本之后出现。

这种技术应该工作得很好。唯一的缺点是，对于选择查看原始页面的访问者，他们第一次会遇到重定向，而标准的 a/b 配置不需要这种重定向。然而，从另一个意义上说，这是一件好事，因为无论访问者使用哪个版本，他们都会体验到重定向。这消除了查看原件的用户的时间优势。这种技术的另一个优点是 a 和 b 页面的 URL 相同，并且后续页面加载没有重定向。

于 2012-06-26T16:33:04.583 回答