1.2.1.3 大数据方法论与实践指南-一种跨团队业务结算方式探索

针对企业内部不同团队定位&工作内部不同，但是还是要有对公司贡献度相对大小对比。以下为作者个人，从收益&成本方面进行的一次尝试性思考。

针对业务目标来说：按照业务划分团队，是最高效的公司治理方式。因此公司主要团队由以下组成：增长、内容、社交、商业化、其它支撑团队。每个团队都努力通过团队成员的努力（策略）将团队外部资源变为有意义业务产出过程。团队划分要遵守高内聚，低耦合的方式才会最高效。团队边界要清晰，对应的产出要可量化。

团队	职责	产出量化方式
商业化	内部流量变现	内部流量：用户活跃时长/帖子浏览量 商业收入
增长	采买外部流量转化为内部流量	营销费用 外部流量用户在 app 内部停留&转化
内容	以内容为核心增加用户停留	用户帖子浏览量 用户使用时长
社交	以关系为核心增加用户停留	用户使用时长
支持团队（数据举例）	提供数据基础服务 以数据视角促进其他团队业务目标达成	业务需求支持需求数 数据角度协助业务完成各自团队业务指标

全局来说，业务收益要大于成本，公司才能持续运转。因此每个团队目标应该在有限资源（成本）下努力达成业务目标（收益）。所有团队的业务目标都是业务团队最直接获取的，因此从权责一致的原则，所有的成本最终也要均摊到所有业务团队上。

每个团队都是为业务最终目标服务的，也会有对应的成本（人力，工位，IT 成本，流量）因此公司内每个团队的业务收益和成本的流动关系如下图所示。

团队绝对收益=业务共享的业务收益-分享给下游的业务收益-本团队直接成本（人力，直接购买服务等）；

由上公式可以看出，本团队为整体业务做出的贡献以及针对团队内部发起的技改节省的 IT 成本、人员优化节省人力成本都会直接体现在团队的绝对收益中。团队可以根据各个方向产生的收益进行投入均衡性衡量。

公司的整体绝对收益（利润）=sum（所有团队绝对收益）

收益传导原则：距离最终直接收益的链路（时间）越长，分成比例越低。

用户行为路径也就是转化链路就是流量转化为收益的链路，最终收益按照此流向反向分成。

流量分为两类：

1. app 内部流量：此流量的直接受益方为具体某个功能，因此可以从最终货币化收益产出阶段，反向按照用户行为路径逐层向上进行收益分配

一种基于埋点页面栈的导流计算方案

背景

假设 1：一个 app 会有多个用户路径进入同一个功能，比如微信的朋友圈和视频号->朋友页面：两个页面点击朋友头像都会进入朋友主页页面，继而产出后一系列聊天，查看朋友圈行为。

假设 2：朋友圈、视频号属、用户主页属于不同团队

假设 3: 用户的使用时长是产品核心指标，每个功能也以此结算作为对产品总体贡献度

问题：各个团队如何计算自己团队对于核心指标时长的贡献度

埋点上报数据：

uid：用户唯一 id

埋点事件 id：单个设备中的事件自增 id，此处只关注 PV 事件

页面栈列表：将用户页面栈上报，栈中记录 PV 的事件 ID（用户点击 app 中或者系统返回按钮弹出栈，点击回主页清空栈重新计数）

计算方案：

最直接的思路：每个页面都归属于唯一一个业务方，导流作为单独阶段按比例分享（比如 30%）

获取当前 PV 前一个 PV 事件作为流量来源，分成 30%本页面时长到上游一级页面所属业务方

利用页面栈获取前后页面的导流关系

步骤 1 展示当前 C 页面的上游页面是 B，导流关系 B->C

步骤 2 展示当前 D 页面的上游页面是 C，导流关系 C->D

步骤 3 展示当前 C 页面的上游页面是 B，导流关系 B->C（和步骤一中的 C 是同一个页面）

步骤 4 展示当前 E 页面的上游页面是 C，导流关系 C->E

如上所述可以解决多屏同时展示及多级页面间的导流关系问题。

