DataTester平台中，开设AA实验者不在少数（也包括一些实验人员爱开AABB实验），利用AA实验来验证分流服务是否运转正常，这一举措确有其合理性。然而，一旦发生AA置信，则一口咬定是DataTester的分流服务/数据统计出了问题，这就存在一些理解偏差了。
我们在解释显著性水平的时候已经提过，在检验假设的过程中，我们会犯第一类错误——我的策略没有用，但实验结果显示我的策略有用。在95%的显著性水平下这类错误出现的概率是5%，即，我们开100次AA实验，然后观测某个指标，可能会有5次得到显著的结果。这是由于不可避免的抽样误差所导致的。
因此，如果AA实验指标差异呈现统计显著，也不过是一个概率问题，并不代表DataTester的分流不科学/数据统计出现了问题。相反，假设检验正是利用「抽样误差」来帮助我们量化犯错的概率，并将其控制在5%以内的（95%显著性水平下），也就是说，如果我们观测到AB显著的结论，犯错的概率就是p-value的大小。
综上，发生AA置信的情况属于正常现象，DataTester会保证分流和统计服务的可靠性，请您尽管大胆假设，小心实验。
我们曾在介绍A/B实验类型时提及过「过度曝光」问题，这是许多实验者容易忽略的一个问题。
什么是过度曝光？
在开设实验时，大量并没有体验到实验版本功能的用户被计入到了指标统计中，导致指标值被稀释（实验中涉及的功能可能“入口较深”，用户打开应用后其实并没有进入到这一功能，但仍然被算作了进组用户，参与了指标计算）。
比如：在某APP的实验中，我们调整了个人详情页里「收藏按钮」的形状，但用户打开APP后需要进行多次点击，才会在个人详情页里看到这个收藏按钮，用户在使用APP时，很可能从头到尾都没看见按过这个按钮。然而，对于DataTester的「服务端实验」或者「普通客户端实验」，只要用户请求过分流服务并被判定进组，且在服务端日志中上报了日志记录，那么该用户的数据就会参与实验指标计算。也就是说：进组的用户根本就没有体验到实验策略，却依旧参与了人均指标、转化率等指标的计算，他们的参与使得这些指标的分母相较于实际情况而言“变大了”，指标值被稀释。这种情况就被称为「过度曝光」。
过度曝光有什么影响？
「指标被稀释」对实验效果评估的影响主要体现在：实验中，有效样本量低于“实际统计到的进组用户量”，评估数据中引入了「没有被真实影响」用户的噪声，导致指标方差更大，实验达到统计显著性需要更多的样本、需要更长的时间。
如何避免过度曝光？
那么，我们应该怎么避免过度曝光的问题呢？
- 客户端实验。
我们推荐大家开启「客户端SDK实验」（需要集成DataTester「AB客户端SDK」），由客户端 SDK 完成实验命中用户的记录。DataTester 在 SDK 的数据上报环节中，增加了「实验曝光区」的设计，仅当实验配置下发，且用户体验到实验功能才会将用户命中实验的信息上报到 event_log 日志中的「实验曝光区」。
拿上面的例子来说：在计算指标时，我们会通过event_log日志的「实验曝光区」来辨别用户是否真正看到了收藏按钮，且只将看过按钮的用户纳入指标计算之中。 - 服务端实验。
情况比较复杂，目前我们可以在指标计算时加入一些过滤条件，剔除掉实际上没有受到实验影响的用户，来尽可能减少数据层面的噪声。
比如，某实验针对头条主端科技频道的推荐策略进行优化，那么我们可以在计算指标时，过滤掉导致过度曝光的用户（打开APP但压根没有点进科技频道的进组用户）。但是这种办法并不能完全解决服务端实验过度曝光的所有情况。
综上，请关注您的实验场景是否会有过度曝光问题，客户端实验建议通过客户端 SDK 实现。
以假设检验为理论依据的A/B实验，仅适用于AB两组进行对比的场景，能够帮助大家从A策略和B策略之中选择一个更好的：在95%的置信水平下，假设新策略没用，我们做一次对比，犯第一类错误（即我的策略没用，但实验结论显示我的策略有用）的概率是5%。但是，如果您的实验是AABB实验，或者ABCD实验，或者ABCDEFG实验等，那么情况就截然不同了——我们将面临多重比较问题：当实验组多于2组时，我们犯错的概率将大大增加，不再是5%。
以ABCD实验为例：假设策略A、B、C、D间没有明显差异，我们对ABCD两两对比，共计有6种组合，需要进行6次对比。6次对比中只要有一次犯错，我们的结论就算犯错，因此每个统计指标的犯错概率就变为了1-(1-5%)^6=26.5% ，远大于5%。
另外需要注意的一点是，假设检验以「AB没有明显差异」为原假设，B相对于A所得到的p-value，并不等同于B比A好的概率就是1-(p-value)。也正是因此，当存在多重比较的情况时（特别是各组策略没有明显的优劣差异甚至是旗鼓相当时），假设检验难以提供判断哪个策略最优的标准。以上两个问题大大增加了我们评估ABCD谁更优的难度以及决策出错的风险**。**
因此，在多组中进行择优时，建议开启多重比较功能，以多重比较修正后的结果为准。
什么叫做为显著而显著呢？在实际的业务过程中，我们发现这种错误主要体现为2种情况：
- 关注过多无关紧要的指标，只要一个指标显著，即认为策略有效。
我们一再强调，在实验中，我们要明确目标，提前确定哪些指标能够真正衡量实验效果，并把这部分指标定为实验中要观测的核心指标。如果我们在实验中观测过多指标，众多无关紧要的指标中，碰巧出现显著是很正常的情况。实验者很可能被这种显著误导，进而认为他的策略有效。 - 对核心指标进行多维度下钻，指标在某一维度上呈现显著，即认为策略有效。
部分实验者会在分析多维下钻实验结果时：在新策略的影响下，指标在某一维度下显著了，那么我的策略肯定是有效的。然而实际上，这个结果有可能会是假阳。
我们来举个例子：假设一款APP的用户分布于5个国家，有3种客户端，那么将国家和客户端组合起来，我们可以下钻出15个维度。某指标在其中一个维度下偶然呈现显著的可能性有多高呢？
经过计算可知，有超过50%的可能出现显著。因而，利用某一维度下的显著来验证策略的效果并不合理。
综上，坚持实验设计阶段确定的目标和评估标准，不要为了获得统计显著的结论而将原定核心指标更换为其他因果关系弱的指标，也不要过度分割数据。如果业务逻辑明确确定新策略确实对某人群属性有特殊的影响，建议更新实验目标，再开一个针对该人群的定向A/B实验进行二次评估。
在分析师中有一句流行的话：“别早看实验报告”，什么意思呢？就是达到预估的样本量（也可以理解为达到预设的实验天数）之前，不要过早地去看实验结果，因为这种时候实验结果有可能会显著，您会忍不住想要停下实验，并用目前的显著结果作为实验结论，然而这是不正确的做法。
对于实际没有显著差异的实验（可以理解为新策略无效），在实验初期进行观测，指标也很有可能出现显著，这种情况我们称之为假阳性。我们使用假设检验来量化抽样误差的理论需建立在「满足一定的样本量」这一前提之上，当样本量不足时，抽样误差对指标的影响会更大。随时间的延长，实验样本量不断增加，p-value取值也会发生变化，待进组用户累计达到预估样本量的时候，实验结论可能从前期的假阳性变为不显著。
来看下图中的例子，这在这个AA实验中，我们预估的样本量是5000。从图中可以发现，实验在中期达到显著（置信度95%以上）；随着样本量的逐渐增多，实验结论最终固定为不显著。
因此，在实验未达到预估样本量之前，显著性可能会在显著和不显著之间来回波动，过早决策的实验结论可能不可靠。DataTester后台推荐大家使用多天累计指标来进行指标观测。从业务角度来讲，多天累积指标本身存在天与天间波动，且周末和工作日表现差异较大，建议实验运行整数个完整自然周后，再做实验决策。
另一方面，从心理层面来讲，如果在早期观测时发现实验指标显著，有些实验者会先入为主，指标所呈现出的假阳性，会让这部分实验者在分析实验结果时，故意挑选出支持他们的观点的实验结论。
与错误No.4相反，在这种情况下，实验者会持续开启实验，直到实验显著。针对这一点，让我们抛开理论，从哲学的角度上感性地去理解：
A/B实验中，无论A策略与B策略多么相像，他们终归是不一样的。理论上来说，只要样本足够多（比如无穷多时），实验组和对照组策略的任何一点差异都会致使实验结果形成统计显著。但这种显著有意义吗？比如我的实验开启了整整10年，新策略使指标提升0.001%，且统计显著，这真的有意义吗？关于这一点，更加详细的理论依据可以参考Power：检验效力、样本量和灵敏度MDE。
综上，我们在实验中，应该遵从实验设计，如果实验已经在预期运行周期内达到所需的样本量，但目标指标变化仍然不显著，那这个实验没有必要继续运行了，停止实验换个方向继续尝试吧。
假设我现在开了一个实验来优化商品页面的用户购买率，其中采用了新策略B的实验组，购买率提升了为3%，且结论置信，这是不是代表我的策略B上线之后，该商品页面的购买率就一定能提升 3% 呢？—— 结论是「不是」。
由于在A/B实验中我们采取部分流量抽样的方式，样本不能完全代表总体，那么实际上，策略 B 如果在总体流量中生效，它的增长会与部分流量时结果有一些差异（置信区间范围内）。事实上，通过假设检验，我们能够结合显著性水平，估算出提升值的范围，这一范围被称为置信区间。
假设在前面的例子里，经过计算，置信区间为[1.5%，4.5%]，那么在策略B实际上线后，预估区间[1.5%，4.5%]将有95%的可能包含真实的购买率增长率（如果显著性水平取0.05的话）。
综上，如果您想知道新策略上线后，指标可能发生的变化情况，可以参考置信区间。
我们倡导用数据说话，不主观臆断，在评估实验时不仅要看指标的提升量，还要结合置信度来判断数据的可靠程度。然而，在部分情况下，数据仅能传达给我们片面的信息，还需要我们基于数据背后的事实进行因果推断，以保证数据论据与要证明的论点之间是具有合理的因果关系的，这样数据才是我们论证观点的有效利器。否则，我们就仅仅只是单纯地拥有数据而已。
举个例子：我们通过分析用户订单的支付路径行为和用户访谈，发现了产品支付过程中存在的问题，并针对性地开发了一个优化功能来提升用户的支付成功率。为了验证这个改进点是符合用户实际场景的，我们设计了一个A/B 实验，A组对照与线上功能一致，B组实验使用优化功能，并根据AB组支付成功率的差异来评估改进方向是否正确值得全量上线。我们预期这一新feature在A/B 实验时对「支付成功率」这个指标有一定的正向提升（至少不会有负向影响）。但是实验结果却与我们的预期大相径庭——实验结果呈负向显著。
这种情况下，请先不要急着否定「新feature有助于提升支付成功率」这个业务判断，因为基于前期的业务分析，我们的实验内容设计和评估指标之间是有合理的因果关系的。确认实验设计合理性后，可以再从功能实现、数据统计等方面入手，排查一下实验人群圈定和A/B 版本的功能是否正常生效无Bug，数据上报链路是否畅通、统计方式是否正确，逐步找到指标负向背后的原因。
综上，在实验中，我们需要根据自身的业务判断，合理设计实验，明确预期；当 A/B 实验结果违背我们的业务直觉时，应当保持怀疑。