你是不是也遇到过这种情况辛辛苦苦做了两个方案拿给同事看同事说我觉得B好拿给老板看老板说还是A稳妥一点——最后谁都说服不了谁。在很多公司里这种争论最后都变成了谁嗓门大听谁的。但如果你懂数据分析手里握着对比法这个工具情况完全不一样。同样的争论你可以直接甩出一句话别争了跑个AB test吧。对比法在数据分析里属于最基础但又最容易被用歪的方法。很多人觉得对比法就是拉两个数出来比大小今天比昨天涨了A方案比B方案点击率高然后结论就出来了。但真正的对比法尤其是AB测试讲究的是控制变量和统计显著性否则你看到的差距很可能只是随机波动。这篇东西我想系统聊一聊数据分析里的对比法核心讲透AB测试——从统计原理到完整的落地流程再到实际工作中最容易踩的坑。不管你是做产品、运营还是数据岗位这篇内容都值得读完尤其是那些正准备在公司里推AB测试但不知道从哪下手的人。1. 对比法不只是拉数据比大小三种对比方式的边界1.1 纵向对比、横向对比和正交对比我在带团队的时候发现一个很典型的现象很多刚入行的数据分析师一说对比法想到的就是和上周比和竞品比。这两种对比方式确实有用但它们解决的是完全不同的问题而且都有自己解决不了的盲区。纵向对比看的是时间趋势。比如你这个月销售额比上个月涨了15%你得出结论增长不错。但是这个增长到底是季节因素带来的还是因为你上个月上线的新功能起效了纵向对比回答不了这个问题因为时间维度上变的东西太多了——季节、市场环境、用户习惯、竞品动作全都混在一起。横向对比看的是同一时间不同对象之间的差异。比如你和竞品都做了618活动你的转化率是5%竞品是7%说明竞品做得比你好。但这个好是因为它的活动机制更好还是因为它的用户体量更大、品牌更强横向对比同样回答不了因果问题。这时候就需要第三种对比方式——正交对比也就是AB测试。AB测试的核心逻辑是把所有用户随机分成两组一组看A方案一组看B方案其他所有条件保持一致。因为分组是随机的两组用户的理论特征几乎完全一样所以实验组和对照组之间唯一的系统性差异就是那个被改变的变量。这样一来你看到的差异就可以有底气地归因于这个变量的变化。1.2 AB测试适用和不适用哪些场景AB测试听起来很万能但实际场景里它边界感很强。适合做AB测试的场景有几个特征第一有足够的流量不管用户量够不够支撑起统计显著性第二决策是增量式的比如改个按钮颜色、调一下推荐策略、换个文案、改一版首页布局第三迭代频率高能用小步快跑的方式持续优化。不适合的场景也很多。比如你的产品还在冷启动阶段DAU只有几百个硬跑AB测试没有任何统计意义——这个后面我会用公式给大家算清楚为什么。再比如你要做的是一次全新的、品牌层面的战略转型这种整体性变革根本没法拆成可对照的变量。还有一种情况没人提但是很常见业务方其实心里已经有决定了跑AB测试只是想拿数据证明自己的决定是对的这种先有结论后有实验的做法不光浪费时间而且非常容易在实验设计上作弊。1.3 为什么AB测试是归因分析里最干净的方案数据分析做到深处核心就是归因到底什么动作带来了什么结果日常工作里我们做的很多分析比如漏斗分析、路径分析、留存分析本质上都只是在描述发生了什么而不是证明为什么发生。要真正验证因果关系最好的工具还就是AB测试。它的干净来自于随机分流这把保护伞。随机化能有效排除已知和未知的混杂变量影响——注意未知这两个字这是AB测试和任何事后分析方法最本质的区别。你做回归分析的时候能控制的可观测变量有限模型永远存在遗漏变量偏误的可能而AB测试不需要你事先把所有混淆因素都识别出来只要分组是真正的随机理论上混杂因素在两组之间是均匀分布的。这也是为什么业内常说AB测试是因果推断的黄金标准。2. AB测试背后的统计逻辑为什么不能看数字大小下结论2.1 随机波动是一切AB测试需要面对的基本问题我在知乎上见过不少这种问题活动页A方案转化率8.3%B方案7.9%是不是说明A更好很多小公司的决策者就是这么干活的——看一个统计报表谁数字大选谁。但问题是这0.4个百分点的差距可能根本不是方案优劣带来的它就是纯粹的随机波动。打个比方你把一枚理论上完全均匀的硬币抛100次理论上正面应该是50次但如果哪次抛出来正面只有45次你会觉得这枚硬币有问题吗不会。因为你知道随机波动天然存在。AB测试面对的是同一个问题用户行为本身充满了随机性哪怕两个方案完全一样也就是你做了AA测试你拿到的转化率数字也会天然有高有低。问题在于我们要怎么判断这个差距到底是随机波动还是真实差异2.2 假设检验和P值的本质理解这时候就要搬出统计学了。AB测试的本质是一个假设检验。你有一个原假设H0两个方案没有差异一个备择假设H1两个方案有差异。你通过收集数据来检验如果H0成立的情况下出现当前这么大数据差异的概率有多大这个概率就是P值。很多人对P值有误解以为P值代表A方案比B方案好的概率这个理解是错的。P值的准确定义是在假设两个方案本身没有差异的前提下由于随机波动观察到当前这么大或更大差异的概率。如果这个概率只有2%说明两个方案无差异这个假设不太站得住脚因为如果真没差异你很难看到这么大的差距——所以你倾向于拒绝H0认为两个方案真的有差异。传统的判断标准是P 0.05也就是显著性水平α0.05。意思是说我愿意承担5%的误杀风险也就是说哪怕两个方案其实没差异我也有5%的概率仅凭随机波动就得出了有差异的结论。这个5%是第一类错误也叫弃真错误。2.3 统计功效别等到实验做完了才发现样本量不够和第一类错误对应的还有第二类错误取伪错误它指的是两个方案其实有差异但因为样本量不够大你的实验没能检测出这个差异。这个错误的概率用β表示统计功效就是1-β业内通常要求至少达到80%。结合两类错误来看就能回答一个常见的问题AB测试要跑多久、需要多少样本量答案取决于四个因素基线转化率p1、你想检测的最小效应量δ、显著性水平α通常0.05、统计功效1-β通常0.8。样本量估算公式长这样两组独立比例检验的情形[ n \frac{(z_{1-\alpha/2} z_{1-\beta})^2 \cdot [p_1(1-p_1) p_2(1-p_2)]}{(p_1 - p_2)^2} ]看着吓人用起来其实不难。举个例子你的旧页面转化率p120%你想检测出至少2个百分点的绝对提升也就是p222%α0.05β0.2查正态分布表可得z_1-α/2≈1.96z_1-β≈0.84代入公式[ n \frac{(1.96 0.84)^2 \cdot [0.2 \times 0.8 0.22 \times 0.78]}{(0.22 - 0.20)^2} \frac{7.84 \times 0.3316}{0.0004} \approx 6500 ]每组大概需要6500个样本两组加起来13000左右。如果你们产品一天只有2000个访问用户意味着这个实验至少得跑一周。如果我想检测更小的效应量比如1个百分点那算出来每组需要2.4万样本时间顿时翻了四倍。这就是为什么业内常说AB测试是一个耗时间的细活。2.4 置信区间比P值更有信息量P值给出的是一个二元判断显著或者不显著。但实际业务决策时光知道一个二元结论远远不够。这就是为什么资深数据分析师一定会看置信区间。置信区间给你的是一个范围真实效应量有多大的可能性落在这个区间内。比如你算出实验组转化率比对照组高1.5个百分点95%置信区间是[0.3%2.7%]意思是你有95%的把握认为真实的提升量在0.3到2.7个百分点之间。这个信息量比单纯一个P0.02大得多——它告诉你效果的下限和上限。如果区间下限是0.3个百分点虽然显著但可能这个提升值不值得你付出那么高的开发成本去全量上线这就是业务判断的问题了。如果你双击几个核心指标每次都用置信区间去看你会比那些只看P值的人敏锐很多。3. 从假设到数据回流一个AB测试的完整实施流程3.1 提出假设用业务逻辑驱动实验设计很多初学者喜欢先跑起来再说但真正有价值的AB测试都始于一个清晰的假设。假设的基本格式是因为某个用户痛点如果做出某个改变会对某个指标产生怎样的影响。举个例子你要优化注册页的转化率。但不加思考地改就是耍流氓。正确的做法是先做用户调研、看用户录屏、分析流失用户的路径发现一个可能的痛点用户对填写资料过长感到厌烦。基于这个洞察你的假设可以是把注册表单从10个字段减少到4个字段能提高注册转化率至少10%。实验目的清晰了后面设计起来就有方向感。写假设的时候顺便把下面几个问题一起想清楚这次改动预期的受益人群是谁会不会有一部分用户反而受影响例如表单缩短了可能进来的用户变多但线索质量可能下降——这就是你需要同时设计护栏指标的原因后面会讲。3.2 指标选择核心指标和护栏指标缺一不可AB测试最忌讳只盯着一个指标看。单一指标被优化、其他指标崩掉的例子在行业内一抓一大把。比如你把首屏的促销弹窗做得更激进了点击率确实上去了但用户次日留存下来了甚至卸载率上去了——这种实验如果只看点击率你会误以为做对了。正确做法是至少设计两层指标。第一层是核心指标也就是你这个实验最想优化的那个北极星指标比如注册转化率、下单转化率、付费率等。第二层是护栏指标用来保证你不能为了优化核心指标而伤害用户体验或长期价值比如客单价、次日留存率、NPS、卸载率等。核心指标变好的同时护栏指标不能显著变差这是AB测试结果可以全量上线的底线。3.3 分流设计与实验单元用户ID、设备ID还是浏览器会话分流单元决定了一个用户算几个样本这是设计阶段特别容易翻车的一环。常见的选择有用户ID、设备IDdevice_id和浏览器会话session。如果你做的是注册转化率实验实验单元一定是人——一个注册用户只能被分到一组。如果你用session来分同一个用户的多次访问可能被分到不同组导致一个用户在不同组的体验不一致数据被污染。再比如你做的是推荐策略实验同一个用户多设备登录的情况很多用user_id分流比device_id更准确。反过来说如果你的产品没有用户体系比如一个纯工具类的匿名站点那只能用device_id或者cookie来做近似。分流不均匀也是个很常见的问题。理想情况下两组占比应该是50/50但因为某些技术原因可能出现45/55甚至更夸张的偏差。这种情况下实验结果就不可信了因为分流本身可能就引入了偏差。我在第五节还会专门讲SRM的问题。3.4 实验时长不只是算够样本量算出样本量只是实验时长下限的参考实际跑实验的时间要更长。以下几个因素必须考虑进去第一覆盖完整的业务周期。电商产品必须覆盖一个完整的周末因为周末和平时用户结构不同如果你的目标是提升付费转化最好跑满一个月的完整周期覆盖发薪日前后用户消费能力差异这样的周期波动。第二过滤新鲜感效应。一个新上线的东西用户一开始的反应往往和他们的长期行为背离。按钮变红了可能一开始大家都点一下但几天后用户就适应了回归正常水平。所以实验时间不能太短要等用户行为稳定下来。第三反作弊和数据清洗需要时间。垃圾流量、爬虫、异常ID都要剔除后再分析这些都要预留时间。3.5 埋点验证与数据回流实验跑起来不等于万事大吉实验上线不等于接下来就等着收数据了。上线后的第一天到第三天是最关键的验证窗口期。你需要确认两组用户的实际分流比例和预期一致实验组用户真的看到了实验版本而不是旧版本核心事件的上报数据是否在正常回流有没有明显的埋点丢失问题。这些听起来像废话但我做过的很多项目中都有几次差点带着错误数据得出错误结论。印象最深的一次是我们用前端埋点做实验结果遇到某个浏览器版本缓存了旧JS文件导致20%的实验组用户实际跑的还是旧页面——如果没在前期发现实验跑完直接分析结果就是废物。现在我们的团队有个约定俗成的规矩实验上线48小时后进行第一轮数据质量检查查三项内容——分流比是否接近预期、暴露量实验组PV/UV是否正常、事件量核心埋点是否有断裂全部通过才允许实验继续跑。4. 结果解读不能只看P值五个反复出现的坑4.1 显著性不等于业务显著性p0.049和p0.052没有本质区别这是一个统计学家看了会叹气的现象有些团队把P0.05当成一道铁闸P0.049大喊效果显著全量上线P0.052就说不显著换方向。但P值本身就是一个连续的值在0.05附近反复横跳是非常常见的。你只要再多积累几百个样本P值可能就跨过这条线了反过来也一样可能本来0.049的结果多跑一天变成0.06。真正理性的做法是把重点放在效应量和置信区间上。如果效应量很小比如提升0.01个百分点哪怕它统计显著到P0.001这个实验对业务来说也没有价值——不值得为你做一次的改动付那么多开发成本。反过来如果效应量很大但暂时不显著说明可能是样本量不足、统计功效不够这时应该延长时间而不是急着下判断。我个人的标准是P值显著效应量达到事前设定的最小预期值置信区间下限可接受三者同时满足我才会建议全量上线。只满足前两个会建议再做一轮验证实验只满足第一个直接放弃考虑。4.2 多重比较问题实验组内部塞了太多变体实验组不只有A和B可以同时测试多个变体——这就是多重比较。比如你想试4种不同的落地页标题于是你跑了一个A vs B vs C vs D的实验。问题来了你做了4次比较按照α0.05的标准至少出现一次假阳性的概率就不是5%了而是(1-(1-0.05)^4 ≈ 18.5%)左右。换句话说你每做一次这样的多组实验就有接近五分之一的概率纯靠随机波动发现一个显著的结果。解决思路有几个最简单的做法是用Bonferroni校正也就是把显著性水平调整为α/nn是比较次数。但这个方法的代价是放大了第二类错误让你更不容易发现真实存在的差异。更推荐的做法是如果你想测多个变体先做一个小流量的筛选实验把明显表现差的变体淘汰掉只留下最有希望的1-2个进行第二次完整实验这样能有效控制多重比较带来的风险。4.3 辛普森悖论分组看和总体看结论完全相反辛普森悖论是归因分析里最有迷惑性的问题之一在AB测试结果解读里同样适用。它描述的现象是在总体数据上A方案比B方案表现好但你把用户按照某个维度比如新老用户、渠道来源、设备类型拆分后每个子群里都是B方案表现更好——整体和局部的结论完全相反。这个悖论听起来反直觉但在实际业务中很常见。比如你的实验组被分到了更多高价值的老用户虽然总体比例均衡但在某个子群内不均衡而老用户整体转化率就是比新用户高于是实验组的整体数据被拉高了。表面上看是方案有效实际上是分流导致了用户结构异常。怎么预防和处理这个坑第一在分流时做分层抽样确保关键用户维度新老、渠道、机型在两组间的分布基本一致第二在分析结果时如果条件允许先做分组分析再看整体结论是否和分组结论一致如果矛盾要顺着矛盾查下去找到原因再下结论。4.4 新奇效应和厌恶效应用户对变化的短期反应不等于长期反应新奇效应指的是新方案刚上线时用户因为新鲜感而表现出异常的积极参与度短期内实验组指标很好看但过一段时间就回落了。厌恶效应则相反——改动刚出现时用户不适应甚至反感到直接流失但如果坚持一段时间用户其实能逐渐接受长期指标反而是好的。这两个效应对AB测试的直接影响就是实验时长太短会导致结论失真。我见过一个团队跑文案测试只跑了三天实验组点击率比对照组高30%团队兴奋地全量上线了结果两周后点击率不仅没保住优势反而比原来还低了。正确的做法是实验室外延长至少覆盖到用户行为趋于稳定的时间点。如果你怀疑存在新鲜感效应可以用滑动窗口法按天看核心指标的趋势确认实验组相对对照组的优势是否在衰减衰减到什么程度。4.5 SRM样本比率不匹配意味着整个实验作废SRMSample Ratio Mismatch是一个比较专业的概念简单说就是在理想分流比例下你期待每组各占50%流量但最终收集到的数据里访客数或者是事件数明显偏离了这个预期比例——比如一组60%、一组40%。SRM一旦发生说明实验中可能存在系统性偏差这个实验结果就直接作废不用再看P值了。SRM的产生原因五花八门其中一个方案有严重bug导致一部分用户无法加载页面某个实验组对于低版本浏览器不兼容用户直接流失埋点上报逻辑不同步导致一个组的曝光事件大量丢失又或者是反作弊系统对不同组进行了不同力度的过滤。所以每次实验分析前我建议先把分流比做单一样本比例检验可以用卡方检验如果P值小于0.05直接判定SRM然后回头查数据采集链路。5. 没有专业AB平台怎么用现成工具做靠谱实验5.1 基于用户ID的哈希分流最简单的实现方式很多中大型团队会购买或者自建专门的AB测试平台功能挺全面的。但如果你所在的是一个小团队连AB测试平台都没有也用不着推翻重来——只要你的产品有用户ID体系你完全可以用哈希算法自己做分流。核心思路很简单对每个用户的唯一标识比如user_id计算哈希值把哈希值映射到一个0到99的整数很好懂对吗比如哈希值对100取模后小于50的分到对照组大于等于50的分到实验组。这样每一个用户都有稳定且唯一的组别归属多次访问不会发生漂移。代码实现我贴一个简单的Python版本大家可以参考一下import hashlib def assign_group(user_id: str, split_ratio: float 0.5) - str: # 使用MD5哈希取模保证用户分组的确定性 hash_value int(hashlib.md5(user_id.encode(utf-8)).hexdigest(), 16) if hash_value % 1000 split_ratio * 1000: return control return treatment注意几个细节一是哈希函数要选择均匀分布的MD5或者SHA-256都行用内置的hash()函数不稳定不同进程的种子不同会导致同一个用户被分到不同组。二是盐值salt可以用实验编号这样不同的实验之间用户分组是独立的比如实验1的用户和实验2的用户在同一个人身上可能分到不同组这是正交实验设计的思路。分流做完之后你需要在前端或者后端记录每个用户被分配到的组别信息然后数据落到数仓后续的分析环节就可以用这个组别字段取数了。5.2 Excel里的快速分析T.TEST和置信区间的计算没有AB平台不代表你不能用Excel做分析。Excel自带统计分析函数分子够用了。假设你有两组数据对照组转化结果0或1实验组转化结果0或1。可以用T.TEST函数直接得到P值用法是T.TEST(array1, array2, tails, type)其中tails填2表示双尾检验type填2表示等方差双样本检验如果你不确定方差是否相等可以直接用type3也就是异方差双样本检验更稳妥一些。用起来大概是这样T.TEST(B2:B6501, C2:C6501, 2, 3)除了P值还可以算置信区间。置信区间的公式是[diff±t_{1-α/2} * SE]其中diff是两组转化率的差值SE是差值的标准误标准误的计算公式是[ SE \sqrt{\frac{p_1(1-p_1)}{n_1} \frac{p_2(1-p_2)}{n_2}} ]Excel里你可以手动拆开算也可以直接定义几个单元格存中间结果。虽然Excel做不到像专业统计软件那样一个函数全搞定但胜在随处可用、随时可分享。很多业务方的小伙伴本来对Python一窍不通但用Excel的T.TEST函数完全没问题。5.3 Python和R用代码让实验分析标准化如果你的数据量很大或者你想把结果做成自动化的分析报告那建议用Python。核心用到的库是scipy和statsmodels。import numpy as np from scipy import stats from statsmodels.stats.proportion import proportion_confint, test_proportions_2indep # 假设数据control和treatment分别是两个组的用户是否转化0/1 control np.array([0, 1, 0, 1, 1, 0, ...]) treatment np.array([1, 1, 0, 0, 1, 1, ...]) c_conv, t_conv control.mean(), treatment.mean() c_n, t_n len(control), len(treatment) # 两组转化率差异的置信区间 diff t_conv - c_conv ci_low, ci_high proportion_confint( countt_conv * t_n, nobst_n, methodwald ) # 精确一点的差异检验 z_stat, p_value test_proportions_2indep( count1t_conv * t_n, nobs1t_n, count2c_conv * c_n, nobs2c_n, alternativetwo-sided )如果你用R做分析代码甚至更简洁# 转化数据0/1 control - c(0, 1, 0, 1, 1, ...) treatment - c(1, 1, 0, 0, 1, ...) # t检验 t.test(treatment, control, alternative two.sided) # 或者用prop.test做比例差异检验 prop.test( c(sum(treatment), sum(control)), c(length(treatment), length(control)) )说实话我自己的经验是除非是非常规的实验比如需要用贝叶斯方法做序贯检验否则复杂的统计模型在AB测试的场景下并没有很大用武之地。Z检验和t检验的差异在实际的大样本场景下可以忽略不计。工具只是载体真正让你的实验靠谱的仍然是前面那三节讲的内容正确的实验设计、足够的样本量、以及干净的数据。5.4 SQL端的数据提取你避不开的基础能力做AB测试分析数据不可能每次都用Excel让你手动粘贴。你在数仓里按实验ID和用户维度把数据提取出来才是分析的正规流程。如果已经把实验分桶信息user_id和对应的group写入了数据表那SQL取数其实很简单。大致思路是用下面的查询把两个组的整体转化情况汇总出来select group_name, count(distinct user_id) as uv, count(distinct case when converted 1 then user_id end) as converted_users from experiment_data where exp_id exp_20240101_01 group by group_name只要数据管道是干净的这一步就是纯体力劳动。但很多人忽略了一个细节取数的用户范围要和你定义的分析单元保持一致。如果你的实验单元是user_id那么分母必须是user_id的distinct count不能是event数量否则一个用户点了10次就算10个样本数据会被重复计算扭曲。6. 案例复盘一次按钮文案AB测试的完整记录最后用一个真实的项目复盘来把上面的知识点串起来。这是之前我在某个SaaS产品团队时做的一次实验目标是提升注册转化率。6.1 背景和假设为什么想改按钮文案产品的主页注册表单核心行动按钮文案一直是免费注册。我们在用户访谈中发现相当多的C端用户对注册这个词天然有心理障碍觉得注册绑定手机号以后会被营销信息骚扰。但产品的核心卖点是先试用核心功能所以我们提出假设把按钮文案从免费注册改成开始免费试用能降低用户的心理门槛从而提升注册转化率至少10%相对提升。这个假设有明确的心理机制支撑也有用户调研数据做铺垫不是拍脑袋决定的。6.2 实验设计和样本量计算核心指标是注册转化率完成注册的用户/访问表单页的用户护栏指标是注册后的次日留存率和试用转化率。用user_id做分流单元哈希分流各50%。实验周期计划14天覆盖两个周末。样本量计算沿用之前的公式历史数据显示表单页访问到注册的基线转化率是7.2%我们想检测的相对提升10%对应的绝对提升是0.72个百分点也就是实验组目标转化率7.92%。代入公式α0.05β0.2[ n \frac{(1.96 0.84)^2 \cdot [0.072 \times 0.928 0.0792 \times 0.9208]}{(0.0792 - 0.072)^2} \approx \frac{7.84 \times 0.1398}{0.0000518} \approx 21100 ]每组需要约2.11万个样本。当时产品的日均表单页访问量约为4000两组各2000算下来要跑10天以上。所以14天的设计是够用的。6.3 实验结果和解读实验结束后我拉取了两组14天的累计数据指标对照组免费注册实验组开始免费试用访问用户数27,82128,104完成注册用户数2,0032,176注册转化率7.20%7.74%次日留存率41.3%40.9%试用转付费率3.1%3.2%差值为0.54个百分点相对提升7.5%P值用Z检验算出来约为0.018小于0.05统计显著。但注意我们之前的假设是至少提升10%才值得上线现在实际的相对提升是7.5%没有达到预设的最小效应量。再看置信区间。0.54个百分点的95%置信区间约为[0.09%0.99%]下限非常接近0。这意味着我们有95%的把握认为真实提升在0.09到0.99个百分点之间——有提升但提升幅度很可能并不大。这时候我反而把专业判断的重点放在护栏指标上。次日留存率、试用转付费率虽然差了一点点但没有统计显著差异说明改动没有伤害到用户体验这是最大的好消息。6.4 最终的决策思考按照严格的达到最小效应量标准这个实验应该算不具备上线价值。但是实际决策时我没有这么机械。我们找到用户访谈的定性证据支持注册这个说法劝退了一部分用户现在数据虽然未达到预期的10%但方向正确、护栏无伤、成本极低改一个按钮文案的开发工作量可以忽略不计。最后我们做出的决策是先全量上线同时继续追踪上线后一个月的数据重点观察留存曲线会不会出现衰减——如果留存下来了说明不是新鲜感效应如果衰减了再回滚也不是什么大事。这个案例我想说明的是AB测试的结论不能代替业务判断。统计工具能帮你把不确定性量化出来但它不会替你回答值不值得做这个问题。最终上线还是放弃本质是个商业决策。我在实际做实验分析时还有一个体会每次实验结束都应该把实验的假设、数据、结论、决策沉淀成一份简洁的实验报告放进实验库。时间长了这个实验库就变成了团队的决策资产库。你以后再做类似的方向直接翻实验库能省去大量重复试错的成本。这也是我从这么多AB测试项目里学到的最值得坚持的一件事。
数据分析对比法：从随机波动到统计显著的AB测试完整指南
你是不是也遇到过这种情况辛辛苦苦做了两个方案拿给同事看同事说我觉得B好拿给老板看老板说还是A稳妥一点——最后谁都说服不了谁。在很多公司里这种争论最后都变成了谁嗓门大听谁的。但如果你懂数据分析手里握着对比法这个工具情况完全不一样。同样的争论你可以直接甩出一句话别争了跑个AB test吧。对比法在数据分析里属于最基础但又最容易被用歪的方法。很多人觉得对比法就是拉两个数出来比大小今天比昨天涨了A方案比B方案点击率高然后结论就出来了。但真正的对比法尤其是AB测试讲究的是控制变量和统计显著性否则你看到的差距很可能只是随机波动。这篇东西我想系统聊一聊数据分析里的对比法核心讲透AB测试——从统计原理到完整的落地流程再到实际工作中最容易踩的坑。不管你是做产品、运营还是数据岗位这篇内容都值得读完尤其是那些正准备在公司里推AB测试但不知道从哪下手的人。1. 对比法不只是拉数据比大小三种对比方式的边界1.1 纵向对比、横向对比和正交对比我在带团队的时候发现一个很典型的现象很多刚入行的数据分析师一说对比法想到的就是和上周比和竞品比。这两种对比方式确实有用但它们解决的是完全不同的问题而且都有自己解决不了的盲区。纵向对比看的是时间趋势。比如你这个月销售额比上个月涨了15%你得出结论增长不错。但是这个增长到底是季节因素带来的还是因为你上个月上线的新功能起效了纵向对比回答不了这个问题因为时间维度上变的东西太多了——季节、市场环境、用户习惯、竞品动作全都混在一起。横向对比看的是同一时间不同对象之间的差异。比如你和竞品都做了618活动你的转化率是5%竞品是7%说明竞品做得比你好。但这个好是因为它的活动机制更好还是因为它的用户体量更大、品牌更强横向对比同样回答不了因果问题。这时候就需要第三种对比方式——正交对比也就是AB测试。AB测试的核心逻辑是把所有用户随机分成两组一组看A方案一组看B方案其他所有条件保持一致。因为分组是随机的两组用户的理论特征几乎完全一样所以实验组和对照组之间唯一的系统性差异就是那个被改变的变量。这样一来你看到的差异就可以有底气地归因于这个变量的变化。1.2 AB测试适用和不适用哪些场景AB测试听起来很万能但实际场景里它边界感很强。适合做AB测试的场景有几个特征第一有足够的流量不管用户量够不够支撑起统计显著性第二决策是增量式的比如改个按钮颜色、调一下推荐策略、换个文案、改一版首页布局第三迭代频率高能用小步快跑的方式持续优化。不适合的场景也很多。比如你的产品还在冷启动阶段DAU只有几百个硬跑AB测试没有任何统计意义——这个后面我会用公式给大家算清楚为什么。再比如你要做的是一次全新的、品牌层面的战略转型这种整体性变革根本没法拆成可对照的变量。还有一种情况没人提但是很常见业务方其实心里已经有决定了跑AB测试只是想拿数据证明自己的决定是对的这种先有结论后有实验的做法不光浪费时间而且非常容易在实验设计上作弊。1.3 为什么AB测试是归因分析里最干净的方案数据分析做到深处核心就是归因到底什么动作带来了什么结果日常工作里我们做的很多分析比如漏斗分析、路径分析、留存分析本质上都只是在描述发生了什么而不是证明为什么发生。要真正验证因果关系最好的工具还就是AB测试。它的干净来自于随机分流这把保护伞。随机化能有效排除已知和未知的混杂变量影响——注意未知这两个字这是AB测试和任何事后分析方法最本质的区别。你做回归分析的时候能控制的可观测变量有限模型永远存在遗漏变量偏误的可能而AB测试不需要你事先把所有混淆因素都识别出来只要分组是真正的随机理论上混杂因素在两组之间是均匀分布的。这也是为什么业内常说AB测试是因果推断的黄金标准。2. AB测试背后的统计逻辑为什么不能看数字大小下结论2.1 随机波动是一切AB测试需要面对的基本问题我在知乎上见过不少这种问题活动页A方案转化率8.3%B方案7.9%是不是说明A更好很多小公司的决策者就是这么干活的——看一个统计报表谁数字大选谁。但问题是这0.4个百分点的差距可能根本不是方案优劣带来的它就是纯粹的随机波动。打个比方你把一枚理论上完全均匀的硬币抛100次理论上正面应该是50次但如果哪次抛出来正面只有45次你会觉得这枚硬币有问题吗不会。因为你知道随机波动天然存在。AB测试面对的是同一个问题用户行为本身充满了随机性哪怕两个方案完全一样也就是你做了AA测试你拿到的转化率数字也会天然有高有低。问题在于我们要怎么判断这个差距到底是随机波动还是真实差异2.2 假设检验和P值的本质理解这时候就要搬出统计学了。AB测试的本质是一个假设检验。你有一个原假设H0两个方案没有差异一个备择假设H1两个方案有差异。你通过收集数据来检验如果H0成立的情况下出现当前这么大数据差异的概率有多大这个概率就是P值。很多人对P值有误解以为P值代表A方案比B方案好的概率这个理解是错的。P值的准确定义是在假设两个方案本身没有差异的前提下由于随机波动观察到当前这么大或更大差异的概率。如果这个概率只有2%说明两个方案无差异这个假设不太站得住脚因为如果真没差异你很难看到这么大的差距——所以你倾向于拒绝H0认为两个方案真的有差异。传统的判断标准是P 0.05也就是显著性水平α0.05。意思是说我愿意承担5%的误杀风险也就是说哪怕两个方案其实没差异我也有5%的概率仅凭随机波动就得出了有差异的结论。这个5%是第一类错误也叫弃真错误。2.3 统计功效别等到实验做完了才发现样本量不够和第一类错误对应的还有第二类错误取伪错误它指的是两个方案其实有差异但因为样本量不够大你的实验没能检测出这个差异。这个错误的概率用β表示统计功效就是1-β业内通常要求至少达到80%。结合两类错误来看就能回答一个常见的问题AB测试要跑多久、需要多少样本量答案取决于四个因素基线转化率p1、你想检测的最小效应量δ、显著性水平α通常0.05、统计功效1-β通常0.8。样本量估算公式长这样两组独立比例检验的情形[ n \frac{(z_{1-\alpha/2} z_{1-\beta})^2 \cdot [p_1(1-p_1) p_2(1-p_2)]}{(p_1 - p_2)^2} ]看着吓人用起来其实不难。举个例子你的旧页面转化率p120%你想检测出至少2个百分点的绝对提升也就是p222%α0.05β0.2查正态分布表可得z_1-α/2≈1.96z_1-β≈0.84代入公式[ n \frac{(1.96 0.84)^2 \cdot [0.2 \times 0.8 0.22 \times 0.78]}{(0.22 - 0.20)^2} \frac{7.84 \times 0.3316}{0.0004} \approx 6500 ]每组大概需要6500个样本两组加起来13000左右。如果你们产品一天只有2000个访问用户意味着这个实验至少得跑一周。如果我想检测更小的效应量比如1个百分点那算出来每组需要2.4万样本时间顿时翻了四倍。这就是为什么业内常说AB测试是一个耗时间的细活。2.4 置信区间比P值更有信息量P值给出的是一个二元判断显著或者不显著。但实际业务决策时光知道一个二元结论远远不够。这就是为什么资深数据分析师一定会看置信区间。置信区间给你的是一个范围真实效应量有多大的可能性落在这个区间内。比如你算出实验组转化率比对照组高1.5个百分点95%置信区间是[0.3%2.7%]意思是你有95%的把握认为真实的提升量在0.3到2.7个百分点之间。这个信息量比单纯一个P0.02大得多——它告诉你效果的下限和上限。如果区间下限是0.3个百分点虽然显著但可能这个提升值不值得你付出那么高的开发成本去全量上线这就是业务判断的问题了。如果你双击几个核心指标每次都用置信区间去看你会比那些只看P值的人敏锐很多。3. 从假设到数据回流一个AB测试的完整实施流程3.1 提出假设用业务逻辑驱动实验设计很多初学者喜欢先跑起来再说但真正有价值的AB测试都始于一个清晰的假设。假设的基本格式是因为某个用户痛点如果做出某个改变会对某个指标产生怎样的影响。举个例子你要优化注册页的转化率。但不加思考地改就是耍流氓。正确的做法是先做用户调研、看用户录屏、分析流失用户的路径发现一个可能的痛点用户对填写资料过长感到厌烦。基于这个洞察你的假设可以是把注册表单从10个字段减少到4个字段能提高注册转化率至少10%。实验目的清晰了后面设计起来就有方向感。写假设的时候顺便把下面几个问题一起想清楚这次改动预期的受益人群是谁会不会有一部分用户反而受影响例如表单缩短了可能进来的用户变多但线索质量可能下降——这就是你需要同时设计护栏指标的原因后面会讲。3.2 指标选择核心指标和护栏指标缺一不可AB测试最忌讳只盯着一个指标看。单一指标被优化、其他指标崩掉的例子在行业内一抓一大把。比如你把首屏的促销弹窗做得更激进了点击率确实上去了但用户次日留存下来了甚至卸载率上去了——这种实验如果只看点击率你会误以为做对了。正确做法是至少设计两层指标。第一层是核心指标也就是你这个实验最想优化的那个北极星指标比如注册转化率、下单转化率、付费率等。第二层是护栏指标用来保证你不能为了优化核心指标而伤害用户体验或长期价值比如客单价、次日留存率、NPS、卸载率等。核心指标变好的同时护栏指标不能显著变差这是AB测试结果可以全量上线的底线。3.3 分流设计与实验单元用户ID、设备ID还是浏览器会话分流单元决定了一个用户算几个样本这是设计阶段特别容易翻车的一环。常见的选择有用户ID、设备IDdevice_id和浏览器会话session。如果你做的是注册转化率实验实验单元一定是人——一个注册用户只能被分到一组。如果你用session来分同一个用户的多次访问可能被分到不同组导致一个用户在不同组的体验不一致数据被污染。再比如你做的是推荐策略实验同一个用户多设备登录的情况很多用user_id分流比device_id更准确。反过来说如果你的产品没有用户体系比如一个纯工具类的匿名站点那只能用device_id或者cookie来做近似。分流不均匀也是个很常见的问题。理想情况下两组占比应该是50/50但因为某些技术原因可能出现45/55甚至更夸张的偏差。这种情况下实验结果就不可信了因为分流本身可能就引入了偏差。我在第五节还会专门讲SRM的问题。3.4 实验时长不只是算够样本量算出样本量只是实验时长下限的参考实际跑实验的时间要更长。以下几个因素必须考虑进去第一覆盖完整的业务周期。电商产品必须覆盖一个完整的周末因为周末和平时用户结构不同如果你的目标是提升付费转化最好跑满一个月的完整周期覆盖发薪日前后用户消费能力差异这样的周期波动。第二过滤新鲜感效应。一个新上线的东西用户一开始的反应往往和他们的长期行为背离。按钮变红了可能一开始大家都点一下但几天后用户就适应了回归正常水平。所以实验时间不能太短要等用户行为稳定下来。第三反作弊和数据清洗需要时间。垃圾流量、爬虫、异常ID都要剔除后再分析这些都要预留时间。3.5 埋点验证与数据回流实验跑起来不等于万事大吉实验上线不等于接下来就等着收数据了。上线后的第一天到第三天是最关键的验证窗口期。你需要确认两组用户的实际分流比例和预期一致实验组用户真的看到了实验版本而不是旧版本核心事件的上报数据是否在正常回流有没有明显的埋点丢失问题。这些听起来像废话但我做过的很多项目中都有几次差点带着错误数据得出错误结论。印象最深的一次是我们用前端埋点做实验结果遇到某个浏览器版本缓存了旧JS文件导致20%的实验组用户实际跑的还是旧页面——如果没在前期发现实验跑完直接分析结果就是废物。现在我们的团队有个约定俗成的规矩实验上线48小时后进行第一轮数据质量检查查三项内容——分流比是否接近预期、暴露量实验组PV/UV是否正常、事件量核心埋点是否有断裂全部通过才允许实验继续跑。4. 结果解读不能只看P值五个反复出现的坑4.1 显著性不等于业务显著性p0.049和p0.052没有本质区别这是一个统计学家看了会叹气的现象有些团队把P0.05当成一道铁闸P0.049大喊效果显著全量上线P0.052就说不显著换方向。但P值本身就是一个连续的值在0.05附近反复横跳是非常常见的。你只要再多积累几百个样本P值可能就跨过这条线了反过来也一样可能本来0.049的结果多跑一天变成0.06。真正理性的做法是把重点放在效应量和置信区间上。如果效应量很小比如提升0.01个百分点哪怕它统计显著到P0.001这个实验对业务来说也没有价值——不值得为你做一次的改动付那么多开发成本。反过来如果效应量很大但暂时不显著说明可能是样本量不足、统计功效不够这时应该延长时间而不是急着下判断。我个人的标准是P值显著效应量达到事前设定的最小预期值置信区间下限可接受三者同时满足我才会建议全量上线。只满足前两个会建议再做一轮验证实验只满足第一个直接放弃考虑。4.2 多重比较问题实验组内部塞了太多变体实验组不只有A和B可以同时测试多个变体——这就是多重比较。比如你想试4种不同的落地页标题于是你跑了一个A vs B vs C vs D的实验。问题来了你做了4次比较按照α0.05的标准至少出现一次假阳性的概率就不是5%了而是(1-(1-0.05)^4 ≈ 18.5%)左右。换句话说你每做一次这样的多组实验就有接近五分之一的概率纯靠随机波动发现一个显著的结果。解决思路有几个最简单的做法是用Bonferroni校正也就是把显著性水平调整为α/nn是比较次数。但这个方法的代价是放大了第二类错误让你更不容易发现真实存在的差异。更推荐的做法是如果你想测多个变体先做一个小流量的筛选实验把明显表现差的变体淘汰掉只留下最有希望的1-2个进行第二次完整实验这样能有效控制多重比较带来的风险。4.3 辛普森悖论分组看和总体看结论完全相反辛普森悖论是归因分析里最有迷惑性的问题之一在AB测试结果解读里同样适用。它描述的现象是在总体数据上A方案比B方案表现好但你把用户按照某个维度比如新老用户、渠道来源、设备类型拆分后每个子群里都是B方案表现更好——整体和局部的结论完全相反。这个悖论听起来反直觉但在实际业务中很常见。比如你的实验组被分到了更多高价值的老用户虽然总体比例均衡但在某个子群内不均衡而老用户整体转化率就是比新用户高于是实验组的整体数据被拉高了。表面上看是方案有效实际上是分流导致了用户结构异常。怎么预防和处理这个坑第一在分流时做分层抽样确保关键用户维度新老、渠道、机型在两组间的分布基本一致第二在分析结果时如果条件允许先做分组分析再看整体结论是否和分组结论一致如果矛盾要顺着矛盾查下去找到原因再下结论。4.4 新奇效应和厌恶效应用户对变化的短期反应不等于长期反应新奇效应指的是新方案刚上线时用户因为新鲜感而表现出异常的积极参与度短期内实验组指标很好看但过一段时间就回落了。厌恶效应则相反——改动刚出现时用户不适应甚至反感到直接流失但如果坚持一段时间用户其实能逐渐接受长期指标反而是好的。这两个效应对AB测试的直接影响就是实验时长太短会导致结论失真。我见过一个团队跑文案测试只跑了三天实验组点击率比对照组高30%团队兴奋地全量上线了结果两周后点击率不仅没保住优势反而比原来还低了。正确的做法是实验室外延长至少覆盖到用户行为趋于稳定的时间点。如果你怀疑存在新鲜感效应可以用滑动窗口法按天看核心指标的趋势确认实验组相对对照组的优势是否在衰减衰减到什么程度。4.5 SRM样本比率不匹配意味着整个实验作废SRMSample Ratio Mismatch是一个比较专业的概念简单说就是在理想分流比例下你期待每组各占50%流量但最终收集到的数据里访客数或者是事件数明显偏离了这个预期比例——比如一组60%、一组40%。SRM一旦发生说明实验中可能存在系统性偏差这个实验结果就直接作废不用再看P值了。SRM的产生原因五花八门其中一个方案有严重bug导致一部分用户无法加载页面某个实验组对于低版本浏览器不兼容用户直接流失埋点上报逻辑不同步导致一个组的曝光事件大量丢失又或者是反作弊系统对不同组进行了不同力度的过滤。所以每次实验分析前我建议先把分流比做单一样本比例检验可以用卡方检验如果P值小于0.05直接判定SRM然后回头查数据采集链路。5. 没有专业AB平台怎么用现成工具做靠谱实验5.1 基于用户ID的哈希分流最简单的实现方式很多中大型团队会购买或者自建专门的AB测试平台功能挺全面的。但如果你所在的是一个小团队连AB测试平台都没有也用不着推翻重来——只要你的产品有用户ID体系你完全可以用哈希算法自己做分流。核心思路很简单对每个用户的唯一标识比如user_id计算哈希值把哈希值映射到一个0到99的整数很好懂对吗比如哈希值对100取模后小于50的分到对照组大于等于50的分到实验组。这样每一个用户都有稳定且唯一的组别归属多次访问不会发生漂移。代码实现我贴一个简单的Python版本大家可以参考一下import hashlib def assign_group(user_id: str, split_ratio: float 0.5) - str: # 使用MD5哈希取模保证用户分组的确定性 hash_value int(hashlib.md5(user_id.encode(utf-8)).hexdigest(), 16) if hash_value % 1000 split_ratio * 1000: return control return treatment注意几个细节一是哈希函数要选择均匀分布的MD5或者SHA-256都行用内置的hash()函数不稳定不同进程的种子不同会导致同一个用户被分到不同组。二是盐值salt可以用实验编号这样不同的实验之间用户分组是独立的比如实验1的用户和实验2的用户在同一个人身上可能分到不同组这是正交实验设计的思路。分流做完之后你需要在前端或者后端记录每个用户被分配到的组别信息然后数据落到数仓后续的分析环节就可以用这个组别字段取数了。5.2 Excel里的快速分析T.TEST和置信区间的计算没有AB平台不代表你不能用Excel做分析。Excel自带统计分析函数分子够用了。假设你有两组数据对照组转化结果0或1实验组转化结果0或1。可以用T.TEST函数直接得到P值用法是T.TEST(array1, array2, tails, type)其中tails填2表示双尾检验type填2表示等方差双样本检验如果你不确定方差是否相等可以直接用type3也就是异方差双样本检验更稳妥一些。用起来大概是这样T.TEST(B2:B6501, C2:C6501, 2, 3)除了P值还可以算置信区间。置信区间的公式是[diff±t_{1-α/2} * SE]其中diff是两组转化率的差值SE是差值的标准误标准误的计算公式是[ SE \sqrt{\frac{p_1(1-p_1)}{n_1} \frac{p_2(1-p_2)}{n_2}} ]Excel里你可以手动拆开算也可以直接定义几个单元格存中间结果。虽然Excel做不到像专业统计软件那样一个函数全搞定但胜在随处可用、随时可分享。很多业务方的小伙伴本来对Python一窍不通但用Excel的T.TEST函数完全没问题。5.3 Python和R用代码让实验分析标准化如果你的数据量很大或者你想把结果做成自动化的分析报告那建议用Python。核心用到的库是scipy和statsmodels。import numpy as np from scipy import stats from statsmodels.stats.proportion import proportion_confint, test_proportions_2indep # 假设数据control和treatment分别是两个组的用户是否转化0/1 control np.array([0, 1, 0, 1, 1, 0, ...]) treatment np.array([1, 1, 0, 0, 1, 1, ...]) c_conv, t_conv control.mean(), treatment.mean() c_n, t_n len(control), len(treatment) # 两组转化率差异的置信区间 diff t_conv - c_conv ci_low, ci_high proportion_confint( countt_conv * t_n, nobst_n, methodwald ) # 精确一点的差异检验 z_stat, p_value test_proportions_2indep( count1t_conv * t_n, nobs1t_n, count2c_conv * c_n, nobs2c_n, alternativetwo-sided )如果你用R做分析代码甚至更简洁# 转化数据0/1 control - c(0, 1, 0, 1, 1, ...) treatment - c(1, 1, 0, 0, 1, ...) # t检验 t.test(treatment, control, alternative two.sided) # 或者用prop.test做比例差异检验 prop.test( c(sum(treatment), sum(control)), c(length(treatment), length(control)) )说实话我自己的经验是除非是非常规的实验比如需要用贝叶斯方法做序贯检验否则复杂的统计模型在AB测试的场景下并没有很大用武之地。Z检验和t检验的差异在实际的大样本场景下可以忽略不计。工具只是载体真正让你的实验靠谱的仍然是前面那三节讲的内容正确的实验设计、足够的样本量、以及干净的数据。5.4 SQL端的数据提取你避不开的基础能力做AB测试分析数据不可能每次都用Excel让你手动粘贴。你在数仓里按实验ID和用户维度把数据提取出来才是分析的正规流程。如果已经把实验分桶信息user_id和对应的group写入了数据表那SQL取数其实很简单。大致思路是用下面的查询把两个组的整体转化情况汇总出来select group_name, count(distinct user_id) as uv, count(distinct case when converted 1 then user_id end) as converted_users from experiment_data where exp_id exp_20240101_01 group by group_name只要数据管道是干净的这一步就是纯体力劳动。但很多人忽略了一个细节取数的用户范围要和你定义的分析单元保持一致。如果你的实验单元是user_id那么分母必须是user_id的distinct count不能是event数量否则一个用户点了10次就算10个样本数据会被重复计算扭曲。6. 案例复盘一次按钮文案AB测试的完整记录最后用一个真实的项目复盘来把上面的知识点串起来。这是之前我在某个SaaS产品团队时做的一次实验目标是提升注册转化率。6.1 背景和假设为什么想改按钮文案产品的主页注册表单核心行动按钮文案一直是免费注册。我们在用户访谈中发现相当多的C端用户对注册这个词天然有心理障碍觉得注册绑定手机号以后会被营销信息骚扰。但产品的核心卖点是先试用核心功能所以我们提出假设把按钮文案从免费注册改成开始免费试用能降低用户的心理门槛从而提升注册转化率至少10%相对提升。这个假设有明确的心理机制支撑也有用户调研数据做铺垫不是拍脑袋决定的。6.2 实验设计和样本量计算核心指标是注册转化率完成注册的用户/访问表单页的用户护栏指标是注册后的次日留存率和试用转化率。用user_id做分流单元哈希分流各50%。实验周期计划14天覆盖两个周末。样本量计算沿用之前的公式历史数据显示表单页访问到注册的基线转化率是7.2%我们想检测的相对提升10%对应的绝对提升是0.72个百分点也就是实验组目标转化率7.92%。代入公式α0.05β0.2[ n \frac{(1.96 0.84)^2 \cdot [0.072 \times 0.928 0.0792 \times 0.9208]}{(0.0792 - 0.072)^2} \approx \frac{7.84 \times 0.1398}{0.0000518} \approx 21100 ]每组需要约2.11万个样本。当时产品的日均表单页访问量约为4000两组各2000算下来要跑10天以上。所以14天的设计是够用的。6.3 实验结果和解读实验结束后我拉取了两组14天的累计数据指标对照组免费注册实验组开始免费试用访问用户数27,82128,104完成注册用户数2,0032,176注册转化率7.20%7.74%次日留存率41.3%40.9%试用转付费率3.1%3.2%差值为0.54个百分点相对提升7.5%P值用Z检验算出来约为0.018小于0.05统计显著。但注意我们之前的假设是至少提升10%才值得上线现在实际的相对提升是7.5%没有达到预设的最小效应量。再看置信区间。0.54个百分点的95%置信区间约为[0.09%0.99%]下限非常接近0。这意味着我们有95%的把握认为真实提升在0.09到0.99个百分点之间——有提升但提升幅度很可能并不大。这时候我反而把专业判断的重点放在护栏指标上。次日留存率、试用转付费率虽然差了一点点但没有统计显著差异说明改动没有伤害到用户体验这是最大的好消息。6.4 最终的决策思考按照严格的达到最小效应量标准这个实验应该算不具备上线价值。但是实际决策时我没有这么机械。我们找到用户访谈的定性证据支持注册这个说法劝退了一部分用户现在数据虽然未达到预期的10%但方向正确、护栏无伤、成本极低改一个按钮文案的开发工作量可以忽略不计。最后我们做出的决策是先全量上线同时继续追踪上线后一个月的数据重点观察留存曲线会不会出现衰减——如果留存下来了说明不是新鲜感效应如果衰减了再回滚也不是什么大事。这个案例我想说明的是AB测试的结论不能代替业务判断。统计工具能帮你把不确定性量化出来但它不会替你回答值不值得做这个问题。最终上线还是放弃本质是个商业决策。我在实际做实验分析时还有一个体会每次实验结束都应该把实验的假设、数据、结论、决策沉淀成一份简洁的实验报告放进实验库。时间长了这个实验库就变成了团队的决策资产库。你以后再做类似的方向直接翻实验库能省去大量重复试错的成本。这也是我从这么多AB测试项目里学到的最值得坚持的一件事。
