背景回顾
5月24日晚，DTalk邀请到了DTalk联合创办人王晔老师，他是吆喝科技的CEO，清华大学本科，耶鲁大学博士，曾在Google总部广告质量部门负责产品优化。进行了一次关于《吆喝科技王晔：A/B测试最佳实践》的微信群线上主题分享。

1、AB测试是什么？

A/B测试是一种科学的试验方法，可以利用少量样本对决策进行测试，从而在决策被广泛执行之前准确预测其实施效果。

A/B测试在科学试验，医疗健康，农业，广告等领域都有重要应用。严格的A/B试验的实施比较复杂，门槛和成本比较高，往往只能用在很关键的决策中。

互联网行业因为用户主要在线上，试验实施和样本数据采集很方便，可以大量进行A/B测试，大大提高了决策的科学性和有效性。

Google和Amazon最早建设了完善的A/B测试试验系统，实现了超越传统行业100倍以上的试验能力，业务发展速度非常快。

2、A/B测试是为解决什么问题而诞生的？

科学家在探索事物的因果关系过程中，发现大部分分析手段是得不出确切的“因果联系”的。用西方医学举例，18世纪的时候还有很多医生认为直肠是决定身体健康最关键的器官，理由是很多重病患者的直肠都有问题。但是这个理由并不充分，会不会是其他原因导致了疾病，然后疾病影响了患者的直肠呢？会不会有其他更加影响健康的因素呢？

因为无法知道两个事情之间的因果关系，我们就没法“预测决策的效果”。看一个NBA的例子，数据显示科比得分越多的比赛，湖人队输球比率越高。那么科比是湖人队的毒瘤么？会不会是湖人队越困难的比赛越需要科比挺身而出多多得分呢？如果教练把科比放在板凳上，湖人队就会提高胜率么？这个问题完全没法回答。

这里再给大家两个好玩的数据分析例子：

随着美国政府在宇宙和科技上的开支越来越大，各种自杀者的数量也越来越多；

随着人均黄油消耗的减少，缅因州的离婚率也显著下降了。

这种情况一直困扰着科学家，政府领导，和企业老板。直到后来科学家发现，如果我们把患者分成对照组和试验组，给试验组的患者服用药物，给对照组的患者服用安慰剂，然后再对比两组患者的治疗效果，得出统计学意义上的结果，就能准确的分析出药物和疗效之间的因果联系。通过这种A/B测试，我们可以知道药物是否比安慰剂更有疗效，以及有“多大”的疗效。如果我们把这个药给全世界所有的患者使用，会增加治愈率0.1%？还是1%？还是10%？还是100%？我们可以估计出这个疗效的范围。

如果没有A/B测试，我们是无法得出这种因果联系和预测性结论的。A/B测试几乎是我们唯一可以使用的方法。

比较麻烦的是一个A/B测试的实施涉及到试验设计，样本选取，控制实施，数据收集，统计分析，试验首尾，总结结论等等各种工作，流程复杂，门槛高，成本高，所以只能用在关键决策上。

不过现在有了吆喝科技AppAdhoc（或者硅谷的Optimizely）这样的A/B测试试验系统，可以帮助互联网产品运营几乎全自动的实施A/B测试，而且可以大量并行的试验，做到精细化的运营决策，这就让A/B测试的应用场景大增，产生的商业价值也大增。

3、A/B测试的准确定义是什么？怎样正确的做A/B测试？

对于A/B测试最常见的误解就是认为A/B测试就是对两个版本的直观对比。把用户分流一下，不同的用户看到不同的版本，然后对比一下看看哪个的转化更多。

这种对比测试其实我们经常会去尝试，但问题是得出的结论非常模糊，今天这个版本的数高一些，明天那个版本的数好看一些，最后92 vs 98，到底是A比B好，还是B比A好，还是两者没什么差别？由于误差大，分流不精确，干扰因素多，试验结果通常意义不大。除非A和B版本里有一个夸张的爆款（数据高出几倍几十倍），否则很难给我们后续的业务决策提供什么有价值的参考。

