A/B 实验说新版本更好，上线却没效果：分流、样本量与指标口径该先定哪一条

实验后台显示提升了，全量放开两周后曲线回到原点

实验后台给出的结论很漂亮：新版本的注册转化率被抬了上去，置信区间没有碰到零，看板上的那条线一路向上。团队按流程全量放开，两周以后再拉大盘，同一条曲线回到原点，甚至比实验之前还低了一点。复盘会上被翻出来的不是策略本身，而是分流日志——分流键用的是会话 ID，同一批老用户在两天之内来回跨了三个版本，所谓的实验组里混进了大量既见过新版也见过旧版的人，对照组同样如此。那个被开会通过并写进复盘文档的提升，本质上是两个被污染过的桶之间的一次随机差。

这件事的价值在于它指出了一个反常识的事实：实验结论可不可信，和流量规模之间没有必然关系。一个每天几十万流量的实验，如果分流失稳、指标事后挑选、样本量没有事先算过，它只是更快地得出一个错误结论——大流量带来的是更窄的置信区间，而更窄的置信区间包着一个偏掉的中心值，读起来反而更像真的。这也是为什么"实验赢了、上线没效果"这件事在数据量很大的团队里照样频繁发生。

本文要立的判断只有一句：A/B 实验的可信度取决于三条，而不是流量大小——分流的确定性与稳定性、指标的事先定义与护栏、样本量与观察周期在开跑之前就定死。这三条没定，流量再大也只是加快出错的速度。后面所有内容都围绕这条线展开，并且会在最后落到这些机制在自己的服务器上会消耗什么资源。

分流键选会话 ID 还是用户 ID，决定的是同一用户会不会跨版本

分流键是整个实验里最早被决定、又最晚被复盘的东西。它只回答一个问题：同一个人，在第一天和第七天，会不会被判给同一个版本。这个问题的答案直接决定实验有没有意义——如果他在两个版本之间反复横跳，你测量到的就不是"版本对人的影响"，而是"版本在不同人身上的混合切片"。

常见的三类键各有明确的适用边界。用户 ID 或账号维度跨会话最稳定，只要登录态在，同一个人始终待在一个版本里，代价是未登录的那部分流量无法纳入结论；设备 ID 不依赖登录，可以覆盖匿名流量，代价是清缓存、卸载重装、换设备都会让它失效，并且一台共享平板上可能有好几个真实用户，一个键对应多个人本身就是污染；会话 ID 实现成本最低，恰恰是最不该用在用户级实验上的——一次会话通常只有几分钟到几十分钟，同一个人一天里开多次会话是常态，跨版本几乎必然。

怎么选，取决于你要改变的是人的长期行为还是一次访问的短期反应。前者必须用账户或设备这样跨会话稳定的键；后者理论上可以用会话键，但结论不能被外推到留存、复购这些长期指标上去，而绝大多数业务真正关心的恰恰是长期指标。

还有一条工程前置条件经常被跳过：分流键必须早于实验上线就已经存在，并且在数据链路的每一环都能被一致地取到。如果 Web 端读 cookie 里的一套 ID、App 端用另一套设备标识、服务端日志里又是第三套，那么同一个人在三个端就是三个键，跨端一致性无从谈起。跨端实验的第一步是先统一键，而不是先搭实验后台。

哈希取模分桶为什么能保证同一个键每次都落在同一个桶

确定性分桶的做法并不复杂：把实验专属的盐值与分流键拼在一起，经过一个确定的哈希函数映射到一个足够大的整数，再对总桶数取模，得到桶号，最后由一张映射表把桶号对应到版本上。它的关键性质有两条，正好对应实验最需要的两件事。

第一条是确定性。只要输入不变、哈希函数不变、桶数不变，输出就永远相同。这意味着系统不需要记住上一次把某个人分到了哪里，不需要维护一张用户到版本的映射表，也不依赖某一台机器的本地状态。由此带来的第二个好处是横向一致：多台应用服务器、多个机房节点各自独立计算，得到的答案一模一样，不需要在它们之间同步分配结果，也不会因为某次请求被调度到另一台机器而换版本。

