Question

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

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

我刚刚无法从你的GWO utmx（“组合”）功能中获得0或1。

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

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

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

我还没弄清楚__utmx cookie何时/如何设置（或者当utmx（“组合”）工作时）。

A/B test with Google Web optimizer; what cookie tells me visitor got A or 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

以下是如何设置utmx cookie。首先从服务器加载页面。您的页面包含控制脚本。控制脚本同步执行并记录文档。写入对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（“组合”）询问为此访问者选择的页面并设置cookie后，您需要重定向回您的服务器。请注意，utmx函数作为siteopt.js文件的一部分提供，并且仅在控制脚本之后出现。

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

使用服务器端代码进行Google网站优化工具A / B测试

1 个答案: