②：90%~95%：优化版本和原始版本之间的统计差异存有疑问，转化率的“改进”是存有疑问的；
③：90%以下：优化版本和原始版本之间没有显著的统计差异，转化率的“改进”是不可信的；
改进效果：
AB测试中优化版本与原始版本相比转化率提高的幅度 。计算公式是：
（优化版本转化率-原始版本转化率）/原始版本转化率 。
差异区间：
也就是AB测试的优化版本与原始版本之间转化率差异最可能分布的区间范围 。例如：A版本为原始版本，B版本是优化版本，A的转化率为10%，B的转化率为15%，则转化率的绝对差异为5%，而转化率的相对差异为50% 。
2、业务分析
通过以上统计学分析确定了可信度之后，就需要对AB测试的结果进行业务分析 。因为统计学分析中我们已经得出了差异性要素，在通过行业知识、客户心理、用户行为习惯、喜好等角度进一步分析，从统计的数字中挖掘出差异的真正的原因 。
AB测试实操需要注意哪些？
1，从简单开始：可以先在Web前端上开始实施 。Web前端可以比较容易的通过可视化编辑器制作多个版本和设置目标（指标），因此实施AB测试的工作量比较小，难度比较低 。在Web前端获得经验后，再推广到App和服务器端 。
2，隔离变量：为了让测试结果有用，应该每个试验只测一个变量（变化） 。如果一个试验测试多个变量（比如价格和颜色），就不知道是哪个变量对改进起了作用 。
3，尽可能频繁、快速进行AB测试：要降低AB测试的代价，避免为了AB测试做很多代码修改，尽量将A/B测试与产品的工程发布解耦，尽量不占用太多工程部门（程序员、QA等）的工作量 。
4，要有一个“停止开关”：不是每个AB测试都会得到正向的结果，有些试验可能失败，要确保有一个“开关”能够停止失败的试验，而不是让工程部门发布一个新版本 。
5，检查纵向影响：夸大虚假的CTA(Call To Action)可以使某个AB测试的结果正向，但长期来看，客户留存和销售额将会下降 。因此，时刻要清楚我们追求的是什么，事先就要注意到可能会受到负面影响的指标 。
6，先“特区”再推广：先在一两个产品上尝试，获得经验后，推广到其他产品中 。以点带面，全局布置，重点区分 。
关于AB测试的一些误区
误区1
AB测试运用成本过高，可以通过灰度发布的方式来进行AB测试，进而避免同时维护不同版本的情况 。
灰度发布是应用发布通常采用的方式，即对一个pool的部分服务器发布新版本的代码，而其余的服务器采用老版本代码，在确认应用正常的情况下逐步将新版本发布到pool的全部服务器 。这样的方式的确可以起到分流的作用，但是这样的分流是不稳定的，用户的两次访问很有可能会被分到新老两个版本上 。同时，灰度发布的分流单位通常是以服务器的流量为最小单位的，不能做到对测试流量的精确分配 。
误区2
用参加实验的部分用户的体验质疑AB实验结果的正确性 。
经常碰到产品经理或是业务人员提出某些用户在新版本的实验中没有转化，而实际实验数据体现新版本效果好于老版本的情况，从而质疑实验的结果 。AB测试是基于统计的结果，是基于大样本量的有效统计结果，实验结果的好坏是针对参与实验的大多数样本而言的，个例不具备代表性 。
误区3
AB测试是优化Web应用的利器，应该在所有场合都应用AB测试进行优化 。
AB测试从实验的设计、实施和实验结果的收集通常需要一个不短的阶段，且进行AB实验需要在线上维护多个不同的版本，所以不应该所有场景下都采用AB测试对Web应用进行优化迭代 。对于那些明显的bug修复，或者对于那些能够明显改善用户体验的功能，应该采用尽快上线并监控关键数据指标的方式 。此外，AB测试也不是silver bullet, 通常AB测试的时间不会延续很长时间，对于一些长期效果很难做到有效的监测和对比 。