第二条是均匀性。好的哈希会把键打散到各个桶里，桶与桶之间的人数接近设计比例，这是统计检验成立的前提之一。总桶数通常取一个远大于实际需要的数，把其中连续的一段分配给实验组、另一段给对照组，而不是每次动态调整。

每个实验配一个独立的盐值，理由经常被忽略：如果所有实验共用同一套哈希空间且不加盐，实验甲的"第一桶"永远是一小撮固定的人，实验乙的"第一桶"也是同一撮人，两个实验的分组就高度相关，等于让同一批人长期承担所有实验的负面风险，也让跨实验的结论无法叠加。加盐让不同实验的划分互相错开。

由此推出一条操作纪律：实验期间不得修改哈希函数、不得修改总桶数、不得修改版本的桶区间映射。改一次，所有人重新洗牌，正在跑的实验直接作废，而这类改动往往发生在"顺手重构了一下分流模块"这样看起来无害的动作里。

确定性分桶会失效的三种情况：登录态切换、换设备、清缓存

哈希保证了输入不变则输出不变，麻烦在于现实里的输入不那么容易保持不变。三种失效场景下，同一个人会被系统当成不同的人。

第一种是未登录转登录。访客用设备 ID 进的实验，注册之后账号体系接管，分流键从设备 ID 切到用户 ID，哈希输入变了，桶就可能变了。更麻烦的是它的位置：很多产品的核心转化动作本身就是注册或登录，也就是说恰恰在最重要的那一步，分流键发生了切换，你在测量一个同时改变了测量对象的过程。这类问答只有两条现实出路——全程以设备 ID 为准，把登录后的行为绑回同一个设备；或者把未登录流量整体排除出用户级实验，只对有账号的人群做结论，代价是结论不能外推到新客。

第二种是换设备。同一个人在手机、平板、办公机和家用机上产生行为，如果不能把这些线索聚合起来，他在实验里就是四个人。跨设备识别本身是一个独立的工程难题，不要指望 A/B 分流顺手解决它。可行的处理是把无法跨设备合并这件事明确写进实验文档的假设里：你的结论适用于设备维度，不代表自然人维度。

第三种是标识被重置。用户主动清缓存、卸载重装、浏览器对第三方 cookie 的限制收紧、系统层面的广告标识授权变化，都会让"这个人"在下一次访问里变成陌生人，然后被当成新用户重新分桶。这类现象无法彻底消除，只能减轻：尽量使用第一方持久化的标识，并在新老标识之间维护一次性的映射关系。

这三种失效都不是理论风险，而是可以直接查的。实验开跑后抽一批日志，统计同一个账号或同一个可识别自然人，在观察窗口内被分配到过几个不同版本；这个比例只要不接近零，后面讨论指标就是在浪费时间。这是一项廉价的体检，比事后争论提升到底有没有意义有用得多。

先定最小可检测效应，再估样本量，这个顺序反过来就全乱了

样本量不是一个可以先跑起来再补的参数，它是实验设计里第一个应该被写下来的数字。而它本身又依赖三个更早的决策。

第一个是最小可检测效应，也就是 MDE：这次改动至少带来多大的提升，才值得我为它买单。注意这是一个纯粹的商业问题，不是统计问题。如果一个新版本只能把某个漏斗步骤抬升极小一点点，但它引入的复杂度、后续维护成本和沟通成本很高，那么即使这个提升真实存在，也不值得上线——既然不值得上线，就不需要花流量去检出它。

第二个和第三个是显著性水平与统计功效。显著性水平取决于一次"误把没效果的改动判成有效"要付多大代价；功效取决于"漏掉一个真实有效的好改动"要付多大代价。这两个同样是业务参数。把它们放在一起的意义是：不要照抄别人推荐的默认值，要想清楚自己的代价结构。