当然，有些对比测试做的更简单，比如先把A跑两天，再把B跑两天，这种误差就更大了，前两天下雨了，导致A组不好，其实冤枉了做A方案的产品经理。

这是Airbnb的创始人给大家的一张图。这是Airbnb核心业务指标（Nights booked）的变化情况，三个月跌宕起伏的增长起来。

中间一个月（红色曲线）发生了什么？Airbnb上线了一个功能，然后一个月后下线了。那么这个功能对Airbnb的业务起到了什么作用呢？不知道。可能是正向影响，但是没有总结经验奖励团队，丢失了继续增长的机会；可能是负向影响，但是因为其他事情做的好问题被掩盖了，白白背了一个月损失；也可能是没有影响，项目白干。所以Airbnb要求产品的任何功能，运营的任何想法，必须先跑小流量A/B测试，给出确定的结论，只有成功的项目才会全面上线。

真正的A/B测试是分离式组间试验，通过均匀采集试验组和对照组的样本，排除其他因素的干扰，对“A和B两个版本是否影响了优化指标”进行假设检验，并且估计出“影响的范围”。

如果要判断我们做的是不是A/B测试，只需要看看试验结果是否能“复现”即可。我们这次试验得出的结论，如果隔几天重新再做一遍这个试验，结论一样么？

实践之中，最好使用完善的试验系统来实施线上的A/B测试，这里必须推荐AppAdhoc A/B Testing，使用成本低，而且有专家咨询服务，避免失误。如果需要线下的精确试验，最好请专业团队来帮助实施，有一定成本，我知道新加坡政府经常雇佣新加坡国立大学的商学院团队来做公共政策的A/B测试，还有很多专业公司给制药厂提供临床3期A/B测试服务。

4、怎么做A/B测试才能实现业务提升？

那么回到实际工作中，我们互联网产品运营怎么用A/B测试？怎么做A/B测试才能实现业务提升？

互联网产品运营通常都有重要的业务优化指标，或者说可以量化的KPI，比如教育行业的在线招生转化率，线上销量，线索数量，App留存率，商品复购率，用户使用时长，用户转发量等等。

针对这些优化指标（比如用户活跃行为数量），我们会提出优化的试验想法（比如增加性格评测功能用户会喜爱），并且分析总结成科学的假设（增加性格评测，用户活跃行为数量会增加20%），再设计和运行一个或多个A/B测试进行假设检验（用10%的流量来试验，对比有性格评测功能的用户组vs没有性格评测功能的用户组，检查有性格评测功能的用户组的用户活跃行为数量是否增加）。

我们看一个实际的电商行业的案例。这是微软商城的一个试验案例，用AppAdhoc　A/B Testing实施的A/B测试。

微软正在大力推广Surface，希望线上销量能够提升。在微软商城Surface的商品详情页，优化指标是加入购物车的转化率。大家注意到这个商品详情页里有三块辅助的内容：售价栏，详情栏，促销栏。那么这三个版块的排版会不会影响用户加入购物车的行动呢？比如，强调促销栏会不会有助于用户更愿意加入购物车？这个想法是个很有意思的假设，试验实施也很简单，简单调整一下版块的排版就可以做出A, B, C三个试验版本。试验流量均匀分配，对照组，A, B, C四个版本各25%的流量。那么试验结果呢？试验版本A提升60%［+33%，+87%］（95%置信区间）。这个结果说明试验想法是有道理的，排版会影响用户的下单行为，值得继续优化。当然，我们可以讲A版本全面上线，想受到至少33%的转化率提升。

像这样的优化试验，微软每天都在做，所以可以精细化的提升自己的线上业务指标。

那么是不是每个试验都有效果呢？很遗憾，历史经验告诉我们，我们对用户需求的理解是很不足的，大量的试验都和我们的预期不一样。

前Amazon和现Microsoft的A/B测试负责人Rony Kohavi试验经验非常丰富，他的结论是60-90%的想法做A/B测试后都被验证失败了。