多级导流分成模式可以逐层向上计算：步骤 1 中：C 70%（1-30%）收益归属页面所属业务，30%*（1-30%）收益归属上 1 级页面归属业务 B， （30%）（30%）收益归属到 2 级上游页面 A。

业务 X 的上游共 N 级页面，每级页面从 X 业务分享收益：

n<N 时：V（n）=（1-0.3）（0.3**n）

n=N 时：V（n）= 0.3 ** n （0.3 的 n 次方）

n 代表第几级上游页面，0 代表本页面

1. app 外部流量（拉新）：此流量的直接受益方为整个 app 整体，因此整体收益都应向拉新团队分享。

团队产出货币化：

问题：团队在公司业务流程中的定位不同，发挥作用不同，对其要求产出的服务也不同，如何在不同的场景进行利弊权衡。

1. 策略之间：外部直接买量、扩容团队进行内容运营、开发新功能如何进行取舍

2. 团队之间：新的预算给到什么部门才能带来最大收益增益

3. 团队内部：招聘三个算法进行研发还是直接采购外部服务

4. 时间维度：同一个部门在产出同样收益场景下是否更高效了

解法：团队的产出归一化为货币。

成本货币化后可以解决多个管理难题：

1. 多个收益之间的取舍：

   1. 假如上线一个实验导致 A 功能使用人数减少，B 功能使用人数增多，可以依据收益货币化进行横向对比（当然，具体是否需要置换管理层可以依据具体情况进行判断，至少有一个参考数据）

   2. 资源有限情况下，需要在多个选项中选择一个功能进行上线，可以根据预期收益进行横向衡量

2. 系统优化与业务收益权衡：

   1. 降本增效和业务研发进行人力资源的冲突：这样研发可以根据降本产出收益和新业务上线收益进行对比权衡

   2. 性能优化和业务收益的收益：针对系统可用时间到底是 99.9%还是 99.99% 通过业务收益判断是否进行技术优化

3. 成本最优化问题：

   1. 到底是自研还是直接市场化采购（技术团队的建立本身也是一种资产，可以量化为此付出的成本）

   2. 人力资源本身是成本，机器资源也是成本：在取得同样业务收益的情况下，到底是进行研发投入还是对机器成本进行优化

归一化准则：

路径：从共外部收益层（商业化）按照收益共享路径（成本均摊逆路径）逐层进行计算。

比例：比例应该是和团队职责边界一同确定的。同时又不能总是固定的（一个改进不能让这个团队吃一辈子）。比例是个动态过程，而且比例直接会影响一个团队的投入产出比，影响团队成员的绩效。因为不同团队比例是此消彼长过程，因此比例设计要能有说服力。并且比例要有在制定目标前就确定，以此激励团队在未来的一个绩效周期积极进行降本&增效。作者想到的最优解：上一个考核周期内的成本比例就是本考核周期内的收益贡献比例。（这也要求连续两个考核周期内团队定位是一致的）

举例：

在业务变现场景（比如商业化场景）：团队在基础设施支撑下将流量进行变现。

收入&利润&成本关系如下：收入=团队策略*流量

各个部分比例依据内部团队过去一段时间的投入比例进行设定。

为提升团队内部自我优化动力：可以将此比例依据历史投入比例及近期响应调整固化比例，按年更新。

比如：过去一个周期（一年）：流量费用 A（假设变现唯一途径是信息流广告，广告规则 5 出 1），广场帖子流量计数为 N（代表 N 个广告位），团队成本 B，营收为 C：

流量团队收益占比：B/（A+B）

流量团队价值：B/（A+B）*C

单位流量价值：B/（A+B）*C/N

团队 OKR 设置：

依据以上收益共享，成本均摊的流程，每个团队都会有收益和成本的明细：

比如某团队 24 年初设置年度 OKR，依据 2023 年数据计算流程如下：

		上游			下游
		团队 A	团队 B	汇总	团队 C（自身）	团队 D	团队 E