三个参数定下来之后，样本量就可以估了。这里只需要记住一个不需要任何真实基线就能成立的关系式：所需样本量大致与效应大小的平方成反比——想检出的效应缩小一半，样本量大约要变成四倍；同时，指标本身的波动越大，需要的样本量也越大。这两句是这类检验的结构性结论，不涉及任何具体业务的基线转化率。

正确的顺序因此是：先把 MDE、显著性水平、功效三个数字写进实验设计文档，再由这三个参数和历史波动估算样本量，再由样本量和日均可用流量推算所需天数，最后把这个天数写死。反过来用"我们有多少流量"倒推"我们能检出多小的效应"，等于先有了结论再去找支持它的观测。

"先跑一周看看"为什么是绝大多数错误结论的来源

"先跑一周看看"这句话的问题不在于一周太长或太短，而在于它把判定标准放到了看到数据之后。真正该有的顺序是：算出需要多少样本，算出这批样本需要多少天，然后接受这个天数。如果算出来是三周，那就是三周。

如果三周太长，正确的应对是三选一：换一个能产生更大效应的改动（效应越大，需要的样本越小，这是上面那个平方反比关系的直接推论）、换一个波动更小的指标（比如用一个更靠近动作本身的漏斗步骤替代最终结果）、或者干脆不做 A/B。把周期从三周砍到一周再去看数据，是第四个选项，也是唯一一个必然增加错误率的选项。

最常见的自我安慰是"样本虽然不够，但方向是对的"。方向这个词在统计上没有定义。样本量不足时，观测到的差异里真实效应和随机波动的贡献是不可拆分的；你说它是方向，等于默认了你想要为真的那个结论已经成立。

反过来也要说清楚：不存在一个放之四海而皆准的最小天数。如果改动足够大——比如把一个流程从五步砍到两步——需要的样本本身就不多，一周甚至更短都可能已经足够。所以"必须跑满多少天"不是铁律，铁律是这个天数必须由样本量算出来，而不是由日历习惯推出来。

主指标只能有一个，护栏指标要在开跑之前列成一张清单

主指标是唯一一个用来判定实验成败的数字。它必须直接对应业务目标，在实验期内能被稳定采集，并且不能是"综合评分"——综合评分背后是一组人为权重，把权重放进结论，等于把结论藏在一个可以随手调的参数后面。

护栏指标是不允许变差的那些。常见的有崩溃率、页面加载时长、服务端错误率、关键链路成功率、退款率、客诉率。护栏的作用不是参与判断，而是给"主指标涨了"设定一票否决：一个把转化率拉上去、同时把退款率也拉上去的改动，几乎从来都是坏改动，它只是把成本搬到了另一个部门的下个月报表里。

还有一类被严重低估的检查项应该在看任何业务指标之前完成，那就是样本比例偏差检验，也就是 SRM。设计是五五分账，实际落下来却是四八点七对五一三点，并且超出统计容许范围，说明分流或者上报环节有 bug。此时所有关于"提升"的讨论都建立在流沙上——SRM 不通过时，实验应该直接作废重开，而不是继续解释数据。

"看哪个指标涨了就说哪个"本质上是多重比较

哪怕你把显著性水平设在常用的位置，一次看二十个指标时，即便新旧版本毫无差别，也期望有一个指标看起来显著。指标越多、维度切得越碎（按端、按地域、按新老用户、按渠道、按时段一层层拆开），出现这种"幸运指标"的机会就越多。事后从一堆切片里挑一个赢的出来讲因果，本质上是把随机误差当成功效。

这件事还有一层更隐蔽的变形：先看全局指标不显著，再拆到某个细分人群显著，然后宣布"我们找到了这个改动真正有效的那群人"。除非这个人群是开跑前就写进文档的，否则它同样是事后挑选。

两种正确的处理。一是事前定死看什么：一个主指标加一张护栏清单，事后再有价值的发现也不写进本次结论。二是确有必要做探索性分析时，把探索出来的差异明确标记为假设，用一次全新的独立实验去验证它，而不是直接搬进复盘材料。两种做法的共同点是：发现的过程和验证的过程必须分开。

