二、（数据）分析壁垒
2.1、两个（或更多）版本的数据怎么收集/整理？
单单区分不同版本页面本身的数据非常简单，但如何对最终达成的转化根据不同入口及流经页面进行归因，进而分析相关参测版本页面（或元素）的表现，这就是一件扰人的事儿。而不同的归因方式甚至可能牵扯到几个部门的利益：投放渠道评价、入口资源的争夺，甚至跟某些KPI遥相呼应。那这个标准谁定，怎么定，本身就是一场战争。
2.2、数字（或比例）越大，就一定说明表现越好吗？
看 A/B test 反馈数据的人，并不全是专职的数据分析师，甚至包括一小部分经验略浅的数据分析师，都非常容易想当然地跳进这个误区。上面我说过，A/B test 绝非神物，但更可怕的是它被误读、被曲解，再被神化。非常遗憾的是，基于各种需要、背景或局限，这样的例子多如恒河沙数。
2.3、访问（者）为什么没有均分，那数据是不是不准（不能用）了？
样本量、分配规则、数据监测或萃取方式（条件）……很多时候，由于各种各样的原因，我们会发现真实数据并不如预期般在各版本中均摊。“几个版本数据差距好大啊，怎么办，能信吗？” 如何校准，是否需要排错，有没有相应的调整策略，数据的信效度衡量……这些也并不是所有拿到报表的人都能 Hold 住的。
三、技术壁垒
3.1、开什么玩笑，我们也不是小公司，会存在技术问题？
抱歉，我并没有任何玩笑或者不敬的意思，事实上不论公司的规模或真实技术实力如何，会中这一枪的并非只有菜鸟。任何公司的资源都是有限的，任何一份投入都会耗费相应的成本，虽然架构 A/B test 所需的技术事实上相当简单，但真正能扑上去用心做好的公司，都可谓英雄。流量分配规则、跳转/切换方式（各种跳转 URL 的方式，或同一 URL 下动态切换模块）、是否记录（如 Cookie）单个用户首次显示状态……这些都会影响到测试效果及最终得到的结果。
在这里我想举个栗子，Google Analytics 从很早之前就提供了现成的 A/B test 工具，只需在原始版页面顶部嵌入一段现成提供的代码，并在这个工具中设定 A、B 版页面路径，即可完成设置开始测试。但如此便利的东西，无法正确操作的公司依然比比皆是。实施的人不懂技术，技术嫌麻烦或担心对服务器有影响或对安全有隐患或不屑于吃别人嚼过的馍，事情又已经摊下来了，等排期要一个月，怎么办？要不硬着头皮先自己捣鼓个？对了错了天知道，反正先交差吧！
3.2、数据收集技术
忽然发现我这个答案真是得罪一批又一批啊……哇咧个喵哈哈哈。这不，又说到这个一梭子扫倒一大片的了。现成的第三方工具不好用或者不会用或者总感觉数据被别人掌握了心里横竖就是不爽，自己开发又费时费力还不得要领。现在某些公司（尤其是某些背靠或依附国字头、垄断者的）出于数据机密性，而不得不自己开发数据分析平台，但……好吧为了略微少得罪几个人，我还是阉了吧。
其实就整个数据分析链条来说，“数据收集”相对应该算是最基本、最先锋的环节。（线上）常见的数据来源主要就这么几种：Page Tagging / Server Log / Third Party，每种来源，或者说每种收集方法，均有其利弊，以目前人类的技术来说都达不到真正的“精准”。如何部署，如何取长补短采阳补阴，如何跨平台甚至跨线上线下，不同监测平台如何统一接口削校数据……
3.3、数据清洗（细分、过滤、归因、算法……）技术
到数据清洗这儿，已经没什么可深聊的了。举个栗子吧：了解WA工具的朋友可以自行比对一下国内、外较成名的几款工具，在数据细分系统上的悬殊差距便知。
四、“落地”的层层障碍
任何数据、任何策划只有落到执行上，才可能有意义。
4.1、信
a、相信——to ‘B’ or not to ‘B’, it’s a single answer
b、威信——合作 & 内耗
c、迷信——有时我们需要信仰，而信仰往往需要一件迷信的外衣。扒与不扒，您看着办
4.2、省
a、自省——挤痘痘会痛，有时还会很痛，敢于直面疤痕的痘主儿都是英雄
b、省悟——读书百遍，其义自现；有则改之，无则加勉
4.3、行
a、action
b、持续永动——是的，这不是物理题，但你确实需要捣鼓一台永动机
4.4、辛
a、抉择——割肉是痛的，尤其是割掉一块看起来如此之好的肉
b、实施——攻城狮们最了解
c、秋处——胡萝卜与棒子