2023 年	收益共享（单位亿）	100	70	170
	团队量化产出：					广场帖子浏览：30 亿	用户时长：20 万分钟
	成本（单位亿）			103	13	50	40

1. 团队总体收益：170 亿，利润：68 亿

2. 团队总成本：103 亿

3. 团队单位产出收益：

   1. 团队 D：单位帖子浏览收益=收益分成/帖子量=50/（13+50+40）*170/30= 2.7508 亿元/亿次

   2. 团队 E：单位用户时长收益=收益分成/时长=40/（13+50+40）*170/20= 3.3009 亿元/万分钟

4. 团队单位产出成本：

   1. 团队 D：单位帖子浏览成本=收益分成/帖子量=50/30= 1.6667 亿元/亿次

   2. 团队 E：单位用户时长成本=收益分成/时长=40/20= 2 亿元/万分钟

团队 OKR 复盘：

		上游			下游
		团队 A	团队 B	汇总	团队 C（自身）	团队 D	团队 E
2023 年	收益共享	100	70	170
	单位产出收益					广场帖子浏览：30 亿	用户时长：20 万分钟
	成本			103	13	50	40
2024 年	收益共享	120	90	210	0.941	110.032	99.027
	团队产出					广场帖子浏览：40 亿	用户时长：30 万分钟
	成本			122	12	60	50
	团队利润			88

24 年底：

1. 团队总体收益：210 亿，利润：97 亿

2. 本团队收益：

   1. 团队 D 收益共享：40 亿次*2.7508 亿元/亿次=110.032 亿元

   2. 团队 E 收益共享：30 万分钟*3.3009 亿元/万分钟=99.027 亿元

   3. 本团队收益：210-110.032-99.027=0.941 亿元

3. 单位产出成本：

   1. 团队 D：单位帖子浏览成本=收益分成/帖子量=60/40= 1.5 亿元/亿次

   2. 团队 E：单位用户时长成本=收益分成/时长=50/30=1.6667 亿元/万分钟

4. 团队利润：

   1. 团队 D 利润：40 亿次*2.7508 亿元/亿次=50.032 亿元

   2. 团队 E 利润：40 亿次*2.7508 亿元/亿次=49.027 亿元

   3. 本团队利润：0.941-12=-11.059 亿元

OKR 结果分析：

团队整体营收，成本，利润都有增长，增长由 D、E 团队贡献，本团队运营效率相对去年变低了。

D 团队规模更大&效率更高了：单位帖子的成本效率更低了：1.6667 降低为：1.5 。

E 团队规模更大&效率更高了：单位帖子的成本效率更低了：2 降低为：1.6667。

本团队：运营效率更低了。

具体团队区别说明：

1. 增长团队：

拉新，拉活（短信，推送，广告等方式）：本质都是花钱买流量。

拉新用户：是将外部用户（陌生用户）流量引入此 app，因此后续此用户在 app 整个使用周期内的用户都应该与此次拉新活动相关，但是随时时间流逝，比如 1 年之后的用户消费行为和用户使用某个功能更关系更大，受拉新的影响很小了。合理的 app 内收益分成的方式应该是：拉新用户在一定时间内（比如 30 天）内的收益按照一定比例分成给拉新行为。这个时间不能太短：否则不能确定是否是作弊流量（众包中的下载&注册某个 app 活跃几天后给多少钱）及非 app 核心目标用户（通过误导性的拉新素材，导致用户注册后对 app 功能失望快速流失）；

拉活用户：是将已经注册用户从外部平台流量引入到 app 中某个功能，因此收益就和普通用户从 app 内一个功能导流到另一个功能一样。

1. 支持团队：

支撑团队也可以将自己提供的服务进行如此货币化分享业务收益，这样支撑团队因为有直接可量化的业务收益可以获得较强的业务参与感。同时，各个团队内部进行的提效，会将提效收益留存在团队内部。这可以解决一个业界通用困境：

不同团队的技术强项不同，专业的基础架构团队一般一般拥有对降本增效、稳定性提升等架构方面有更通用的解决方案；定期的跨团队技术交流可以为架构优化提供更多的视角。