这也是"实验赢了上线没效果"的另一条常见路径——赢的那个指标本身就是一个被挑出来的幸运儿，它从来就没有真实存在过。

观察周期必须盖住一个完整的业务周期：周循环、月度结算与发薪日

最短要求是盖住完整的周循环，而且必须以整数周为单位，不是滚动七天。工作日和周末的用户构成、行为意图、客单价通常差得很远，只跑周一到周三的实验，结论描述的是工作日用户，周末人群的反应可能方向相反。整数周而不是七天，是为了保证每种星期几被计入的次数相同。

再往上一层是月度周期。如果业务有明显的月初月末效应，比如账期、配额重置、月度结算、会员续费、发薪之后的消费意愿变化，那么一到两周还不够，需要覆盖到那个节点，或者明确在结论里注明"本次未观察到结算周期附近的表现"。承认边界比装作没有边界要好得多。

同时，时长还有上限。跑得太久会引入外部变量：一次季节性波动、一次行业事件、一次版本发布、一次投放策略调整。既然两边都有压力，取舍原则是什么？答案是优先保证两组被放在同一个时间窗口里同时观测。同期对照才是 A/B 相对前后对比最核心的优势——外部事件打到两组身上的时间相同，它对两组的影响是可比的；而"跑得足够久"只是次一级的诉求。两者冲突时保同期，而不是保时长。

只跑三天看到的，通常只是第一天发生了什么

首日偏差值得单列，因为它太容易被当成早期信号。上线头一天的数据通常不代表稳态：缓存没有刷新到全量、一部分用户拿到的还是旧资源、推荐位和排序还在学习阶段、内部同事和种子用户在头几天的占比明显偏高。这几条同时作用，第一天的曲线天然不稳定。

识别办法很朴素：把指标按天拆开看差值随时间怎么走。如果一个提升只存在于第一天或者头两天、之后迅速回落并贴合，那它不是效应，而是上线动作本身带来的噪声。反过来，如果差值在第三天开始才稳定下来并持续存在，那么真正可信的观测窗口其实是从第三天开始，前面的部分应该被剔除或者单独标注。

这也是为什么"最短整数周"是底线而不是建议：一周的长度足以让第一天的噪声在整段平均里被稀释到可接受的水平，而三天的长度做不到。

反复查看、看到显著就停，等价于把显著性阈值放大

中途偷看不是一个道德问题，而是一个可以被说清楚的统计后果。每查看一次，就等于多给了一次判卷机会。检验机会积累得越多，至少有一次越过阈值的累积概率就越高——你在名义上用的还是那个熟悉的阈值，实际承担的整体错误率远高于它。看到显著就停手，等于把这次实验的判定标准交给了随机数。

对应的做法有三层，能接受多少取决于团队的执行力。

最干净的一层：到达既定样本量之前不看业务结论。注意这不等于不看数据——健康类数据应该照常看，包括崩溃、报错、SRM 和资源占用；被禁止查看的是那张判定成败的指标图。

如果必须每天盯，那就用序贯检验的思路：为每一次中途查看支付额外的显著性代价，用随时间逐步加严的判断边界替代固定阈值，把总的错误率控制在预定水平。这里只提这个思路的存在，具体实现涉及边界函数的选取，属于统计工程范畴。

折衷的一层：在文档里预先约定几个固定的检查点，比如在达到设计样本量的三成和六成时允许查看，并且只有在边界被明显突破时才允许提前停止，其余情况一律跑满。把查看次数写死，比把查看冲动压住要现实得多。

多个实验同时跑为什么会互相污染，正交分层和错开人群怎么取舍

同一批用户同时进入多个实验，单个实验的结论未必是假的，但它不可加。甲实验说提升，乙实验说提升，同时上线甲乙之后未必是两者之和，有时互相抵消，有时反而更差。原因有三类：交互效应，两个改动作用在漏斗相邻环节上，前一个改了进入后一个的人群构成；资源挤占，两个实验都要在写入通道和存储上付出代价；用户层面的叠加疲劳，同一批人被反复干预。