有趣的是，在做A/B测试之前，我们产品经理和运营高手都是自信满满，但是做了一些A/B测试之后开始逐渐谦卑，不再贸然说自己的想法好。再经过一段时间的试验，我们有可能过分悲观的反思“我活在世上有什么意义”。

其实盲目自大和盲目消极都不能带来成功。还是有相当比例的试验会大获成功，而且有些成功的试验还是意料之外的，这些意外成功都是我们继续加大探索步伐最终走向爆款成功的关键。

做A/B测试能够提升业务的最重要方法就是“大量试验”，“高频试验”，量化我们的经验，增加试错的速度，加快对用户真实需求的学习。

Twitter最初只能人肉做A/B测试，所以每个月就跑2个试验，增长速度慢；后来有了系统性的试验能力，可以每个月跑40个试验了，增长速度就翻了倍。

增长黑客常常跟大家说自己成功的绝招，仿佛一招就能力挽狂澜；其实真正的成功之路，是快速的试100招，从中找到对用户有用的10招，然后从这10招去进一步探索研究，最终形成一套秘技，实现快速的增长。然后可以和人分享你发现的最好玩的一招。

记住，做大量试验，找到用户爱你的点，然后加大投入获取爆发。

分析了一百款现象级App关键迭代，梳理出两条用户增长逻辑

这个文章大家现在不用看，以后可以看。里面说到这些看似“一夜爆发”的产品是如何不断迭代试验找到爆发的。

A/B测试可以应用在很多业务环节，比如对于增长黑客的流量漏斗模型来说，流量入口，用户活跃和留存，营收转化这几个环节都可以大量做试验来提升转化率。

针对营销拉新场景，用户的初次体验（比如广告着陆页和产品首页）特别值得多做试验优化。针对用户活跃和留存，产品功能的用户体验需要持续的试验优化，各种运营活动也应该多做试验积累经验。

当然，在关系到业务核心支撑的重大决策上更加需要做A/B测试，比如金融行业的风控模型的修改，运营商套餐具体的档位和定价，推荐算法的迭代等等，这些大项目都应该使用A/B测试来精确实施。

对大部分试验场景来说，实施的过程可以用这个图来解析：

使用AppAdhoc这样的试验系统的情况下，大部分过程都是全自动的，需要我们人工操作的事情主要包括需求分析，编辑创建试验版本，集成调试，分配试验流量，实时追踪数据，和决策。

5、怎样形成高频A/B测试的试验文化？

要想实现大量试验，高频试验，不能只是一个或者几个业务人员单枪匹马疯狂的做试验。事实上有了好工具之后做试验不难，难点在于好的试验想法。要有大量的试验想法，就需要团队尽可能的全员参与创新。

不过，我们会发现不是团队里的所有人都喜欢A/B测试。有些岗位是没有业务KPI的，比如对很多研发工程师来说，代码质量，bug-free，deadline是技术大牛追求的事情。如果每一个技术改进都需要先做A/B测试才能最终上线，虽然降低了贸然上线的风险，但是会拖延进度，减缓上线的成就感。何况技术改进并不一定能提升业务指标，这就给上线带来了额外的“考验”。

还有一些业务人员，要么过于自信相信自己的直觉，要么不愿意自己的工作被准确衡量，所以不喜欢A/B测试。这种情况并不是不存在的。

我们不是要黑“码农”和“独裁者”，事实上他们有充分的理由不喜欢A/B测试，但是事实上A/B测试也许能够帮助到他们，那么也许随着更多试验的进行，他们的看法也会渐渐变化。

我在硅谷和华尔街看到的情况是，Google, Amazon, Airbnb，Capital One, Geico这些企业里人人都想做A/B测试，人人都想提升公司的KPI。这就是企业里试验文化。

Google上市以后到2007年建设了完善的A/B测试试验系统，之后试验越做越高频。

我个人的看法是，试验文化鼓励创新，让每个人都有更多的机会，可以将自己的想法付诸行动。我想做一个产品功能，我有我的理由，但是其他人可能会看到我想法的不足，在团队里一定会有异议。如果没有A/B测试，这样的创新项目很难落地。有了A/B测试，我就可以申请跑一个1%流量的试验，机会就大多了。有机会行动，就有机会创造价值，任何一点为业务增长的贡献都可以被A/B测试准确衡量，这就可以鼓励我再做更多的试验来继续向上前进，士气节节高涨。

