文章目录
想了很久这章应该叫什么，最终还是定了 “不同场景下的应用模式”。介绍两种不同场景下的 AbTest 功能形态、及不同的形态造就原因。
注意：详细 AbTest 架构设计及实现，见文章
不同人群眼中的 AbTest
依据我不同阶段眼中 AbTest 模式的变化，把人生状态分为 三个阶段。
- 首先是初识，初次遇到 AbTest 这种手段，但无实际的接触。只知道 AbTest 是通过“生物、化学…”做实验的方式，去决出最佳策略或方案，具体实现的见识固定在，谋篇介绍 AbTest 的架构或要点…文章；
- 再次是真实接触 AbTest 服务，生产环境中切实需要实现 AbTest 功能。这是已经确认了 AbTest 的两个核心要素，随机性 + 正交性、及三个功能粒度点，uv + pv + 自定义。这个时候，脑海里会大概形成对 功能点、及 AbTest 服务应用模式的定义，对服务端流量做不同功能粒度的实验；
- 第三个阶段是在另一个新的场景中，发现一个与已知 AbTest 应用方式有异正在运行的 AbTest。哦，其实不同场景中，AbTest 也是不一样的。
当然这是某个长度中对同一件事情的不同认知，因人而异，当然也欢迎雷同。下面就介绍两种应用模式。
AbTest 不同的功能倚重
用户关联性弱，经典场景为 Feed - 部门组织形式大多非垂直业务
在这类场景中，AbTest 的诉求是 对流量粒度越细越好。常规为，uv、pv。
在 Feed 的自然结果中，我可以通过 uid 和 pv 做实验。比如 A 部分用户做展示样式A，B 部分用户做展示样式B；也可以针对当前 C% 的流量做样式 C，D%的流量做样式 D。这样通过观察 用户的反馈数据，可以确认 A/B 样式的优缺；可以通过 相同比例流量下不同的点击/交互频次，可以确认 C/D 那种样式收益效果更好。
这个模式下，AbTest 需求方往往作为中台或者业务平行部门，对生产数据的视角更广、高，业务专业局限比较少。
用户关联性强，经典场景为 垂类/工具类APP；部门组织形式大多为垂直业务
这类场景中，AbTest 的诉求相对单一。常规为，uv。
在 地图/出行类强依赖登陆的状态下，uv 粒度的实验相对占据了全部实验的 99.9%，pv 或其他粒度 做起来及其复杂。比如 A 部分用户做展示样式A，B 部分用户做展示样式B…很常规与 Feed 类无异，但如果对 pv 做实验，显的不那么友好。因为要保证实验的正交性，就不可避免的出现 A 用户每次看到的实验效果不同，易对用户产生困扰或报 bug 的举动。当然，并不是不可以，比如一些用户关联性弱的场景，依旧可以做 pv 。
这个模式下，AbTest 需求方往往受垂类业务局限，部门方向走向为用户关联。这样状态下 AbTest 的应用模式就比较单一。
康为定律-组织决定产品形态
康威第一定律：组织设计的产品/设计等价于这个组织的沟通结构。
Conway’s law: Organizations which design systems are constrained to
produce designs which are copies of the communication structures of
these organizations.– Melvin Conway(1967)
线型系统和线型组织架构间有潜在的异质同态特性。异质同态指的是系统和组织虽然是两个东西，但是有相同的结构。
AbTest 不同的应用模式这个问题，也证实了这个定律。组织架构的不同，决定了部门前进的方向，进而确认了产品特征的趋势。
不同应用模式下服务构建
除了上文浅述的 AbTest 功能倚重不同，更深的是，功能的实现及构建方式也不同。准确的说，不同场景下，没有相同、完全一样的服务。 这里完善一下，对应上面场景的模块介入方式，希望可以给予你相关经验。
开机 & 后置
- 针对 垂类、用户关联性强的产品/部门，可以把 AbTest 放置开机阶段，开机往往具有热加载及倒计时逻辑，可以融纳较多的服务。当然，前面重了，就意味着后面服务就轻了。
- 针对 Feed 类，用户关联性弱的产品/部门，可以考虑把 AbTest 放置在 前置或后置服务，这样形成的漏斗具有两极性。
当然这样的方案并不唯一，也不全面。比如，还有 AbTest 往往具备更多的数据传输问题，是安排在 Header 还是 body、或者 特定协议…. 大家找到最适合当前场景的，才是最佳的。
小结
AbTest 只是一个例子，换做是其他模块/服务，或者是某件事情，在不同的场景下，都是有因果的、且合适、科学的。