网站建设 模板中心,wordpress 执行了两次,适合做装饰公司的名字,网上购物网站开发开题报告文章目录不同人群眼中的 AbTestAbTest 不同的功能倚重用户关联性弱#xff0c;经典场景为 Feed - 部门组织形式大多非垂直业务用户关联性强#xff0c;经典场景为 垂类/工具类APP#xff1b;部门组织形式大多为垂直业务康为定律-组织决定产品形态不同应用模式下服务构建开机…
文章目录不同人群眼中的 AbTestAbTest 不同的功能倚重用户关联性弱经典场景为 Feed - 部门组织形式大多非垂直业务用户关联性强经典场景为 垂类/工具类APP部门组织形式大多为垂直业务康为定律-组织决定产品形态不同应用模式下服务构建开机 后置小结想了很久这章应该叫什么最终还是定了 “不同场景下的应用模式”。介绍两种不同场景下的 AbTest 功能形态、及不同的形态造就原因。
注意详细 AbTest 架构设计及实现见文章 广告业务系统 之 辅助决策 —— “ AB 实验平台” AB ? Angelababy ? 噢不拒绝老板拍板决策的神器 用数据说话的决策实验平台 —— AbTest Overlapping Experiment Infrastructure: More, Better, Faster Experimentation
不同人群眼中的 AbTest
依据我不同阶段眼中 AbTest 模式的变化把人生状态分为 三个阶段。
首先是初识初次遇到 AbTest 这种手段但无实际的接触。只知道 AbTest 是通过“生物、化学…”做实验的方式去决出最佳策略或方案具体实现的见识固定在谋篇介绍 AbTest 的架构或要点…文章再次是真实接触 AbTest 服务生产环境中切实需要实现 AbTest 功能。这是已经确认了 AbTest 的两个核心要素随机性 正交性、及三个功能粒度点uv pv 自定义。这个时候脑海里会大概形成对 功能点、及 AbTest 服务应用模式的定义对服务端流量做不同功能粒度的实验第三个阶段是在另一个新的场景中发现一个与已知 AbTest 应用方式有异正在运行的 AbTest。哦其实不同场景中AbTest 也是不一样的。
当然这是某个长度中对同一件事情的不同认知因人而异当然也欢迎雷同。下面就介绍两种应用模式。
AbTest 不同的功能倚重
用户关联性弱经典场景为 Feed - 部门组织形式大多非垂直业务
在这类场景中AbTest 的诉求是 对流量粒度越细越好。常规为uv、pv。 在 Feed 的自然结果中我可以通过 uid 和 pv 做实验。比如 A 部分用户做展示样式AB 部分用户做展示样式B也可以针对当前 C% 的流量做样式 CD%的流量做样式 D。这样通过观察 用户的反馈数据可以确认 A/B 样式的优缺可以通过 相同比例流量下不同的点击/交互频次可以确认 C/D 那种样式收益效果更好。
这个模式下AbTest 需求方往往作为中台或者业务平行部门对生产数据的视角更广、高业务专业局限比较少。
用户关联性强经典场景为 垂类/工具类APP部门组织形式大多为垂直业务
这类场景中AbTest 的诉求相对单一。常规为uv。 在 地图/出行类强依赖登陆的状态下uv 粒度的实验相对占据了全部实验的 99.9%pv 或其他粒度 做起来及其复杂。比如 A 部分用户做展示样式AB 部分用户做展示样式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 只是一个例子换做是其他模块/服务或者是某件事情在不同的场景下都是有因果的、且合适、科学的。
