快速决策方案 —— Airtrack

在一篇文章《动态调整的基础 —— 配置中心》中我们聊了关于Native App动态化的问题。无疑Native的动态化能力较Web要弱很多，很多操作是依赖版本节奏的。这就导致在Native App上许多决策无法快速验证，对存在不足的逻辑没办法快速修正。受到这些条件的限制，那个唯快不破的铁律在Native App上遭遇到了尴尬。每一个产品决策会变得异常谨慎，因为一个错误的决策要持续整个版本周期可能被修复。慢慢的我们就会发现，不出错会成为做出决策的重要因素，而有意义却退居二线。 \

所以具备快速验证和及时修正这两个能力就显得非常重要，打造这样的能力需要一个完整的解决方案。我们认为，这个方案是一个以A/B测试为核心，结合周边多个系统能力，共同组成的一个试错平台。在这个平台上，我们的团队，不管是业务方还是工程师，都可以快速应变，不畏惧出错，变得灵动起来。 \

A/B测试

说到A/B测试，这到底是个什么东西？我个人的理解是：狭隘的说，A/B测试是以分桶为核心，以依据分桶结果执行不同逻辑为基本原理，以获取最优解为目的一种测试方案。 \

一般认为，A/B测试的主要场景有两种：对比实验和灰度发布。 \

对比实验

所谓对比实验，就是同一时间执行两套甚至多套方案，通过对比反馈数据，对这些方案作出评价。 \

灰度发布

灰度发布则是，某个新功能或版本正式发布前，先圈一部分人作为小白鼠，试用这个功能或版本。我们从稳定性，业务效果等多方面观察这部分试用者的反应，对这个新功能或版本作出评价。 \

不管是对比实验还是灰度发布，最终目的都是期望只是发布带来的效果最大化。 \

体系

一个单一的A/B测试框架并不能帮助我们达成目的，还需要诸多周边能力辅助。要实现丰富的分桶条件，需要设备和用户的信息收集机制；要实现线上逻辑实时调整，要Native逻辑动态化方案；要实现动态调整分桶逻辑，需要分桶条件下发系统；实现观察对比实验结果，需要数据收集和分析平台，等等。 \

在天猫，我们整合各方能力搭建了一个称为AirTrack的试错平台。在AirTrack平台上动态实验条件，实时运算SDK和数据收集和反馈平台三部分是重中之重。 \

动态实验条件

在传统的Web A/B测试中，实验条件的计算和分桶逻辑执行都在后端完成，具有非常好的动态性，可以随时发布随时生效。在Mobile场景下，很多时候我们惯性的延续这种思路，把这些逻辑放在后端，通过API吐出不同的数据来控制App端的不同形态。这种方式固然有很好的动态性，但一个致命问题在于，这样的设计依赖数据API，只能用于数据层面的实验。 \

我们认为数据API在Mobile场景中仅仅占一小部分，而我们要建设的是一个代码级别的A/B测试框架，必然不能依赖数据API，而是要具备在端上完成此前后端承担的全部工作。具体的说，就是我们需要在App端实时运算实验条件和执行分桶逻辑。所有的逻辑都在App端，那么动态化的问题怎么解决？幸好我们具有成熟的基础设施建设，可以通过配置中心实现实验条件动态化。 \

我们把实验条件的数据结构设计为一棵树。根节点是运算起点，非叶子节点是一个逻辑表达式，叶子节点都是实验条件运算的结果。 \

通过一段JSON描述这棵实验条件树，再利用配置中心的动态能力把数据动态下发到端，从而实现了实验条件动态化。

{\  \"name\": \"demo\