关于试验用户跳组的说明

在一些A/B Testing经验较多、A/B Testing文化较浓的公司内，为了能尽快验证效果、累积流量，都会默认选择用户随试验设置更新所在试验分组（即用户跳组）。一般来讲，试验用户跳组，是 A/B Testing 试验过程中一个可预期的行为，一般发生在以下情况：

1. 在试验运行过程中，如果选择「非粘性层」试验，我们主动调整了流量，一般是缩小流量，会导致部分用户重新分流回跳到对照组；
2. 在试验发布过程中，随着发布的进行，陆续有用户跳组，用户会进入发布策略的分组内；
3. 试验结束时，我们主动下线试验时，会导致试验组用户全部回跳到对照组；
4. 在试验推全后一段时间，发现了一些数据异常情况或者产品功能缺陷，对已发布的试验进行回滚操作，所有已经命中发布计划的用户，都会执行发布前的试验策略，有些已经命中发布策略的用户会跳组，回到原来试验运行中的试验分组；
5. 在一些类似 智能分流 的场景，由于是程序化的控制流量的缩放、变更，也会有可能导致试验用户跳组；
6. 在一些特定的试验类型里，比如时间片轮转试验，根据试验配置的时间段，用户会翻转试验策略，也会出现预期的跳组行为；
7. 在一些特殊的试验配置设置里，比如试验层类型的选择、试验配置内的用户变更的选择，都会出现用户跳组的行为，具体可以参见下文表格；
8. 另外就是由于分流服务异常产生的 timeout or pvlost，在部分没有缓存的场景（比如服务端分流试验），会有可能导致试验组回跳到默认的对照组，这个是预期外的跳组；（实际上作为在线服务，线上始终有一定的小概率出现极小部分的pvlost，这个需要结合服务可用性预期做整体评估）

其次，对于用户跳组的业务影响评估，我们一般作如下考虑：

1. 作为在线服务，线上始终有一定的小概率出现极小部分的pvlost，即线上大流量 toC 服务中，结合整个服务 SLA，我们一般忽略掉这一小部分影响。
2. 从试验周期来看，一般试验上线首日和试验结束下线日，用户的分组都可能发生变化，我们一般观察评估整个试验过程会建议排除这2天，以试验主体时间的业务数据为参考。
3. 如果遇到意外情况引入的脏数据，比如业务程序bug，或者试验分流服务故障，我们需要评估数据量级，根据实际数据量级来评估样本量的影响；对于轻量级的数据污染，一般以延长试验周期的应对方式为主。在我们的日常实践中，企业内的试验管理者一般会对核心策略指标设置阈值作为试验正向推全依据：以某亿级 DAU 公司的广告策略上线逻辑为例，一般要求 CPM 收益大于0.5%为门槛；某千万级 DAU 公司的留存策略上线逻辑，一般要求 用户时长 收益大于2%为门槛；在样本量足够的情况下，结合门槛阈值屏蔽各种数据分布波动，一般来说，少量的数据误差不会对试验是否正向产生根本影响。

总的来说，非预期的试验跳组行为，应该避免，但不应该冲击我们的业务本身。A/B Testing 试验平台早期建立的理念就是基于部分用户体验可能有损的情况下做试验。因此，在一般实践中，我们试验分流失败的默认策略即保持和对照组（一般来说，就是维持线上）一样的策略即可。

神策A/B Testing试验中，有以下配置可以控制用户是否跳组的选择：