正交分层是把流量切成多个独立的层，每层一个实验，层与层之间在同一个哈希空间上通过不同的盐错开，使得层与层之间的分组统计上无关。它的效率最高，可以同时放量，但要求基础设施把每一层的盐、每一层的流量分配和每一层的排除规则管清楚。更重要的是别对它抱有不切实际的期待：正交保证的是不相关，不是没有交互。两个改动在统计上独立，不代表它们放在一起的效果等于单独效果之和。

错开人群是把不同实验放到不相交的人群切片上，每个实验只看自己的那一撮人。解释成本最低，几乎不会互相污染；代价是每个实验可用的流量变小，达到同样样本量需要更长时间，实验吞吐上不去。

取舍上的判断很直接：在基础设施还没有被验证能保证分层正确之前，先错开人群；验证过了再上正交分层，并且在两个改动准备合并上线时，仍然补一次小的验证实验去确认叠加后的实际效果。另外，凡是事先就能看出有强交互的改动——比如都作用在结算页——应该安排成同一层里的串行排期，而不是并行。

老用户第一周的反应不等于第三周的，新用户连基线都没有

新奇效应指的是：任何变化都会吸引注意力。老用户对一个改版的短期反应里，往往混入了"它变了"这件事本身的贡献，而不只是"它更好了"。注意力会随时间回落，行为会回到习惯。这类偏差最常见的结果是短期虚高，但反过来也成立——改变习惯会带来短期抵触，真实收益要到抵触消退之后才显现。

识别的办法是把实验人群按新老用户分层，并观察效应随暴露天数怎么变化。如果差值随暴露天数单调衰减、并在若干天后趋于平稳，那么就应当用后段的稳态值作为最终判断，而不是拿整段的平均值交差。只看用户整体，等于把不同暴露时长的人混在一个平均里，稳态被早期的高值持续稀释。

新用户的问题性质不同。他们没有历史行为基线，无法做自身前后比较，任何"比之前更好"的判断对他们都不成立；同时他们对产品还不熟悉，任何改动的适应成本都很低，容易给出偏乐观的结论。处理方式建议简单粗暴一点：把老用户的稳态值作为上线决策的依据，新用户的结论只作参考；如果改动主要面向新客且老用户样本不足，那就用一次更长的实验去覆盖那些人变成老用户之后的时间。

分流服务挂在关键路径上：多出来的一跳延迟和一个新的故障点

分流的计算放在哪里，是客户端还是服务端，决定了这笔账怎么记。放在客户端，由 SDK 本地算哈希，好处是零额外网络跳数，延迟几乎为零，代价是配置下发依赖拉取策略、规则的实时性差，App 侧的改动还要跟着发版周期走，Web 侧还要处理脚本加载失败时的兜底。放在服务端，规则实时生效、跨端天然一致，代价是每一次需要分流的请求多一次外部调用，等于在关键路径上加了一个依赖。

服务端方案的延迟是怎么被放大的，值得拆开看：一次完整的分流判断通常包含读一次实验配置、一次哈希计算，很多时候还要补一次用户属性查询来做人群定向。这三步的耗时直接叠在接口响应上。而且这个开销会波及没有参与实验的请求——如果所有流量都被要求先过一遍分流层，那么为了百分之几的实验流量，百分之百的请求都慢了一点。

结构上的控制手段有这么几种：配置信息在本地进程内缓存并带版本号和有效期，异步刷新而不是每次请求同步拉取；把确定不需要分流的接口从调用链里摘出去；给这次调用设置严格的超时上限，超过就走默认策略而不是继续等。其中最后一条尤其重要，它把"外部依赖变慢"从一个可用性事故降级成一次可控的降级。

故障点这一侧有一条必须提前约定的东西：分流服务不可用时怎么办。多数情况下的默认应该是不分流，全部走对照组，也就是当前线上正在跑的那个版本。理由是充分的——对照组的表现是已知的，实验组是未知的，在信息缺失时选择已知的那个。反过来把默认设成全部走实验组，只有在对照版本存在严重缺陷需要紧急替换时才说得通，而那时它已经不是实验而是发布决策了。

