想了很久这章应该叫什么,最终还是定了 “不同场景下的应用模式”。介绍两种不同场景下的 AbTest 功能形态、及不同的形态造就原因。
注意:详细 AbTest 架构设计及实现,见文章
广告业务系统 之 辅助决策 —— “ AB 实验平台”
AB ? Angelababy ? 噢不,拒绝老板拍板决策的神器 !用数据说话的决策实验平台 —— AbTest !
Overlapping Experiment Infrastructure: More, Better, Faster Experimentation
依据我不同阶段眼中 AbTest 模式的变化,把人生状态分为 三个阶段。
当然这是某个长度中对同一件事情的不同认知,因人而异,当然也欢迎雷同。下面就介绍两种应用模式。
在这类场景中,AbTest 的诉求是 对流量粒度越细越好。常规为,uv、pv。
在 Feed 的自然结果中,我可以通过 uid 和 pv 做实验。比如 A 部分用户做展示样式A,B 部分用户做展示样式B
;也可以针对当前 C% 的流量做样式 C,D%的流量做样式 D
。这样通过观察 用户的反馈数据,可以确认 A/B 样式的优缺;可以通过 相同比例流量下不同的点击/交互频次,可以确认 C/D 那种样式收益效果更好。
这个模式下,AbTest 需求方往往作为中台或者业务平行部门,对生产数据的视角更广、高,业务专业局限比较少。
这类场景中,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 往往具备更多的数据传输问题,是安排在 Header 还是 body、或者 特定协议…. 大家找到最适合当前场景的,才是最佳的。
AbTest 只是一个例子,换做是其他模块/服务,或者是某件事情,在不同的场景下,都是有因果的、且合适、科学的。
下一篇:一文梳理深度学习算法演进