在公司工作,普遍采用了AB实验去验证某个 Feature 的效果,但是客户端或者前端工作而言,我们在做实验分析的时候还需要做更多的事情。
去年自己遇到一个 Case 便是如此。这里不太会透露很多业务的细则。
比如自己再做的的一个实验 A, 它在前端整体跑下来的结果是 显著
positive
的。比如它从设计的出发,会带来某个指标的增长。从假设出发,到最后的结果,我们发现符合预期的。因此我们计划将它应用到全量用户。
总的来说这里没什么问题,但是我们都知道前端其实面临非常多设备型号, 有可能存在某种型号在这个 feature 上的失效,带来负面的影响。虽然我们看到了总体的增长,但是部分用户我们其实并没有看到预期增长,这个是我们工作需要去重视的。
因此后来我们也提议,在做实验结果 Review 的时候,可以 Review Top5 的机型指标增长情况。
很多人提出为什么不再测试阶段去针对多个机型的测试呢?
这里引入另外一个自己的 Case。前端工作的多重性,会让我们的工作总会有所疏漏。
自己在做的某个实验 B,它的假设是可以降低某种错误。然后我们开始进行多个平台的实验,发现普遍都取得了一些效果,然后我们准备去进行全量铺开。然后全量铺开的过程,发现它带来了某一项别的指标的异常上升。然后我们 Review 发现,它在某种机型某种条件下才会失效。这种条件本身是用作 Fallback 的,因此QA并不会当做常规测试流程进行测试。
同样我们还面临着多种系统的变化
自己再做某个实验的 C,它在跑的初步阶段效果很好,然后突然有一天数据指标开始增长开始缓慢。最后达到样本数目,总的来算还是有显著增长,我们于是乎准备再次将它全面铺开。然后铺开后,发现线上指标没有像我们预期的那样,有明显的增强,反而日渐走低。后来我们发现我们在实验过程中遇到了OS的升级,我们这个 Feature 在 OS1.1 上效果不错,在 OS 1.2 上有明显问题,但是早期 OS 1.2 样本数目少,不能够带来较强的实验影响,所以上线后出现了不达预期的效果
这些 Case 都有一个点,就是前端工作面临的实际情况差异太多了,我们要面临不同的设备,不同的系统,不同的系统版本,不同的浏览器。因此保持数据敏感性很重要:
- 比如我们在测试中发现它能够带来的增长大概有多少百分比
- 比如我们在 Review 的时候保持对 Top 3 or 5 的 机型或者系统版本的关注
- 不仅仅关注正向指标,负向指标也需要留意
总的来说,过去一年自己的一些实际经历,让我对 Data Driven 又有了更加深的认识,虽然数据无情,但是却是客观和实时的。