还要配套一件事：降级期间发生的一切必须被清楚地标记出来。分流服务降级时要有明确的告警，降级期间的曝光数据要在明细里带上标记，以便在分析时剔除。降级期间的数据有没有被计入样本，必须在实验文档里预先写死，通常的结论是不计入——因为这段时间里所有人都在同一个版本上，它既不属于实验组也不属于对照组。

实验事件上报把写入量放大几十到几百倍

每一次曝光、每一次点击、每一次滚动、每一步漏斗停留都要上报，而真正产生收入的动作通常只有一次。这两者之间的差距在量级上是几十到几百倍——这里说的是量级关系，不是一个统计数字，具体落在哪个位置取决于埋点密度和业务类型，不同业务之间可以差得很远。

这个量级差异带来三条硬性要求。第一是通道独立：不要让实验事件和订单写入共用同一条同步写路径。两者的可靠性要求完全不同，事件上报应当是可丢、可延迟、可降采样的，而交易写入必须不丢。把它们放在一条路上，结果要么是为事件付出了不该付的成本，要么是被事件拖累造成交易抖动。

第二是缓冲与批量。客户端在本地聚合之后批量上报，服务端用消息队列做削峰。这里有一个很容易被忽略的连带效应：批量上报意味着数据会晚到，最后一段窗口的明细可能在导出结论时还没到齐。因此"数据可用时间"要相对"实验结束时间"往后推一到两个缓冲周期，否则每次导出都会发现最后一段的样本系统性偏少，而这个偏少在两个组之间未必对称。

第三是采样。对高频低信息量的事件（滚动深度、鼠标移动、无转化的浏览）按可调比例采样是可以接受的，只要采样比例对两组一致，就不会引入偏差；真正需要全量保留的是判定主指标和护栏指标所依赖的那几类事件。

最后一条一致性的坑：分流决定把这个人算进哪个组，上报决定他被写进哪张表里。如果这两件事发生在不同时间点、读的是不同的 ID 取值链路，甚至在不同的服务里用不同的逻辑兜底，就会出现曝光数和转化数对不上的情况。这正是很多团队直到做 SRM 检查才发现的根本原因——问题不在统计模型，在两条链路各算各的。

实验明细不要和业务数据挤在同一个库里

实验分析的查询模式是扫描全量明细做大范围聚合，业务主库的负载画像是在线交易的高频小事务读写，两者几乎相反。把实验明细写进主库的表中，最直接的后果是分析查询吃掉在线库的磁盘 IO、连接数和缓冲池，反过来拖慢业务请求的响应时间——于是实验把那个它声称要优化的产品弄得更慢了。这种自伤在报表任务被安排在业务高峰附近执行时尤其明显。

结构上的分离通常分三层：写入层负责收集与缓冲，承接峰值；存储层用列式或按实验 ID 加日期分区的方式存放明细，便于大规模扫描；计算层跑批做聚合，结果再回写成一张小表供看板读取。规模很小的团队做不到三层齐备时，最低限度也应该是：明细写在独立的表空间或者独立的实例上，聚合结果再回写。这条线的核心从来不是技术选型，而是隔离——不要让分析负载直接压在在线库上。

保留周期同样要单独算。实验明细的生命周期应该按"实验结束后还要保留多久才能完成复盘和结果复现"来定义，而不是无限期堆积。保留多久要结合存储成本和事后追溯的需要核算，两者冲突时优先保留聚合结果，明细可以更早清理。此外还要考虑口径一致：明细里通常包含用户标识，它的保留策略必须和整体的隐私口径对齐，不能因为它是分析数据就例外。

本文不解决的三个问题：灰度发布、推荐算法、BI 选型

划清边界比多讲一点更有用。本文从头到尾不碰三件事。

