开发者 Launch 留出实验：随机分配、污染测量与增量采用门槛

Launch 当天注册翻倍，只能证明时间上同时发生。新版本可能本来就会被自动更新，热门社区帖子也可能同时把处理组和未触达者带来。要回答“这次开发者营销净增加了多少采用”，必须在发送前保留随机、稳定且不会被运营补发破坏的 holdout。AI 功能 A/B 测试比较产品内功能行为，本篇比较的是发布消息的触达策略；功能本身对两组保持相同可用性。

这也不是重新验证需求或付费意愿。AI 产品 Kill / Pivot 标准决定产品方向是否继续，AI 功能证据评分卡比较机会优先级。Launch 留出只估计一个已定义活动对合格开发者采用动作的因果增量，不能把结果外推为产品市场匹配。

在看到结果前封存协议

实验创建不可变的 developer.launchExperiment.v1，固定假设、资格查询摘要、排除规则、分配单元、分层变量、随机盐 key ID、处理比例、渠道与素材摘要、开始/结束时间、最小可检测效应、样本量、主要指标、护栏、污染定义和停止规则。协议摘要写入每条事件；任何修改产生新 experiment generation，不能在看数后移动终点或换分母。

schema: developer.launchExperiment.v1
experimentId: sdk-4.2-launch
unit: organization
eligibilitySnapshot: sha256:8ae...
allocation: {treatment: 0.8, holdout: 0.2}
primary: adopted_within_14d
mdeAbsolute: 0.02
analysis: intent-to-treat

先在资格截止时冻结组织集合，再用 HMAC(saltGeneration, experimentId || organizationRef) 确定分组。原始组织 ID 不进入分析仓；同一组织的成员必须同组，避免一个管理员收到邮件后影响“未触达”的同事。按历史活跃度、SDK 主版本和区域做预先声明的分层随机化，分析时沿用相同层权重。账号合并或成员邀请只追加 membership 证据，不重新抽签。分配完成即按总量和每个预声明 strata 比较实际 arm 数与 expected allocation，执行协议指定阈值及多重检验修正的 sample-ratio mismatch（SRM）检查；SRM 失败立即冻结曝光和分析，不能用“确定性 hash 看起来正确”代替排查资格丢失或事件漏数。

分配产生 launch.assignment.v1，记录 protocol 摘要、unitRef、arm、generation 和 assignedAt；渠道接受后写 launch.deliveryReceipt.v1，包含 channel、rendition、provider receipt 与失败原因。只有客户端或产品表面给出合格可见性信号时，才另写 launch.observableExposure.v1，供应商接受不能冒充曝光。采用由服务端 launch.outcome.v1 证明，例如首次成功调用新 API，而非点击按钮。这些事件都有稳定 ID、occurred/received 时间和水位；重复、倒序与迟到只改变材料完整度，不能改变分组。LLM 可观测性中的指标与 trace 分层可承载聚合，但高基数 unitRef 只能留在受控事件仓。

主分析坚持意向治疗

主要结果用所有已分配合格单元做 intention-to-treat：处理组投递失败仍留在处理组，holdout 从别处看到公开消息也仍留在 holdout。这样估计的是可实际执行的 Launch 策略，而不是“只挑成功送达的人”。同时报告 treatment delivery rate、holdout contamination 和 treatment non-compliance，帮助解释效应被稀释的程度，但不能事后剔除这些单元。

若所有组织同时处于公开发布环境，组织级随机只能估计“私域触达叠加公共发布”的 assignment effect，不能回答整场 public launch 相对完全不发布的增量。后一问题需要把相互独立的社区、区域或时间窗作为 cluster 随机化，并预设隔离与 washout；传播强度会互相影响时应采用 saturation design，报告不同 cluster 覆盖率，而不是把受污染组织当成独立样本。

报告给出两组采用率、绝对百分点差、相对比、置信区间与预注册样本量。窗口内不得每小时试显著性后提前宣布胜利；使用固定终点，或在协议中预先写明顺序检验及 alpha 花费。中途重大服务事故按规则暂停曝光，结果标为 INTERRUPTED，不能删除故障日后继续拼接。AI 产品 Time to Value可作为采用后的质量护栏，但主要终点仍是这里冻结的开发者动作。

故障注入包括：随机盐误轮换造成重新分组、某个 strata 的 assignment 事件选择性丢失、消息重试重复投递、holdout 被人工 CSV 补发、链接预览 bot 伪造点击、组织成员跨账号、账号在资格截止后创建、采用事件晚于水位、客户端时钟倒退、某区域渠道全停、公开发布跨 cluster 扩散，以及 feature flag 错误地只给处理组开放功能。系统必须让 SRM 检出选择性丢失，阻断 assignment generation 混用，标记干扰与渠道不可用，并证明功能可用性在两组一致。Feature Flag 灰度可以独立控制运行风险，但不能暗中充当营销实验分组。

进入正式分析前要求：A/A 演练的 assignment recompute mismatch 为 0；总量及每个预声明 strata 的 SRM 均通过预注册阈值；重复事件对单元数影响为 0；预实验关键协变量的最大标准化差异小于 0.1；处理投递率至少 95%；未解释的 holdout 直接投递低于 0.5%；采用凭据与服务端记录一致率 100%；迟到水位内完整率至少 99%；两组功能权限差异为 0。示例发布门可设为主要指标 95% 区间下界大于 0 且绝对提升不少于预注册的 2 个百分点，同时错误率不升 0.5 个百分点、支持工单不升 10%。不满足就是 INCONCLUSIVE 或失败，不能改看点击率寻找绿色结论。

发布顺序从 2% A/A 开始，再用 10% 合格总体验证投递和污染，最后启动冻结样本的正式实验。出现权限差异、assignment mismatch 或护栏越界时，立即停止新的消息和产品内入口，把 channel alias 切回无活动状态；已经分配的单位保持原 arm 直到观察窗结束，避免回滚后交叉污染。可以恢复旧素材或结束活动，但不得重抽 holdout、删除负向结果或把未发送者改名为新对照组。AI onboarding可在实验结束后吸收已证明有效的引导，前提是另开版本和基线。