在公司工作，普遍采用了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 又有了更加深的认识，虽然数据无情，但是却是客观和实时的。