第一，不讲灰度发布与流量染色。那套东西回答的是"要不要上线、怎么安全地分步上线"，关心的是回滚半径、批次推进速度和故障止损动作；它和实验共用"分桶"这个词，但目标不同——实验要求的是有对照，灰度只要求可控。两者可以复用同一套基础设施，但判据不能混用：灰度期间观察到没有问题，不等于这个改动带来了收益。

第二，不讲推荐算法。本文关心的只是如何判定一次干预有没有产生效果，至于这个干预本身是推荐策略的调整、是 UI 文案的修改、还是定价的变化，都不影响这些结论的成立方式。

第三，不做数据分析平台或 BI 工具的选型对比。本文涉及存储与计算的讨论，仅限于"实验事件落在哪里、用什么样的隔离方式才不会压到在线库"，那是容量与隔离层面的工程判断，不是产品功能的横向比较。

换句话说，本文的范围只有一件：实验自身的分流怎么定、样本量怎么算、指标口径怎么看、以及这套东西跑起来之后在自己的服务器上要付多少资源。

六种典型的实验失效原因：怎么错、在哪一步埋下、能不能补救

关于实验落地的高频疑问

问：流量小是不是就做不了 A/B？

答：不是能不能做，值不值得做的问题。由前面那个关系式可以直接推出来：想检出的效应越小、指标波动越大，需要的样本就越多。日流量小的场景下，你能检出的最小效应被迫放得很大，而大多数日常改动的真实效应远在这个之下。这种情况下硬跑，大概率得到一堆"没有显著差异"——注意这个表述的含义。

问："没有显著差异"是不是等于"没有差别"？

答：不等。它真正的意思是"以当前的样本量和波动水平，不足以判断有没有差别"。这两句话的决策后果完全不同：前者会让团队放弃一个可能有效的方向，后者会让团队选择要么加大样本、要么换指标、要么放弃这条验证路径。把它当成"没有差别"，是小流量团队里最贵的一个误读。

问：同一个用户换设备会不会进到不同桶里？

答：只要分流键是设备级的，就一定会。哈希本身没有问题，同一个键依然进同一个桶，问题是换了设备之后键变了。这也是为什么自然人级别的结论必须依赖账号这类跨设备稳定的标识；如果业务只能在设备粒度上识别用户，那么实验结论也只应在设备粒度上被解释。

问：中途看一眼数据算不算作弊？

答：别用道德词汇描述它，它是一个能够被说清楚的统计后果：每看一次就多一次判卷机会，越多看，至少有一次越过阈值的累积概率越高，实际承担的错误率就偏离你设定的那个值。真正有害的不是"看"，而是"看到显著就停"。如果必须每天盯，就把查看次数和停止边界预先写进文档，或者采用序贯检验这类为多次查看支付代价的思路。

问：多个实验同时跑一定会互相影响吗？

答：不一定，取决于两个因素：一是流量有没有被正确分层，二是两个改动在业务上有无交互。正交分层能消除分组之间的相关性，但消除不了交互——两个改动同时作用于结算页时，统计独立不代表效果可以相加。所以结论不是"不要并行"，而是"并行时不要把两个组的结论加起来用"，并在准备合并上线前安排一次验证。

问：到底该看多少个指标才算合理？

答：一个主指标，加一张事前写好的护栏清单。护栏数量可以按风险面来定，但它们的作用是否决而不是投票：任何一个护栏变差，主指标的提升就不被采信。除此之外新增的一切指标，都应当被当作待验证的假设，用下一次实验去证实，而不是补充到本次结论里。

问：实验到底该跑多久才够？

答：没有统一的天数，天数必须算出来。顺序是：定最小可检测效应与两个水平的参数，估样本量，再用日均可用流量换算成天数，然后取整到完整的周循环；如果业务有月度结算或发薪效应，还要覆盖到对应节点。反过来，先说"跑一周看看"，再去找支持它的理由，这个顺序本身就是错的。

问：分流服务挂了会怎样，默认策略应该设成什么？