另一方面，试验文化缓解领导的压力，领导不需要背负所有决策的重担，可以允许大家积极尝试，让试验数据来帮助最终的决策。从同事的角度来看，领导一发话，创新就死掉了，大家就没有了热情。领导不轻易说是／否，反而给大家更多发挥自我价值的舞台。

所以，要想建设试验文化，就要积极鼓励团队从小的试验小的项目做起，看到自己的工作价值（我的想法帮助公司的营收提升了1%!）。要减少凡事直接请示领导，而是拿着试验数据去找领导。大家开会，可以围绕着试验数据来讨论。

领导不是只考核团队的KPI，还要看KPI的增长情况，更要看试验数量试验频率的情况。这样才能更好的让大家朝着正确的方向努力。

具有试验文化的企业都是各行业最优秀的企业，他们都从大量A/B测试试验中找到了很好的增长机会。

这里有一些我们吆喝科技客户的试验案例，大家可以看看他们是怎么做的：

http://www.appadhoc.com/blog/category/instance/

Q&A : 根据留言区的提问，选出几位提问的朋友，有针对性的分享。

幸运观众1：太空可乐
问题1. 如果选择服务端分配试验流量，如何处理网络延时导致变量无法及时展示问题？

王晔老师的回答：这是个典型的问题。这个问题其实涉及两种业务场景：

我们针对用户的老用户的留存、体验做的试验。那么这种实验，一般来说都可以接受异步的方式。当你分配流量进行了这个样本的选取把实验配置推送到前端之后，客户端的可以其实不用对这个实验的配置做处理或者所谓的这个响应展示。可以等用户下一次再打开app的时候再处理。用户的这个行为数据，只有他进入实验之后才会获取的话。他并不会影响你的实验结果，这是可以很好处理。简单来说：老用户试验：可以选择异步请求服务端（后端），用户真正到达试验场景后再请求试验信息，这样用户进入实验后控制变量的参数是直接从客户端缓存读取，不会出现延时。

另一个实验场景呢，其实必须用同步的实验，如营销页面，比如投放广告的时候用户点了广告进入了我们的这个营销页或者是广告着陆页。可能一个用户一辈子都只看到一次，他点开这个广告以后就再也不会点。对于这个页面要做实验，要对比不同版本，它就需要我们的后端要尽可能快的把实验配置、实验分流做好。然后前端尽可能快的显示出来。这是这是一个对技术上的一个更高的考验。然后我们的系统能够控制它正确的。进入这一个或者这几个实验正确的去渲染还有用户体验逻辑。然后获取相应的数据。简单来说新用户试验：如营销活动的落地页，这种情况如果对新用户的行为数据要把握比较准确的话，可以考虑直接请求，也就是客户端直接向测试后端请求同时完成流量划分及试验参数获取。

问题2. 如果选择了客户端在初始化时请求试验参数，对于页面层级比较深的页面，如何处理流量浪费问题？

王晔老师的回答：页面层级比较深，我理解是，就是比如说我一共有一百万用户。但是，这一百万用户可能只有一万个用户他会去进入付款页面，那么所以付款页面实际上只有一万个用户可以参与实验。在这种情况下。应该不叫流量浪费，因为你实实在在的其实只有一万个用户参与了这个实验。那么在你的这个最终的这个统计里面应该只有这一万个样本。

问题3. 以及因页面层级深转化用户不均匀产生系统性偏差的问题？

王晔老师的回答：第三个问题和第二个问题，其实是这个一脉相承的。如果我们只有最后的页面只有这么多样本，那我们就要尽可能保证这些样本他能够被均匀地分配。如果最后付款成功的用户只有一千个。那么你最多有一千个样本，那么你得出来的结论可能就会更加的模糊。但是即便是模糊的也必须是准确的，比如他能给你精确的百分之九十五置信区间，那么它的置信区间你可以理解为一种误差。误差是准确的就行，这是我们不可避免的一个问题。

