增长实验最先要回答的，不是“B 版赢了吗”，而是“这场实验有没有资格回答这个问题”。如果分组、真实曝光或结果回传已经偏了，AI 只会更快地产出一份精确但错误的结论。对 Momcozy APP，实验能力的第一块地基应是“数据可信门”：先证明比较对象成立，再谈显著性、增量和自动放量。
A/B test（A/B 测试）是把合格用户随机分到 A 版和 B 版，再比较结果。它想解决的旧问题是：产品改动上线后指标变好，到底是改动造成的，还是季节、流量、人群或其他变化造成的？随机分组让两组在平均意义上尽量相似，于是两组结果之差才有机会接近改动的因果效果。
但“平台显示 50/50 分组”不等于实验真的有效。至少有三道门：用户是否被正确随机分配；被分配后是否真的看到了对应体验；看完后的结果是否被同一口径完整记录。任何一道门失真，后面的统计计算再漂亮也没有意义。
一个常见红灯叫 Sample Ratio Mismatch，SRM（样本比例失配）：原计划 A、B 各 50%，实际进入分析的却明显不是这个比例，而且偏差大到不太可能由随机波动解释。生活类比是测试两种奶粉罐开盖设计：先随机给两组家庭，但 B 组包装在运输中更容易损坏，很多人还没试就被排除。最后只比较“成功收到并愿意反馈的人”，看到的已不是原来随机出的两组。
Momcozy APP 的待验证例子：我们测试新的设备绑定帮助，系统把用户随机分到两组；但 B 版资源更慢，部分弱网用户在页面加载和“已曝光”事件上报前离开。分析里 B 组剩下的可能恰好是网络更好、设备更容易连接的人。即使 B 组稳定连接更高，也不能先说新帮助有效——它可能只是把最难的人从数据里漏掉了。
所以实验前需要一个 Validity Gate（有效性门槛）：样本比例、身份稳定、真实曝光、事件完整、版本一致、A/A 校准等检查未通过时，系统应先判“不可解释”，而不是勉强给出输赢。这里最反直觉的能力不是更聪明地分析，而是知道什么时候没有资格下结论。
Booking.com：每天上千个并发实验，仍用两条独立数据管道互相验算
实验规模越大，越不能把一条数据管道当作绝对真相；可信度必须被持续测试，而不是靠团队相信平台。
关键事实
Booking.com 公开论文称，其各部门每天运行和分析超过 1,000 个并发实验。为检查实验数据质量，团队让不同工程师维护两套独立聚合管道：一套近实时、延迟少于五分钟，另一套每日批处理；相同核心指标在两边分别计算，出现差异就报警。团队还保留一组 A/A test（A/A 校准测试，即两组体验完全相同），检查误报率和指标统计分布是否符合预期。论文给出的另一类陷阱是 selective attrition（选择性流失）：如果新版同步加载更多图片，弱网用户可能在任何行为数据回传前离开，剩余样本就不再可比。遇到这类情况，报告不只显示警告，还会隐藏用于决策的比较统计。
编辑视角它证明了什么： 这证明“独立复算、持续 A/A、发现选择性流失后阻断解读”可以被做成平台机制，而不是分析师的个人习惯。它不能证明双管道一定覆盖所有错误，也不能把 Booking.com 的高频交易实验照搬到低频设备任务；但它清楚说明，实验民主化的前提不是人人都能点开始，而是平台能阻止一场坏实验被轻易包装成答案。
Optimizely：相同版本也要互测，校准的是整条实验链路
A/A 测试不是“浪费流量测两个一样的页面”，而是在没有真实差异时，检查系统会不会凭空制造赢家。
关键事实
Optimizely 的官方说明把 A/A 定义为数据可靠性和质量保证程序，建议定期运行，经验上可按季度校准。两组版本完全相同，因此多数结果应为“无法证明有差异”；若系统频繁报告显著赢家，应检查实验实现、目标规则、页面覆盖、样本量和分析工具之间的口径。官方也提醒，95% 显著性不是百分之百确定：在重复许多无差异测试时，仍可能约有 5% 因随机波动看似显著；因此应观察一批 A/A 结果的分布，而不是用单次 A/A 给平台盖章。
编辑视角它证明了什么： 这是一家实验平台对校准机制的官方解释，支持“分析系统本身也要接受实验”。它不是独立审计，也不能证明某个平台当前实现零缺陷。更重要的证据边界是：一次 A/A 没报警，只说明本次未发现异常；它不能替代真实曝光、事件完整性和具体实验的 SRM 检查。
先认识这个人
Ronny Kohavi 曾负责微软实验平台，也在 Amazon 和 Airbnb 从事数据与实验工作，是《Trustworthy Online Controlled Experiments》的合著者。这个访谈值得深读，不是因为 Momcozy 应该马上建立巨型 A/B 平台，而是 Ronny 把一个容易被忽略的顺序讲得很清楚：实验速度建立在信任之后；一旦团队发现“平台宣布的赢家后来没有兑现”，整个实验文化都会被反噬。
核心机制：SRM 是“别再读结果”的红灯
访谈约 55:47 起，Ronny 用 50/50 实验解释 SRM：即使实际是 50.2% 对 49.8%，在百万级样本下也可能极不寻常；关键不是肉眼觉得“只差 0.4 个百分点”，而是计算这种偏差由随机产生的概率。他引用微软团队公开的经验称，在加入检查后，约 8% 的实验出现过 SRM。常见原因包括机器人流量、数据管道过滤、从不同入口进入的流量，以及新版改变了用户能否被记录。
最有意思的不是这个数字，而是治理设计。微软最初只在报告上放警告，团队仍然会拿结果去汇报；后来隐藏 scorecard（实验计分卡），用户仍会点开；最后平台把每个数字都加上红色标记，让截图离开系统后也无法轻易抹掉“本实验失配”的上下文。系统不是只提示风险，而是在对抗人天然想看见成功的偏差。
“太好”不是庆祝信号，而是调查信号
Ronny 还解释 Twyman’s Law（特怀曼定律）：任何异常有趣、异常不同的数字，通常先怀疑它错了。他称，当正常实验变化通常小于 1%，某次突然出现 10% 时，应暂停庆祝并调查；按他的经验，这类“好得不像真的”结果，十次里约九次能找到实验缺陷。少数真正的大胜需要多次复现和交叉检查，而不是因为数字激动就降低证据标准。
这里不能误解为“大效果都是假的”，也不能机械套用微软的大样本阈值。Momcozy 的流量、设备任务频率和风险结构不同。我们能借的是判断顺序：结果越能改变资源和生产策略，越要先证明分组、曝光、回传与口径没有把答案预先写进数据。
以“实验可信度 Agent”为例，完整链路不是自动生成实验周报。
系统读取什么：实验预注册的资格、随机分配比例与哈希版本；assignment（被分配到哪组）、exposure（是否真实看到对应体验）、关键结果三个不同事件；匿名且最小化的 APP、设备和系统版本；事件延迟、缺失、重复、跨端身份变化；A/A 校准结果、历史正常区间、脱敏 VOC 与人工排障记录。母婴、儿童、健康和设备数据不能为了追踪方便被默认跨场景拼接。
形成什么判断：先判实验为“可解释、SRM、曝光失衡、结果回传不完整、身份污染、A/A 异常、证据未成熟或无法判断”；再列出最可能原因和反证。只有通过可信门，系统才分析 B 相对 A 的增量；不能把“已分组”当成“已曝光”，也不能把“没有上报”当成“没有发生”。
能做什么：自动运行比例与缺失检查；在影子模式比较两条聚合口径；隐藏或水印不可解释的 scorecard；抽取少量脱敏旅程供人工排障；提出修埋点、重新随机、延长观察或重跑候选。事先批准的低风险实验可按硬阈值自动暂停，但未经明确授权，不扩大流量、不向真实用户发送 Push、EDM、站内信，也不改变生产设备或健康相关策略。
如何看结果并更新策略：修复后先重跑 A/A 或小流量验证；若比例恢复但曝光仍偏，继续阻断结果；若多次实验都在同一版本丢事件，降低该版本数据的可信度并优先修复测量；若“大胜”复现后仍成立，再提高机制置信度。系统保留每次无效实验及其原因，避免下一轮再次把相同数据缺陷当作产品洞察。
何时交给人：任何设备安全、健康或儿童语境；身份与授权边界不清；小样本；跨设备归因；未知事件丢失；统计检查与用户旅程冲突；以及真实上线、主动触达和指标口径变更，都交给人。AI 帮忙查 SRM、找异常属于 AI-assisted Operations（AI 辅助运营）；系统持续校验实验资格、阻断坏结论、从故障中更新检查规则，才接近受治理的 AI-native Growth System（AI 原生增长系统）。
场景一：设备绑定帮助实验。 待验证假设是，新帮助卡可能在不同网络、系统或设备版本上有不同加载与回传路径。可以借 Booking.com 的选择性流失检查：分别记录“符合资格、完成随机、真实看到帮助、开始重试、首次稳定连接”，比较两组每一步的人数是否异常减少。不能只用页面点击当曝光，也不能把没上报稳定连接的人统统算失败。最先需要的证据是一条从 assignment 到 exposure 再到稳定结果的可审计链路。
场景二：AI 助手首次价值实验。 待验证假设是，让部分用户看到更明显的助手入口，会增加真实问题解决；但“被分到新版”不等于入口渲染成功，“打开对话”也不等于模型完成回答或问题解决。可以把入口可见、知识检索、回答完成、用户确认、行为验证和正确转人工拆开。不能为提高样本量把敏感会话变成营销画像，也不能把正确转人工记成处理组失败。最先要验证的是，两组是否以同一规则识别“合格低风险任务”。
场景三：BBM/VOC 与客服闭环。 待验证假设是，新故障引导会减少客服求助；但求助下降也可能因为入口更难找、上报中断或用户放弃。可以联合脱敏行为与 VOC，看“求助减少”是否同时伴随稳定任务改善；不能把沉默当解决，也不能跨用途复用儿童、健康或孕产育数据。若投诉或高风险求助出现，即使总体比例正常，也必须人工接管。
- Experiment Validity｜实验有效性：实验是否真的具备比较两组并解释差异的资格。Momcozy 例子：绑定实验先证明随机、曝光和稳定连接事件完整，再读提升。
- Sample Ratio Mismatch / SRM｜样本比例失配：实际进入分析的组别比例明显偏离预设，且不像随机波动。Momcozy 例子：原定 50/50，但 B 版弱网用户在上报前大量消失。
- Exposure Logging｜真实曝光记录：记录用户是否真正看见或接受了实验体验，而不只是被后台分组。Momcozy 例子：新版帮助卡成功渲染后才算曝光。
- A/A Test｜A/A 校准测试：给两组完全相同的体验，用来检查系统是否凭空制造差异。Momcozy 例子：相同绑定流程随机分两组，验证分组和指标管道。
- Selective Attrition｜选择性流失：某组中特定类型用户更容易在数据记录前消失，导致两组失去可比性。Momcozy 例子：B 版加载慢，使弱网用户更常没有曝光事件。
写一张“实验可信门卡”，只选一个假想的 设备绑定帮助 A/B test，不运行真实实验、不触达用户：
- 写清谁有资格进入，以及计划 A/B 比例；
- 把 assignment、真实 exposure、首次稳定连接写成三个独立事件；
- 为每个事件写一个“它可能丢失但用户其实已发生行为”的原因；
- 写三条阻断读数的条件：SRM、两组曝光率异常不同、结果事件缺失；
- 写明出现红灯后是暂停、修数据还是重跑，不能写“先看看输赢再说”。
产出物是一页“资格—分组—曝光—结果—红灯—处置”卡。完成后能更新的判断是：我们现在缺的是更高级的实验分析，还是连一场实验有没有资格发言都还不能证明？最后只回答一个具体问题：如果 B 版稳定连接率更高，但 B 组真实曝光人数比预期少 6%，我们应该宣布胜出、继续观察，还是先判实验不可解释？哪条证据能帮你区分随机波动与选择性流失？