ToB数据化运营：数据产出价值量化模型

本来想探讨一下数据产品和数据服务在业务应用中的价值量化模型，不过这个问题太抽象，目前还没想清楚。可以先从数据开发的角度，来探讨一下产出的数据价值量化模型，这个就具体、清晰、可操作地多。对于开发同学来说，不应该只埋头开发，也需要关心自己产出的数据价值。

其实数据作为一个中间节点，可以以一个很简单、直接、客观的标准来衡量价值：如果下游使用得越多，则价值越高；如果没有下游使用，则没有价值。

数据开发的下游及应用场景主要包含：

• 为数据产品提供交互查询
• 为业务平台提供开发支持
• 为数据分析师adhoc计算用

平台输出与调用数据集成

按照上面的标准，数据产出价值完全由使用频次来衡量，那么就应该尽可能完整地收集调用数据，那当然不能靠手动扔excel，需要通过平台输出并采集调用日志。平台有多个没关系，但日志格式需统一规范，并能聚合起来以作统一处理和计算。包括平台页面访问、SQL查询、接口调用，都需要明确到数据表粒度的日志。

数据仓库血缘地图

数据仓库血缘地图是一个DAG，表征着表节点生产的层次关系；既可用于指导数据生产的层级和顺序，也可用于生产故障的快速定位与影响评估，是一套成熟数仓开发体系必不可少的工具。

在价值量化模型中，也是需要的——因为数据仓库是分层建模的，有的底层表并不直接传输给下游使用，而是靠依赖其生成的上层表交付使用的，这种底层表也是需要参加价值量化计算的。

分层加权PageRank

数仓血缘地图本身是一个网络图，而PageRank算法是一个经典的以连接关系为主体的、计算节点权重的算法，所以当然也是适用于数仓DAG。不过相对于直接套用，有2个核心点需要考虑——

• 表层级：由于PageRank算法的特点，可能会造成越是底层的表，权重越高的倾向——不过最底层的表，往往是从业务系统中直接拉过来的，本身并不凝聚数据开发的逻辑和技术，因此需要把各个表节点本身在数据仓库中的层级考虑进来，并对层级做一个折扣系数
• 调用权重：根据每个表被调用的频次，归一化成权重，作为PageRank排序的初始权重向量；当然，也不一定每次调用都等权重，可以根据部门、用户、调用类型等多因素调整初始权重值

分层PageRank表节点得分

有了得分之后，就可以基于分布划分区间：高价值、中价值、低价值、基本无价值。
打上价值标签后，既可用于需求追踪，也可用于长期复盘。

为什么要做数据产出价值量化？

思想方法（逼格）演示完了，我们再回过头来，为什么要做这件事？

数据团队的ToB服务本身也是需要数据化运营的，开发同学的每一次开发与支持，都需要留下数据，去分析、去复盘，去指导运营，作好数据化运营之后，才能做到——

• 把握重点：数据仓库里那么多的表，打上了价值标签后，你会发现高价值的产出表其实比例是很小的，这样就能快速地get到重点，并且通过核心节点去了解业务主体脉络
• 了解用户：谁是重点用户，谁的需求需要优先支持满足；谁的需求应该降低优先级甚至拒绝？用户的优先级当然与其需求链接的数据价值对等
• 以价值为导向，而不是以支持为导向，将有限的资源向高价值的业务需求中倾斜，减少开发资源的虚耗，对于数据团队的稳定发展具有重要意义

不过需要强调的是，对于低价值需求，其责任并不在于数据开发，更多在于需求方——在于业务方和产品。

那么业务方和产品应该如何提升数据化运营思维，提高数据的整体价值水平？
这个问题下次再讨论吧。