太空可乐的观点：

明白了，核心问题是对“真正”触达试验环境才请求试验参数。我当时确认了一下答案。『核心问题是用户真正到达试验场景后再请求试验信息』，这就延伸出异步请求和同步请求，两种场景对开发同学其实是完全不同的需求。这个需要在搭建试验甚至是有了想做abtest之前就应该考虑到的。二者各有利弊，需要权衡。

目前实际中选择异步。没有对真正触达试验场景做要求。是APP在初始化的时候就请求后端给参数，然后加入了一个回调机制，也就是当缓存里面取到了参数，通知前端调取参数，进行正确试验环境的渲染，由于APP有开机动画，开机动画基本上消化了这个请求-调取的过程。所以新用户异步请求也能正确进入试验环境。

但是依旧带来了个问题，就是APP初始化就必须去请求（因为只有开机动画能缓冲延时）。也就带来了我说的试验流量的问题。每一个启动APP的用户我都认为是试验用户，但是实际触达真实试验环境的用户，并没有这么多。直接请求还有别的问题，内容下发的服务端和流量划分的服务端耦合度太高，会导致更多问题，不光是速度。这是服务端划分流量带来的不可调和的问题。如果客户端预先已经做好流量划分，就没有这种问题了，但是埋点工作会非常多，而且无法对工具进行平台化，也就是具体的产品业务线自己在客户端代码里面做好流量划分。

幸运观众2：张章-策略PM
问题1、在生产用户标签时，比如算法挖掘出来的性别标签，应用在精准营销，如何通过线上AB测，来测试标签的准确率，以及标签的应用效果？

王晔老师的回答：这个问题其实是一个非常有意思的一个实验场景。当我们对用户有了一定的画像或者标签的时候。怎么才能通过ab测试或者一些方法来验证这个标签的准确性。

我觉得针对这个问题，我可能有两个点可以分享，一个对于标签是否准确这件事情，不一定是用完全用ab测试来验证。他可能需要我们标注人员或者是专业的专家来进行一些样本的抽取，检查这个标签是否正确。我们在建模的时候，所做的一些工作，他又本身就有自己的准确率，一类错误二类错误的，他有这些相应的这些指标可以去衡量。

从另外一个角度讲的这个标签，关于用户的作为、用户的一些预测相关的。比如这个标签说用户会喜欢什么东西或者我们应该给他推送什么东西。而如果这些标签具备这样的这个特点。那么他其实在指导我们的行动。这些行动是不是有效呢，他也是一个假设，我们确实可以去做AB测试、假设检验。我们可以根据这个标签去采取不同的行动，千人千面的行动。然后来对比没有用这个标签，没有千人千面的这个版本效果，是不是我们预期的一样。

如果因为这种用户画像和标签对我们算法、逻辑好带来了实际的价值。并且我们能够比较精确地衡量价值是多少，比如提升了我们多少点击，提升了我们多少业务量。那我们就可以去评价这套标签的价值是多少。

张章-策略PM的观点：

对于有测试集和训练集的标签，确实能直接获取到准确率，不需要通过ABtest。用户偏好类、预测类标签，通过ABtest能够得到效果提升的指标比如点击率和转化率，但是准确率的数值，我觉得仍然无法获得，因为没法用点击率和转化率来代替准确率；

标签的应用效果影响到业务指标，看标签应用之后业务指标的提升情况；

问题2、AB测试有哪些局限性？对流量是否有数量上的限制，比如用户量必须到了一定量才能适合ab测，这个量怎么评估？

王晔老师的回答：

AB测试有哪些局限性，其实局限性太多了，比如有些场景是做不了AB测试的。那比如说流量，做这个火箭发射的，可能一年也发射不了几根火箭，所以你没有办法通过足够多的样本去推出什么结论。另外是线下的商品，比如牙膏做成什么样的形状的这个销量更好，这个做起来就会非常的困难。

