在一篇文章[《动态调整的基础 —— 配置中心》]中我们聊了关于Native App动态化的问题。无疑Native的动态化能力较Web要弱很多，很多操作是依赖版本节奏的。这就导致在Native App上许多决策无法快速验证，对存在不足的逻辑没办法快速修正。受到这些条件的限制，那个**唯快不破**的铁律在Native App上遭遇到了尴尬。每一个产品决策会变得异常谨慎，因为一个错误的决策要持续整个版本周期可能被修复。慢慢的我们就会发现，**不出错**会成为做出决策的重要因素，而**有意义**却退居二线。
所以具备**快速验证**和**及时修正**这两个能力就显得非常重要，打造这样的能力需要一个完整的解决方案。我们认为，这个方案是一个以**A/B测试**为核心，结合周边多个系统能力，共同组成的一个**试错平台**。在这个平台上，我们的团队，不管是业务方还是工程师，都可以快速应变，不畏惧**出错**，变得灵动起来。
## A/B测试
说到A/B测试，这到底是个什么东西？我个人的理解是：狭隘的说，A/B测试是以**分桶**为核心，以依据分桶结果**执行不同逻辑**为基本原理，以获取最优解为目的一种测试方案。
一般认为，A/B测试的主要场景有两种：对比实验和灰度发布。
### 对比实验
所谓对比实验，就是同一时间执行两套甚至多套方案，通过对比反馈数据，对这些方案作出评价。
灰度发布则是，某个新功能或版本正式发布前，先圈一部分人作为小白鼠，试用这个功能或版本。我们从稳定性，业务效果等多方面观察这部分试用者的反应，对这个新功能或版本作出评价。
不管是对比实验还是灰度发布，最终目的都是期望只是发布带来的效果最大化。
一个单一的A/B测试并不能帮助我们达成目的，还需要诸多周边能力辅助。要实现丰富的分桶条件，需要设备和用户的信息收集机制；要实现线上逻辑实时调整，要Native逻辑动态化方案；要实现东条调整分桶逻辑，需要分桶条件下发系统；实现观察对比实验结果，需要数据收集和分析平台，等等。
在天猫，我们整合各方能力搭建了一个称为AirTrack的试错平台。在这个平台上包括：
• 条件树
• 状态中心
• 配置中心
• AirTrack SDK
• 数据采集SDK
• 数据分析平台
• 界面动态化解决方案
• 数据投放系统
条件树是以树结构描述的A/B测试分桶条件。根节点是逻辑起点，一层一层向下运算，直至到达叶子节点。
每一个非叶子节点都是一个更细分的逻辑表达式，分为两种：最简单和常用的哈希条件。也就是把设备ID做哈希成一个0-100000的十进制数，同时看给出的各个分桶的比例对0-100000上分段。看哈希结果落在那一段数字中，那么久意味着这个设备命中了相对应的桶。另一个是个性化条件，配置中给定状态名称，运算符和基准值。当前设备的相应的状态值，与给出的基准值进行给定的运算，得出结果为真则进入左子树，否则进入右子树。
每一个叶子节点都是分桶逻辑的重点，在叶子节点中指定对应的桶号。若最终条件树的运算终止于该子节点，则该子节点的桶号就是当前命中桶号，另外除了桶号叶子节点还会带有少量的meta信息，供命中桶内的逻辑执行时参考用。
状态中心收集用户和设备的状态信息，在条件树的个性条件计算中使用的状态值就是从状态中心获得的。
状态中心具与备后端服务的双向同步能力，也就是说状态中心中储存的状态不局限于设备本身，还有大量后端业务状态。在这些业务状态的支持下，条件表达的业务性大大增强。
在《动态调整的基础 —— 配置中心》中对配置中心有详细的介绍，不再赘述。在试错平台中使用配置中心下发订制的实验条件，给平台提供最核心的动态能力。
AirTrack SDK是整个方案的核心部分。
业务方把多个逻辑注册到SDK中。SDK根据业务给定的实验名称在配置中心返回的条件集合中，找到相应的实验条件，再计算出当前设备的分桶信息。依据分桶信息找到诸多注册逻辑中命中的一个，并执行这段逻辑。
在天猫App中有一套成熟的数据采集SDK，数据以界面为线索被收集并同步到后端。我们对这个收集SDK进行一些改造，在AirTrack SDK中自动调用数据采集接口，把执行结果的分桶信息写入埋点。
根据数据采集收集的日志，我们有一套完整的以页面为线索的数据分析平台。在这个平台上我们可以看到页面维度的全部信息，除了PV，UV，点击率等常规数据，该页面的入口和出口流量，转化率等等。
而我们对A/B测试数据的要求也正是这些，所以我们对数据分析平台改造支持分桶统计，可以平行看到各个分桶的数据。
以上这些系统配合起来基本上已经建立了一套完整的A/B测试体系，然而在使用过程中我们会发现，接入A/B测试的逻辑都是硬编码的，动态能力依旧不足。而在日常维护中A/B测试最典型的场景设界面方案，所以我们在把现有的一套界面动态化方案直接改造支持A/B测试。可以根据客户端计算出的分桶信息，展示出不同的样式。
数据投放是配合界面动态化方案的一个平台，我们的业务方在这个系统上投放数据，界面容器会根据分桶信息获取对应的数据。
以上这些就是整个试错平台，或者说天猫的A/B测试体系的概况。后边我们介绍一些实践。
配置灰度发布
之前我们说A/B测试的两个主要场景之一是灰度发布，配置中心是一个典型场景。修改一份配置后，需要对这次变更进行灰度发布，以求安全稳定。
我们预先定义若干灰度方案，每一个灰度方案就是一份A/B测试的实验条件。例如，我们有一份实验条件是：
• 第一个20分钟生效10%
• 第二个20分钟生效50%
• 第三个20分钟生效80%
通过1个小时的灰度，逐步上线。在灰度过程中，我们可以在数据监控平台上实时发现问题，随时终止灰度进程。如果一切正常，那么这个变更就会自动全量发布。
首页模块对比测试在天猫App的首页上有很多坑位，我们在一次坑位变更中，我们使用了对比测试方案。
切除20%的流量作为样本，把样本五五开，10%执行旧逻辑，10%执行新逻辑，在线上试运行两天。根据反馈的数据显示，我们对比两个坑位的转化率和展示效果，发现新坑位效果并没有达到预期。
所以我们撤回新方案，并实施改造，再次上线对比实验，直至达到预期效果。在整个决策过程中，花费了1周时间。然而这样的决策在没有试错平台的情况下，需要跨越1个甚至更多个版本。
我们在实施A/B测试的过程中，发现这个平台除了处理以上的两个场景，还可以有更多功能。甚至可以在常规业务中发挥效果。
个性化弹窗大家应该经历过天猫App首页的红包雨，这是一个独立的弹窗系统。然而在什么条件下出现弹窗这件事并没有很好的解决。最初的方案只是分时间段弹窗，也就是说，弹窗有一个生效队列，到了某个时间点，某个界面一定会弹出某个框。
但，我们希望弹窗逻辑可以更加聪明，能根据设备和用户信息个性化的出现。所以，我们使用AirTrack SDK的配置，把不同的弹窗条件单做桶来看待。通过动态配置AirTrack的分桶逻辑，并指定弹窗桶号来实现了这个个性化弹窗的需求。
以上，就是我们在天猫的三个重要实践场景。
针对，刚才说的A/B测试两个主要场景，补充两张示意图。
Q问题1 如果想简单实现，后台下发一个json配置，里面包含空间名，属性值，动态修改，和这个方案的id，后台记录这个方案id，然后对比效果，这样会有啥问题。
其他逻辑还不是，但我们已经在研究如何用JS来解决native逻辑动态了。
