数据产品经理近来炒得比较火热，以至于最近面试了几个想做数据产品的应届生，直言不讳地告诉我：“数据产品有前（钱）景”。

我非常开心他们对我足够的坦诚，但是在“钱景”的高光下，我们可能对数据产品的理解还存在盲区。今天就从几方面带大家重新认识一下数据产品。

因为工作经历、思考深度等原因，我的理解也存在一定的局限性，大家选择性采纳，如有不同的看法也欢迎在下方留言互动~

一、数据产品的分类

我从18年才开始做数据可视化的产品工作，并从19年接手同事的项目后，又开启了画像侧数据产品工作。

而在现公司，我继续做数据产品，但前后工作的两家公司在数据产品的方向上完全不一样：前者是对内的数据产品，而后者是对外的数据产品。

1. 对内的数据产品

前公司是有自己的核心（盈利）业务，而数据产品只是大数据中台部门的一部分，更多的是数据存储、数据计算……以便支持公司各业务线在数据应用、数据分析的方向上的支持，整个数据中台的架构大致如下：

数据存储层是整个公司的数据基础，也是确保数据安全性、时效性、准确性、无二义性（数据孤岛）等，以便形成数据资产的关键。这也是我以及公司其他几个数据产品经理所负责产品系统（数据展示）的数据来源。

1）数据看板系统

数据展示层系统的主要愿景就是减少分析师的常规分析的处理时间，提升业务方数据分析的效率，并协助业务方对业务策略的调整提供依据。

之前的文章也提了，数据看板系统的指标并不是我来配合业务方确认，而仅仅是提供一个承载图表展示的工具。所以，在这个产品上顶多是抓住了业务方的爽点，而协助业务方确定“北极星指标、增长模型……”也只能成为愿景了。

（但在有的公司，数据产品是需要参与到指标建设的工作中的。）

2）画像项目

我在画像项目的工作则是贯穿了从“数据存储”到“数据展示”的整个过程，“哪些画像标签需要实时/离线使用”、“哪些画像标签需要进行实时查询”……这些涉及到数据存储（数据库选型）的工作，需要数据产品和数据开发同学进行配合。

“画像标签是统计类（基于现有数据进行常规计算）还是模型挖掘类（基于现有数据进行预测推断）”、“画像标签是放在分析系统（数据展示层）上查看还是推送系统上应用”……这些涉及到数据计算侧工作，需要数据产品提前整理好画像标签的逻辑、定义和应用场景。

而画像标签也是公司所有业务投放、算法推荐模型中必备的元素之一，所以在整个画像项目涉及的工作，就解决了业务方的痛点。

3）其他说明

对内的数据产品有着得最天独厚的优势：拥有着查询公司数据的权限。这就是虽然我在做数据看板系统时多么的工具化，我也依旧查询数据库自己去发现一些问题主动的去找业务方来沟通数据上的问题，未来的方向是可以专注于某一垂类领域下的数据/数据产品工作。

当然，公司内部有数据产品的一般都是大公司，各个岗位的明确分工，也会让数据产品趋向于工具化、技术化的方向。

分析的工作一般由分析师进行，而数据产品在完成产品设计上线后，除了运营推广工作外，就是在保证“不同颗粒度数据呈现”、“准确性”、“时效性”等问题上频繁地与数据开发同学沟通协调。

最重要的是，很多大企业的数据基建堪忧，这也是数据产品会工具化、技术化的原因之一。

2. 对外的数据产品

而现公司属于 To B 数据服务型公司，核心业务就是售卖数据产品、服务、方案等，以此来满足各企业数字化转型的需求，这看起来确实解决了企业的“痛点”。

1）数字化转型的趋势

基于 CNNIC 《第47次中国互联网络发展状况统计报告》的数据显示，2016年12月~2020年12月，网民规模虽然在增多，但是普及率也在不断扩大，这就意味着互联网的渗透率也非常大，即互联网用户获取的竞争将越来越激烈。

（这也是各大互联网公司开发极速版争夺下沉市场用户、开发大字版争夺老年用户的原因。）

互联网用户获取的竞争越激烈，也就代表着越困难，甚至还会流失，而数字化转型的目标就是帮助客户公司更好地利用好数据。

基于客户的原始数据诊断，通过提供标签体系、指标体系、分析平台（专业模型分析）等数据产品/服务形成数据资产。并在通过提供用户运营中心等营销系统，实现客户的数据价值变现。

前面也提到了，很多公司的数据基建比较差，这也恰恰是 to B 数据服务咨询公司要去解决的客户“痛点”。

2）其他说明

对外的数据产品有着得最天独厚的优势：可以快速了解不同行业的痛点。

