在互联网公司的业务发展过程中，用户增长是永恒的主题，因为没有增长也就没有发展，所以在业务发展的早期产品迭代速度往往是越快越好，总之一句话：“怎么快怎么来”，至于系统建设得是否可以满足未来几年的扩展什么的，往往在用户增长面前都会显得很扯淡，因为慢了可能就死掉了。
而当业务发展到一定阶段后，野蛮生长的红利逐渐消退，用户增长空间在可见策略下变得不那么明显的情况下，如何合理地规划产品迭代策略就显得尤为重要了，而具体如何判断产品策略是否有效，往往就需要数据进行判断，其结果决定了该产品或策略的生命力以及与之配套的各类资源的调配，毕竟大部分公司是不会愿意将资源浪费在无效的产品和策略上的。那么，通过什么样的工具或手段才能确保数据驱动策略的有效落地和实施呢？
目前硅谷的很多公司都在通过ABTest及建设与之相适配的实验基础设施平台来实现这样的目标，而国内有条件的互联网公司也在逐步进行尝试。小码农目前所在的公司也在进行这样的尝试，作为比较前沿的一种思路与实践，虽然目前在国内的普及程度还并不是很高，但是作者相信随着国内互联网ToC流量红利的消退，这种工具会被越来越多的公司重视起来。本文将从基础理论及系统设计的角度与大家进行一些初步的探讨。
简单来说，ABtest就是当我们在A、B两个方案之间犹豫不决的时候，直接把两个方案测试一把，看看哪个效果好，把测试结果作为参考依据。
因为是抽样测试，所以需要一些统计学方法，估计是否测试能代表整体情况，因此要引用统计学方法。
ABtest本质上是一个：两总体假设检验问题，要检验A、B两个版本是一样，还是有所区别。和之前介绍的单总体假设检验一样，两总体假设检验，也分步骤：
第一步：明确要检验的A、B两个对象
第二步：明确要检验的指标，是平均值，还是比例
第三步：根据检验目的，给出原假设/备选假设
第四步：根据要检验的指标，选择检验统计量（是不是头都看大了，其实没关系，大部分统计软件，包括excel，都有提供两样本均值的t检验，直接用即可）。
第五步：给定显著性水平，计算统计量，得出结果：支持原假设还是推翻原假设
在倡导数据驱动的公司中，会通过大量的数据分析来了解产品业务的进展以及做相关的决定。一个较大的产品或者策略改进上线以后，需要进行一段时间的abtest，以决定这个产品或者策略改进是否符合预期，是否要扩大流量，或者需要中止实验。
产品迭代过程中是否要用abtest，长期以来是存在各种反对声音的。以下举2个不恰当的反对理由，并说明为何不恰当。
1. 在我接触的一些rd团队leader中，流行着这样一种说法：好的PM不用做abtest，做abtest证明PM没有产品sense。首先，很长时期以来互联网行业的极速膨胀导致了各种职位招聘门槛降低，PM也不例外。有不少PM会产出各种粗制滥造的产品需求。即便那些超级有产品sense的神级PM，他们也不是所有需求都是毫无瑕疵的。某著名“他老人家”在世的时候大家还觉得“他老人家”不会犯错误呢。关于这个问题，咱们再聊个八卦J
中国的互联网公司抄袭美国公司早已司空见惯。早年的xx网，据说实现了对facebook的像素级抄袭，从而还闹出过一个笑话。2012年的时候，facebook进行了一次大改版，从下图改到了下下图。
当然，facebook是极其数据驱动的公司，改版不会随便全流量上线，而是进行了很慎重的实验。改版后的界面，最终只开放了12%流量。虽然这个项目是公司的一位VP在强力推动，但是因为各项数据指标表现不佳，最终还是被扎克伯格和管理团队叫停，下线了。
而在中国，xx网以超强的执行力把facebook的这次失败的改版copy过来了。如下图：
据说，xx网里面过产品需求的是这样的：
Manager：为什么要做功能A？
PM：因为本土用户如何 blablabla，这个功能如何好blabla，如何能更好满足用户需求blabla
Manager：那FB有没有这个功能？
PM：貌似木有。
Manager：那这个功能开发先暂停。你再回去多想想。另外你要多花脑筋想想为什么FB不这么做
PM：。。。
Manager：下一个。功能B为什么要上？
PM2：因为这个功能Facebook上有了，上个月刚出来的。
Manager：好的，那上！
PM2：Yes！:-D
希望看了这个八卦的同学，会努力避免成为xx网的Manager :)
2. 另外一个反对意见是，我不需要用abtest，我可以用数据的变化趋势来判断。那么，我们来看看，在没有任何操作的情况下，某产品某个展位某个指标的变化趋势。
我经历过不少公司和产品，可以说，大部分产品的数据指标都存在这样的情况，在没有采取任何动作的情况下，变化就很大，普通的策略迭代的短期效果很容易淹没在这种变化中，无法判断真实效果。还有人说，我是做品类A的，可以和品类B的数据进行对比，看看相对品类B，品类A的数据有没有变好。表面上好像挺有道理，不幸的是，这里面还是存在很多问题：比如，品类B的用户群体和品类A是一样的吗？品类B在同一个时间点有没有做什么操作（技术上或者运营上的），导致他的数据变化趋势本来就和品类A不一样呢？
当然，也不是说，什么时候都必须abtest。有些产品还在早期，用户量太小，是没法通过abtest得出靠谱结论的；有些产品体验的改进是可以通过线下用户调研得到答案的；有些改变，有决策者的特殊意图在里面，并不以某个指标的提升作为出发点，那也应该另当别论。
下面开始介绍abtest的一些基本原理。
在大量运行abtest实验的公司，为了让各个团队，各个模块的abtest有序进行，需要设计良好的abtest实验架构。
下面以有一定代表性的一种简化的场景介绍一个abtest框架。下图所示，是一个客户端列表页从前端到后端的极其简化版的流程图。括号中表示进行abtest时候，每个层次主要关注的点。
在谷歌的那篇文章《Overlapping Experiment Infrastructure: More, Better,Faster Experimentation》中，介绍了一个很复杂的abtest框架。以下我们描述一个简化的版本。看这个图的时候，可以想象流量从上往下流动，左侧的流量不分层，它可以同时测试产品展示交互设计，产品功能点，策略算法等层次的参数组合。而右侧的流量会经过不同层次的实验。上方的是展示交互层实验，中间是排序层实验，下方是召回层实验。层与层之间，可以有几种不同的关系。多数实验会使用右侧的多层实验框架，跨层次的实验发生得比较少。
原文链接: https://www.yukx.com/abtest/article/details/2326.html 优科学习网什么是ABtest？