如果只说流量对AB测试的限制，我们的这个经验是这样的，如果做线上业务的正常的转化率来有日活一千的流量。你就值得去做一些优化

如果日活有一万的流量，无论是你是营销场景，还是你买来的流量做做转化。还是留存的用户。做一次AB测试是对你帮助就非常大。

张章-策略PM观点：

其实之前我一直认为，ABtest至少日活有上十万，才会有测试的意义，看来这一点，我之前就理解的有偏差。

幸运观众3：安娜-IT-网站运维
问题1：如何评估一个测试是否成功？ 一个网站同时最多进行几个测试？ 是否一个测试只能测试一点变化（如一个feature, button etc），比如两个设计和排版不同的促销落地页面是否可以测试？ 需要注意什么？

王晔老师的回答：

如何评估一个测试，我猜想是你说的是这个业务场景的AB测试他是不是成功。其实我觉得任何一个AB测试，无论什么样的结果，都应该是成功的。

如果这个实验结果说明你的想法对用户没有什么影响，其实他也告诉给了你一个很好的结论，就这条路可能行不通，你该换换思路；如果这个结论是说你的想法跟你的预期截然相反，你本来希望让用户多下单，结果最后用户下单量反而减少了。那么他可能让你反思一下。当然也要去你可以去反思，是不是我技术实现上有bug，还是我的整体的这个用户的需求理解有问题。当然最好的情况是你的试验的结果跟你的假设完全吻合，试验证明了这一点，这对你是一个莫大的激励。

从这个角度来看的话呢，我觉得实验结果，无论是怎么样的，他都是很很成功的。因为他对你来说都有一个非常大价值，你从中学到了很宝贵的东西。从另外一个意义上可以说什么样的实验更成功什么样试验？我觉得更成功实验投入产出比更高，比如想法需要两个月才能去实现才能落地。我花了两个月，然后才开始做实验过了两个星期才收集到数据。那么这就不如可能你有一个简单的想法，只需要这个几个小时就可以实现。产生实验，结果带来的帮助更大。

所以从一定意义角度来讲，我们其实更鼓励大家从小的点、更低成本的做实验的角度去做事情。有些大的试验，比如我们用户的画像、AI的模型、风控算法的改进，那肯定都是很大的项目，这种决定性的项目更应该去做AB测试。但是他可能在我们做之前对他的产出预期就有很多的学习分析，更加有可能得到我们预期中的结果。

问题2是否一个测试只能测试一点变化（如一个feature, button etc）？

王晔老师的回答：是否一个测试只能测试一点变化呢，并不是这样，当然了，一点变化这种实验的话是我们非常鼓励的，好处就在于我们刚才说的投入产出比。我知道了很多例子，都是你这个你可能只是简简单单的花了这个半天时间做了一个非常简单的一个元素的变化。最后带来个百分之十、百分之一百的这种增长这种情况屡见不鲜，所以只做一个点的测试呢，有助于我们有更高的投入产出比同时的话呢，也能帮助我们更好地理解用户，我们可以知道仅仅因为。一个改变。用户就能有什么样的响应，这样我们可能能够得出一些更确定性的因果性的结论。

但是并不是我们只希望或者只期待做这种单变量一点点改变的实验。我们很多时候是会做两个设计和排版都不一样的，比如广告落地页，进行测试。这是非常常见的，因为很正常，因为我们在做广告营销的时候还是一个创意主导的事情。因为你对用户的理解千变万化，很多时候你的这个想法，，和那个想法完全不一样，就拿互联网金融产品来说，你是卖黄金产品你到底想在落地里根说这个东西回款快，还是收益高，还是低风险的。其实这三个不完全不同的这个创意点就可能是三个完全不同的设计，那么他们能带来转化上的不同吗，完全有可能。

这种实验，你可以理解为是某种意义上的多变量的实验。这个实验变量的值变化的特别大的那种实验。其实呢，没有特别需要注意的。只是你可能使用的手段不一样，比如你要用我们工具的话，我们有个专门的多链接实验的一个工具，可以让你非常方便的实施这样的试验。

