3. 数据即产品

说实话，我第一次听到“数据即产品”这个说法时，心里是有点抵触的。那时候我还在做传统数据平台，每天忙着搭管道、修脏数据、应付各种临时取数需求。数据就是数据，哪来的产品？

后来我参与了一个跨部门的数据项目，才真正明白这个转变有多重要。你想想看，如果数据团队只是“接需求、做报表”，那永远是被动的。但如果你把数据当成产品来经营——有用户、有生命周期、有质量标准——整个协作模式就变了。

这一章，我们就来聊聊数据产品的定义、生命周期，以及怎么定 SLA。

什么是数据产品？

数据产品不是“数据+产品”的简单拼接。我个人习惯这样定义：数据产品是经过封装、可复用、有明确消费场景的数据资产。

举个例子。你有一张用户行为日志表，这是原始数据。但你把它清洗、聚合、加上业务标签，做成一个“用户活跃度指标 API”，供多个业务方调用——这就是数据产品。

我在项目中遇到过一种尴尬情况：数据团队花了两周做了一个“用户画像宽表”，结果业务方根本不知道有这个东西。后来我们建了一个数据产品目录，每个产品都配了“说明书”，才解决了这个问题。

数据产品和普通数据资产的区别，我整理了一张表：

维度	数据资产	数据产品
消费方式	需要手动处理	开箱即用
文档	可有可无	必须完整
SLA	没有承诺	有明确承诺
负责人	模糊	明确的数据产品经理
版本管理	无	有版本号和变更日志

数据产品的生命周期

数据产品不是一锤子买卖。它有自己的生命周期，我把它分成五个阶段：

1. 规划与设计：定义用户、场景、输出格式
2. 开发与构建：写管道、做质量检查、写文档
3. 发布与运营：上线、监控、处理反馈
4. 迭代与优化：根据使用数据改进
5. 退役与归档：不再使用时，通知用户并归档

嗯，这里要注意：很多团队只做到第2步，就以为完事了。实际上，运营和迭代才是数据产品真正创造价值的地方。

我曾经接手过一个“用户流失预测模型”，上线后没人用。后来一查，文档是半年前的，特征定义已经变了，预测结果根本不准。这就是典型的“只开发不运营”。

下面这张图展示了数据产品的完整生命周期：

数据产品的质量标准

数据产品好不好，不能光靠感觉。我建议从四个维度来衡量：

• 准确性：数据是否真实反映了业务事实？有没有偏差？
• 完整性：关键字段有没有缺失？覆盖度够不够？
• 及时性：数据更新的延迟是否在可接受范围内？
• 一致性：不同数据源之间是否对得上？

每个质量标准都要有具体的度量方式。比如：

质量维度	度量指标	可接受阈值
准确性	抽样验证通过率	≥ 99%
完整性	非空字段比例	≥ 95%
及时性	数据产出延迟	≤ 30 分钟
一致性	跨源字段匹配率	≥ 98%

SLA：数据产品的“服务承诺书”

SLA（Service Level Agreement）是数据产品团队对消费者的正式承诺。说白了，就是“我保证什么时间、什么质量给你数据，如果没做到，我承担什么责任”。

一个完整的数据产品 SLA 应该包含：

1. 可用性承诺：数据接口或表的可用时间（如 99.9%）
2. 延迟承诺：数据从产生到可用的最大延迟
3. 质量承诺：准确性、完整性等指标的最低要求
4. 响应承诺：对问题反馈的响应时间
5. 惩罚机制：未达标时的补偿或升级流程

下面是一个实际项目中用过的 SLA 模板：

数据产品名称：用户活跃度日表
版本：v2.3
负责人：张三（数据产品经理）

SLA 条款：
1. 可用性：数据表每日 08:00 前可用，可用率 ≥ 99.5%
2. 延迟：T+1 数据，最晚 08:30 产出
3. 准确性：关键字段（user_id, active_days）抽样准确率 ≥ 99%
4. 完整性：核心字段非空率 ≥ 98%
5. 响应：问题反馈后 2 小时内确认，4 小时内给出修复计划

未达标处理：
- 单次延迟超过 30 分钟：邮件通知所有订阅方
- 连续 3 天延迟：升级至数据平台负责人
- 准确性低于 95%：立即下线，修复后重新发布

嗯，这里有个细节：SLA 不是越严格越好。我建议根据数据产品的消费场景来定。比如给实时风控用的数据，延迟 SLA 可能是秒级；给周报用的数据，小时级就够了。定得太严，团队疲于奔命；定得太松，业务方不信任。

小结

数据即产品，本质上是一种思维转变。它要求我们把数据当成有用户、有生命周期、有质量承诺的“产品”来经营，而不是一堆等着被消费的“原材料”。

这一章我们聊了三个核心点：

• 数据产品的定义和特征
• 数据产品的五个生命周期阶段
• 质量标准和 SLA 的制定方法