AB测试是产品经理和营销人员进行方案优化时常用的方法，通过AB测试对比新老版本的转化数据，从而更科学的判断哪个版本效果更好，指导方案优化，持续提升产品体验和转化。但很多使用者在进行AB测试时不经意间就进入了误区，无法有效进行AB测试。其中，常见的误区主要有以下这些：
误 区 ：为了得到真正可靠的结果，将网站或应用内的任何更改都进行 AB 测试。无论变化有多大，以及转化改进带来的预期增长情况如何，这并不重要。面面俱到的测试网站上的每个组件将会带来令人难以置信的业务成果。
真 相 ：漫无无目的测试不仅会浪费宝贵的时间和流量，而且不会为业务带来真正的增长。需要事先通过分析转化渠道来进行自检，并找到出现问题的所有可能性，并且提出解决问题的假设，在明确假设的前提下展开 AB 测试。当然，案例研究可以为我们带来灵感，作为新想法的奇妙来源。AB 测试并不是要一直测试全部元素，我们应该构建和实施自己的AB测试策略，策略要基于业务目标和转化漏斗的“痛点”。
误 区 ：UI层面类的方案选择，主要是找到视觉效果最好的设计，很明显，漂亮的设计必须更好地执行。丑陋的设计是不可能赢的，所以测试这样的变化甚至没有意义。
真 相 ：事实是，不同方案的美丑只是我们自己的评价判断。一个人认为这种设计更好，另一个人可能会选择另外一个变量，因为每个人都有自己的审美和视角。这对试验者可能是难以置信的事情，但我们确实应该根据测试方案的受众目标，主动测试不同的变化，用数据驱动决策而不是主观感觉。
误 区 ：根据过往采集到的数据，对意向用户和非意向用户打上标签，将意向用户分给试验版本，非意向用户分给原始版本，然后将试验结果推广至全量用户。
真 相 ：AB 测试能否成功很重要的一点就是流量是否随机分配，每组用户是否具有代表性。而这里就要提到一个概念：辛普森悖论。
举一个栗子：两种疗法治疗肾结石的成功率
可以看到，无论对于大型结石还是小型结石，A 疗法的成功率都是相对高一些的；而将两种类型的结石一起研究时，B 疗法的成功率反而更高。这就是辛普森悖论：即在某个条件下的两组数据，分别讨论时都会满足某种性质，可是一旦合并考虑，却可能导致相反的结果。
所以在 AB 测试中，上述的情况就是分流不均，由于最初把用户按照某种属性做了分类，导致最后的试验结果是有偏差甚至是完全相反的。
误 区 ：只要做到了随机分流，保证了对照组与试验组流量均分（避免发生辛普森悖论的情况），每个组就是独立的，试验结果一定是准确的，不会受到流量因素的干扰。
真 相 ：即使确保了对照组与试验组的流量是随机分配的，特殊业务场景下还是会受到流量因素的干扰。比如：在某推荐算法的AB测试场景中，试验版本中的用户因为喜欢新版内容而延长了在 App 内的停留时长并且分享了喜欢的内容，而恰好在原始版本中的用户看到了前者分享的内容同样也花了更多的时间在 App 中，这就使得原始版本也间接受到了试验版本的影响。所以在 AB 测试前期设计时，就要考虑到真实业务场景的复杂多变，避免此类问题的发生。
误 区 ：试验开始之后不停的观察数据，当看到置信区间已经收敛，转化数据看上去还不错的情况下，就立刻结束了试验，并且将结果推广至全量用户。
真 相 ：在 AB 测试开始之后，我们一定会迫不及待的想要拿到试验数据，希望自己的猜想得到验证。大多数的 AB 测试工具会在试验开始后实时的统计数据的变化。正确的做法是让 AB 测试运行一定的时间（流量充足的情况话建议至少运行7天），并通过足够数量的样本，有了足够的相关数据，才能指导业务做出更好的决策。
误 区 ：在某些情况下，我们的试验并不会很快的出结果，可能需要等上几周、甚至几个月。这时试验者可能就会有这样的想法：这样的 AB 测试是没有价值的，因为根本就没有可用性结果，还为之付出了相应的人力物力及时间，得不偿失。
真 相 ：上述的情况可能有不同的原因。其中一个是流量太小，另一个是试验设计有问题。在第一种情况下，完成试验可能需要几个月甚至更长的时间（例如，每天只有 100 位访问者），所以短时间内就不会收敛。第二种情况如果流量够大，但是依然没有结果，我们就要考虑调整试验方案，重新开始试验。
这里要告诉大家的是，试验不收敛其实也是一种结果，不要认为在做无意义的事情。经统计在热云数据 AppAdhoc AB Testing 平台，没有收敛的试验占到了总试验的 60%，这意味着其实我们好多的猜想是不符合用户需求的，但如果没有进行测试，盲目上线认为效果好的版本，也不会对业务带来正向反馈，效果甚至适得其反。
误 区 ：当我们看到其他人做了 AB 测试后，转化数提升了 30%，恰好我们有类似的场景，于是就把试验版本的内容直接套在我们的产品上，希望得到同样的结果。
真 相 ：要记住没有任何一次 AB 测试是相同的，对其他产品有用，对我们的产品未必起作用。试验的运行时间，市场环境，受众目标等等都是不同的，所以不要盲目使用别人的测试结果，很有可能得不偿失。
误 区 ：AB 测试是一种非常昂贵的优化方法，因为从数据的收集分析，不同版本上线，分流算法到最后的统计计算，需要产品，技术，设计等部门协同配合。而这其中的分流，一旦出现不均的问题就可能导致我们所有的付出全部白费，从而认为 AB 测试就是一件麻烦事，继而逃避试验。
真 相 ：AB 测试不是那么的困难或昂贵。利用AppAdhoc A/B Testing工具，首先确保分流和统计计算的准确性。其次在试验准备上，利用AppAdoc A/B Testing的Visual Editor（可视化编辑器）功能，也可以实现0代码基础快速上线试验，避免小调整也需要等待开发排期的情况，省时省力，高效迭代。