安娜-IT-网站运维的观点：我的问题是关于如何衡量测试是否成功，以及是否可以同时测试多个网站元素。

关于第一个问题，老师的回答很有趣，就是所有的测试都可以看作是成功的。即便预想没有得到验证，也可以得出结论，当做反向学习的example。

第二个问题，老师的解答是单一元素的测试和多元素的测试都是可行的，具体回答可分为两个部分。首先单一元素的测试是被鼓励的，并且往往是投入产出比相对较高的测试：既可以降低测试设计成本，执行起来比较方便。其次多元素测试也是经常会涉及到的，特别是对于促销活动页面。虽然从设计到执行成本比较高，但对于整体客户体验的测试对比会更直接。

我在一个跨过企业工作，属于传统行业，执行一次测试从idea到最后结果分析起码要等2-3个月。昨天听说很多公司都是同时进行几十个测试，觉得挺震惊的。所以总结一下就是对AB测试领域有更基础的了解，强化了很多基础理论和理念。

幸运观众4：杨林_产品 前边做了个文案的实验，但是最后结论差的特别大有百分之九百的差距。当然我们产品本身数据量比较小，这个我还继续实验还是直接上？

王晔老师的回答：一个改文案的实验还带来了百分之九百的一个增长。这个事情需要更多的分析和支持。因为如果你的样本量比较少的话，那么这个百分之九百，他是一个准确的数字吗？采集的是哪个时间范围的样本？是否精确？还有你有没有去分析比如95%或者至少90%的置信区间。区间估计大概是多大?这些是很重要的信息。

假如我们百分之九十五置信区间的是(-300%,200%)。那么这个百分之九百是因为随机性导致我们看到的一个不准确的一个样本值。他并不能告诉我们，一旦我们这个上线之后他真的能给我们带来提升，因为置信区间还非常的宽，你并不知道哪个版本更好。

如果你的样本量已经足够大并且得出一个比较精确的一个置信区间(600%-1200%)你就可以相信，这个版本确实很好，如果你真的有这么好的一个效果的文案。你不仅要把他上线，而且你要告诉所有的人。比如微博置顶、微信公众号、广告的所有页面里都要改成这句话。

所以对非常有经验、技术专业比较深的人肯定都知道，实验结果需要一个医疗三期临床检验一个非常精确的统计学的结论，才能够给我们最大的帮助。但是对于刚刚开始做AB测试的来说，你不能只是一个样本采集的样本值就说哪个好哪个坏，你还可能需要更多的分析。如果你的样子量非常大的话，你也可以比较有信心样本值。你在做几次也能够重复出现，那么你的结论是非常可信的。

杨林_产品的观点：小的改动比方说文案颜色，确实对产品有非常大的影响。不过在实际运行中，仅仅通过不同版本的数据对比可能也并不科学，尤其是在流量比较小的情况下。个人感觉是A/B测试确实需要有一定的流量基础，流量太小可能意义不大。另外就是各种统计指标，比方说置信区间、显著性等等指标也应该多多关注。

本文主要内容贡献者：

王晔老师，DTalk联合创办人，吆喝科技CEO，耶鲁大学博士，曾在Google总部广告质量部门负责产品优化。

干货专访和文章
【DTalk分享】黄一能：互联网产品运营决策中用户画像的核心作用直播回顾
【DTalk分享】陈抒：产品设计中的用户画像直播回顾
【DTalk分享】吆喝科技王晔：A/B测试最佳实践直播回顾
【DTalk精华】网易郑栋:如何打通产品多端的埋点数据？
【DTalk精华】网易郑栋：前端数据采集与分析的那些事第一弹: 从数据埋点到AB测试
【DTalk精华】滴滴出行谯洪敏：前端数据采集与分析的那些事第二弹：企业如何选择自动埋点和可视化埋点
【DTalk精华】滴滴出行谯洪敏：前端数据采集与分析的那些事第三弹：埋点需求整理原则于埋点流程规范
【DTalk专访】滴滴谯洪敏：百家争鸣的前端技术时代
【DTalk思考】顾青：互联网团队的数据驱动能力从哪里来？