如果没有A/B实验，一个能带来30%收入增长的功能和一个导致10%下滑的功能混在一起发布，你只能看到一个‘整体不错’的假象。
一个版本发布后数据持续下跌，团队花数周查Bug、开会，最终被迫回滚——这种开发噩梦，本可以通过A/B实验在发布前就彻底避免。
第一、加速迭代
让多组实验互不干扰地同时进行。早期没有 A/B 系统的时候，上需求都是要排期的——可能这次排期的优先级已经满了，优先级不够的需求要等到下一次排期。而有了 A/B 实验系统，多组 A/B 实验可以同时跑，通过分流做到各个实验之间互不干扰、并行迭代，大大加速了产品迭代的速度。
第二、量化提升
在没有 A/B 的时候，我们经常用「月对月」、「周对周」、「版本对版本」这样去比较。但这种方法非常不科学，因为对比的时间不一样——比如有暑假效应、周末效应，绝大多数产品在暑假前一周的表现跟暑假里面一定是不一样的，很难明确量化功能的效果。
再举一个更具体的例子：同一个版本同时上了两个商业化的需求，最后这个版本的收入涨了 20%。那怎么区分这次提升是由哪个需求带来的？是第一个需求提升了 19%，第二个提升了 1%？还是两个各提升了 10%？——猜不出来还不是最可怕的。
最可怕的是：一个需求实际上涨了 30%，而另一个下降了 10%，整体看起来没什么毛病。下降的那个需求跟着「比较厉害」的提升也混到了全量。如果通过 A/B 来发布，就不会存在这些问题——我们可以明确量化出第一个需求提升 30%，第二个下降 10%，第一个发全量，第二个去查问题。
第三、降低风险
在没有 A/B 之前，一个版本发出去后数据开始下降。刚开始大家觉得是波动，等了三天发现还在下降，怎么办？查问题。数据 Leader 带着分析师查数据，运气好的话能定位到大概模块；研发 Leader 带着研发同学 Review 代码，发现有好多 Bug——但具体哪个 Bug 导致了业务数据下降，很难定量评估。
可能我们发现了几个问题，修了 Bug 重新发版。发完之后过了几天一看，悲剧了——修完之后根本没用，数据还在跌，那几个 Bug 根本不是这次下跌的真实原因。然后产品、开发、数据、测试一群人在会议室里开会讨论，最后基本就是一个办法：版本回滚——把上一个版本拿出来重新发版。这个流程短则两周，长则一个月，对公司的损失非常大，员工的士气也非常受影响。
但如果接入了 A/B 系统，正确做了 A/B 实验，这样的悲剧就不会发生。因为在 A/B 阶段就可以发现新 Feature 的问题，有问题的需求根本没机会全量发布，从而避免了版本回滚。
综上所述，A/B 实验相对于传统的迭代方法，在加快迭代、效果评估和控制风险上，都有一个质的飞跃。
