没必要当“Test everything! ”，A/B测试跨越多个应用或涉及复杂合作时，一个小小的能力折现设计偏差，就可能导致整个合作不欢而散。
并非所有改动都值得大动干戈进行A/B实验，有时保留一个功能开关，远比盲目测试一切更具性价比。
发布A/B实验阶段的配置参数，若在全量时悄然改变，可能会让大盘数据突然下跌，排查成本远超预期。
发布一致性
A/B 实验阶段使用的配置参数必须与全量发布时保持一致。典型案例：某插屏导流广告在 A/B 阶段展示时长配置为 3 秒，数据表现符合预期。全量发布时，负责该场景的产品经理未经沟通即将展示时长改为 5 秒，导致大盘使用时长出现显著下降。事后排查耗时良久才定位到原因，造成了不必要的资源浪费。
如需调整配置参数，应将其视为新的实验假设，重新走完整的 A/B 流程进行评估。
发布一致性案例：参数变更导致大盘留存下降
A/B 的思想比形式更重要
常规 A/B 实验在同一安装包内预埋多套方案，根据服务端下发的分组信息展示。但在时间紧迫、改动幅度较大的特殊场景下，可考虑使用应用市场渠道包的方式进行 A/B 测试——即打两个不同的安装包供不同渠道分发。尤其在框架层改造场景中，兼容两套框架的成本较高时，渠道包是一种务实的权宜方案。核心原则是：A/B 的思想比形式更重要，应灵活选择实现方式。
aA 渠道包 B 渠道包渠道 bz1bz2
| A渠道包 | B渠道包 | |
| 渠道 | bz1 | bz2 |
| 特性 | 老特性（框架） | 新特性（框架） |
特性老特性（框架）新特性（框架）
实验的性价比评估
并非所有改动都适合或值得进行 A/B 实验。修复明确的 Bug、变更不影响用户行为的内部实现等场景，保留功能开关即可，无需投入 A/B 实验的成本。
部分实验做 A/B 的代价较大，保留开关即可，没必要“Test everything! ”，在一些公司有时候修个明确的 bug 也要做 AB，数据跌了还说这个 bug 是“良性 bug”。
【案例】接入保活 SDK
以下图的“甲应用”为例，普通的 A/B 测试只需要甲应用终端和服务端进行通信，获取实验分组信息即可。而涉及多个应用联动时问题会变得非常复杂（数据回传、用户隐私）
【案例】输出 SDK 能力
输出 SDK 能力，常见的商业模式是能力换拉新。与某内容大厂合作时，对方非常严谨，要求做 A/B 测试，能力直接折现。我们输出能力时担心对方扣量，就降级了输出能力，对方发现能力不达预期，数据也进一步下降，最终合作不欢而散。