当然，缺点也显而易见，因为仅仅是第三方的数据服务公司，很多客户的数据权限很难获取，数据分析的相关工作，短时间内很难接触。

因为深度无法下探，只能在广度上得到延展，所以未来的职业是朝着数据化解决方案的专业领域发展的。

当然，细心的同学已经发现了，我把对外数据产品解决的“痛点”加了引号。套用《人类简史》中说的那样：“科技的发展最终使得人类更累（义同）”。所以，如果企业数字化转型后，是不是会增加更多的人效负担呢？

最近接触的客户，他们现在的业务梳理也是找不到北，没有明确的北极星指标、增长模型……在没有数据权限的前提下，直接套用行业模型落地在客户业务上能够实现价值增长吗？

我想现在谁都给不了明确的答案，而有没有一套方法论支撑起这份工作，我也在继续求索之中。

二、数据产品的用户

从上半部分的内容中，可以看到数据产品分为“主攻沉淀数据资产”的对内数据产品，和“主攻数据解决方案”的对外数据产品。

在之前的文章中，我也曾解释过B端产品的定义：面向角色化用户，设计重视效率的产品。

那今天为什么把这两个产品放在一块说呢？

因为数据产品的本质就是 to B 产品，这就意味着数据产品的用户不是普通的个体，而是不同的角色（岗位）。

数据产品的产品结构可以按照上一篇所拆分的三个部分：存储层、计算层、展示层。

抛去底层计算服务，直接以产品化展示的系统，又可以分为：数据存储、数据计算、数据分析三个大类。

每个数据产品都会服务不同的产品角色，详情可以参考下图展示。

（因为笔者经历有限，所以列举的数据产品如果有遗漏的，也欢迎大家在底部留言。）

由上图就可以清楚地了解到，数据产品的用户角色主要分为两大类：业务、技术。

那接下来，你肯定也会有一个新的问题：“既然都是面向企业级的专业用户，那还会区分出来大明、笨笨、小贤吗？”

这是一个很好的问题，不过我先卖个关子，接下来的内容会解答你的疑惑。

专业用户有时候也并不专业，这里并不是质疑他们的岗位能力，而是在不同的业务领域下，大部分用户都会存在信息断层。

例如，业务方可能不知道分析某个业务的数据相关的字段存储在哪里；同样，分析师可能不会快速知道这次用户的突增是因为上线了某个营销活动。

考虑到普及度和用户角色差异明显的特性，我们这里还是说一下“展示层”的数据产品。

这类的产品的本质是提供数据分析服务，那么这类产品的大明、笨笨、小闲用户分别有什么特点呢？

结合梁宁的阐释，我尝试对“展示层”数据产品的使用者分类进行大胆解释：

大明：有明确的分析需求，有明确的分析思路；
笨笨：有大致的分析需求，没有明确的分析思路（分析思路散乱，没有串联起来）；
小闲：没有分析需求，对业务是一知半解，或深谙其道。

留点时间给大家思考一下，假如你是数据产品的设计者，你会如何规划产品的定位？是只服务大明、笨笨、小闲中的一种用户？还是多种用户呢？如果你也不确定的话，那你可以想一想一个公司里会不会存在这三种用户呢？

首先，大明、笨笨可能会存在的，可是小闲会存在吗？

我个人认为不会。

首先，对业务一知半解的小闲并不会持续一个长期的规程，会随着工作深入，短时间内会成为一个笨笨（对于低频且不重要的需求我们可以选择先放弃）。

其次，深谙业务其道的用户也基本上没有，在变幻莫测的互联网下，数据需求也会慢慢出现。即，数据可视化产品服务的对象是大明和笨笨。

通过数据产品矩阵，基本解决了上述用户的需求痛点。

OLAP 查询工具服务了大明用户，可以在明确的分析思路下快速、便捷地查询数据；组件化分析工具服务了笨笨用户，主题看板辅助用户理清分析思路，自主化探索看板辅助用户完善分析思路；BI 可视化工具比较特殊，既服务大明用户（自己搭建数据集，创建图表、仪表盘），又服务了笨笨用户（了解大致方向，在分析师帮助下，查看分析师搭建的数据看板）。

举个例子：竞品对比哪个服务得更好？

考虑到篇幅原因，这里就先简单说一下 BI 可视化工具的对比吧，服务最好的当然非 Tableau 莫属。这里并不是无脑吹，我将前公司的 BI 可视化工具 unicorn 和 Tableau 的差距做个清单，你就知道 Tableau 的过人之处了。

（如果有遗漏或错误的地方，烦请大家在下方留言指出。如果你有其他的数据产品推荐，也欢迎在下方留言~）