答：默认应该是不分流，全部落到对照组，也就是当前线上正在跑的这个版本。理由是信息不对称：对照组的表现已知，实验组未知，缺少判断依据时选已知的那个。配套要有两件事——降级期间的告警，以及降级期间数据在明细里明确标记并在分析时剔除，否则这段时间实际上是一个不成组的流量，混进来两边都不干净。

问：实验事件上报会把写入量放大到什么程度？

答：量级上通常是业务成交量的几十到几百倍，具体倍数由埋点密度和业务类型决定，这里说的是数量级关系而不是可照搬的数字。规划时要据此单独评估：独立的写入通道、客户端批聚与服务端削峰的缓冲层、以及由于批量上报带来的数据晚到（导出结论的时间要相应后移）。不要按订单量去估实验写入。

样本量不够的时候，最正确的选择是干脆不做 A/B

把上面三条串起来，会得到一条否定的结论，而这往往是最有用的那条。

当算出来的所需天数超过你能接受的等待，或者说当业务日流量根本撑不起一个有意义的最小可检测效应时，正确动作不是把实验砍成三天跑完，而是换方法。可行的替代有三类：前后对比加人工判读（明确承认它无法排除外部变量，只作为弱证据）；小范围灰度观察（注意这是发布范畴的动作，它能回答有没有明显问题，不能回答有没有收益）；定性的用户研究，用来解释为什么而不是证明有多大。三类都比一个样本不足的 A/B 要诚实。

还有一个反向的纪律要一起说清楚：不要把"没有显著差异"读成"没有差别"。前者是证据不足的表述，后者是否定了零假设的结论。这两者在文档里看起来只差几个字，在决策上差的是要不要继续投入一个方向。真正吃得透的团队，会把实验预算留给效应足够大的改动，而不是把每一次 UI 微调都送去做一次必然 inconclusive 的检验。

回到最开始那个例子。它的问题不在样本小、不在策略差、也不在分析工具不够先进，而在于开会决定做实验的那一天，没有任何人问过一句：我们用哪个键分流、我们接受多大的最小提升、我们先看哪个指标。这三个问题不回答，实验后台给出的每一个数字都只是装饰。

本文关于 A/B 实验分流与判读的判断边界

本文的判断集中在实验方法论层面：分流键的选择与失效场景、哈希取模带来的确定性与它的边界、最小可检测效应到样本量到观察周期的推导顺序、主指标与护栏指标的事前约定、多重比较与中途停止的后果、多实验并行的污染机制、新奇效应与首日偏差。所有结论都建立在这三条支柱上——分流的确定性与稳定性、指标的事先定义与护栏、样本量与观察周期在开跑之前就定死。

本文没有给出任何需要真实基线转化率才能算出的具体样本量数字，因为那类数字离开具体业务就是误导；文中出现的唯一量化关系是"所需样本量大致与效应大小的平方成反比、并随指标波动增大而增大"，这是检验本身的结构性质，不依赖任何具体业务的观测数据。文中也没有引用任何客户案例、销量数据或市场份额。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。部署分流服务与实验事件上报通道时，建议把它与业务主库分开评估，按上报峰值与保留周期单独核算写入与存储，具体机型与配置需结合业务量确认。

本文关于实验工程实现与资源占用的信息来源

分流机制部分（哈希取模、加盐错开、确定性带来的无状态与横向一致性）来自实验系统通行的基础做法，属于行业通用共识，可以在任何一本实验设计与因果推断的工程资料里找到对应表述，本文只对它与本文主题相关的部分做了取舍说明。

资源账部分（关键路径多一跳、默认降级策略、事件上报的写入放大、明细与分析负载的隔离）来自典型的部署思路归纳，用于说明结构关系与取舍原则，并不特指某一真实客户环境，文中的数量级描述均为量级说明而非统计结果。写入到底放大多少倍、需要多大规格的存储与计算、链路要预留多少余量，这些都需要以你自己的埋点密度和流量结构去核算，具体机型、带宽、存储与报价请以官网实时信息或咨询确认为准。

本文不涉及任何形式的收益承诺、效果保证或服务级别承诺，所有判断均需读者结合自身业务规模与可用数据验证。