多表拆解 | 数据PM的工作内容

本文由作者 董小矿 于社区发布

数据产品经理的工作内容有哪些？下文是根据自己在一家内容服务公司的相关工作经历，总结出的有关数据产品经理的工作思路、工作内容。之前一篇文章介绍了我司数据体系搭建过程，见：埋点、数仓到中台：数据体系的从0到1

为了区分数据产品和数据产品经理，下文会用数据产品和数据PM来区分。

本文较长，目录如下：

数据PM的工作内容：

1. 产生数据：

1.1 埋点指标定义-事件表

1.2 埋点指标定义-用户表

1.3 埋点指标定义-默认属性

1.4 埋点数据准确上报监控

 2. 获取数据：

2.1 提需求取数

2.2 SQL查询自助取数

2.3 可视化平台取数和分析

2.4 自助报表取数

3. 数据产品：

        3.1 基础：数据仓库

        3.2 自助报表取数

        3.3 自建可视化数据平台

        3.4 数仓Pro版：数据中台

4. 推广数据能力

4.1 指标地图

4.2 培训（工具+分析思路）

---

先做说明：工作内容分了前后五部分，有一定的、但并不绝对的顺序关系，比如埋点设计和数据治理，是一个伴随始终的工作，而数仓、数据产品建设，则属于比较靠后顺序的工作内容了。

1

产生数据

1.1 埋点指标定义-事件表

一款互联网产品每天产生的数据是庞大杂乱的，全部都存下来会占据硬盘空间，而且，不加定义和标记的数据也很难使用。因此，在初期的数据建设阶段，先要做的是定义想要的数据，告诉前端开发和后台的同事，你想要的数据有哪些，定义这些数据的字段包括但不限于以下字段：

图1：埋点指标定义

上图是我目前管理我司平台埋点的字段，分别解释下：

埋点位置：我司平台覆盖了APP、Web和小程序平台，其中有部分核心功能、页面在三个平台都有涉及（类似于电商平台的商品详情页），分开管理会造成指标冗余，因此对于多平台存在的核心指标，采用的是统一事件名定义，不同平台触发时，数据上报到同一个事件名上，通过平台类型（platform_type）进行拆分；

功能模块：对应埋点所属的大功能板块，如【电子书】功能模块，会尽可能把属于电子书的埋点事件放到该模块进行管理。这里解释下没有向下拆解子功能模块的原因：对于我司业务，区分度比较高，功能模块+具体事件名就能够快速定位到想要的指标了。这点因公司而异；

埋点事件：这个文档我是同时要给开发和运营的同事看的（分开维护的成本太高），对于运营同事来说，他们要关注的字段是下面这些：

图2：运营同事关注的字段

而开发同事关注的是下面这些字段：

图3：开发同事关注的字段

因此针对同一个埋点，至少要考虑的是以上这些字段。（更大平台的埋点字段会更多，欢迎交流）

其中，比较难处理的是【触发时机】的准确定义和描述，举个例子，某页面的pv数据，触发时机定义成加载和加载成功，会是完全不同的数据；又比如，首页模块（也有叫楼层）浏览，模块长短不一，到何种深度会触发对应模块的浏览，需要定义时想清楚，与开发沟通实现细节，避免后期踩坑；

事件变量定义：用来定义事件的参数，也可以理解为事件维度（也有一些实践是把事件表和维度表分别进行管理，我司实践是把二表合二为一）。该字段决定了事件的颗粒度，直接影响到事件下钻的颗粒度，对于数据PM来说，平台不同位置的事件抽象后，尽可能提取出公用事件，然后通过事件变量进行区分，能减少：指标冗余、指标管理工作、培训成本，以及使用者的学习成本。当然这里也并不完全执着于抽象公用性，对于数据PM和开发来说，指标约精简越好，便于理解和管理，但可能对于运营同事来说，学习和使用成本高企，数据产生了但无法最大化应用侧价值，那就得不偿失，所以需要平衡。

举一例，电商产品，商品详情页的事件变量怎么设计，见下图：

图4：商品详情页事件变量

这里你可能会有疑问，如果是传一个【商品id】，其实也就可以通过【商品信息表】，把【商品名称】、【品牌】、【一二级类目】给查出来了，为什么还需要传？这里就涉及到指标管理与数据使用便捷性的权衡：如果不传，在使用的时候免不了要跨表联查，是比较影响使用效率的。在指标管理时常需要通过用空间换时间的方式，来保证数据能比较高效使用，最大化数据的价值。

其他说明：变量值类型，比较常见的有：int、float、boole、string、timestamp；埋点形式，对于自己研发的数据采集系统，一般前端埋点和服务端埋点可以了，如果外采第三方数据采集服务，可能还会有全埋点（详细见上篇文章）；埋点版本和日志，则是帮助你和开发快速回忆这个点的前世今生。如果这篇文章你只记住一句话，我希望是：好好记录指标备注及变更日志。这个工作能让你后面少踩太多坑了。

以上，综合下来，以电商商详页举例，一个埋点事件最后的字段如下：

图5：举例-商品详情页事件指标设计

1.2 埋点指标定义-用户表

用户表，顾名思义是记录用户信息、用户属性的表，通过用户的唯一标识（user_id）能够将事件表和用户表两张表进行关联。事件与用户实现关联，事件表里一条条的数据记录，就不会再是孤立的统计数字，而是能够与具体的用户产生关联进行分析，或者用行为来圈定用户，给用户设定分群和标签。

图6：事件表和用户表的关联

用户表的自定义维度设计与业务关联度最高，除了常规的用户id、用户昵称、注册时间、首次登陆APP时间等字段外，其他偏业务属性字段需要一个比较全局的视角，不仅要与数据运营方沟通，而是要与公司每一个有分析诉求的部门进行沟通，采集他们的数据分析诉求，来提炼抽象出比较通用的用户表。

如上面提到的，如果只是从事件表里把上报的数据聚合成统计数字或者图标，是没有很大意义的，还要能够下钻进行分析。事件表中变量字段的设计是为了从事件反映的用户行为侧进行下钻，而用户表的属性字段则是基于从产生行为的用户本身进行下钻。

举简单一例：当日商品详情页的总浏览数据是上升的，但是总GMV确没有明显提高，从事件侧分析，发现某类异业合作主推的单品商详页浏览数据上升，其他品类商详页没有明确上升；从用户侧分析，该类单品新增流量主要来自于渠道A。从此得出的初步判断是：1）单本对渠道A的用户拉新效果明显；2）但是该类用户被吸引来了，却没有下单，很奇怪，需要确认投放落地页与站内商品信息是否一致，尤其是价格；3）该类用户对平台其他商品的兴趣不高。

说回用户表的属性字段设计，回到那句核心：采集共性诉求，提炼出通用、容易理解的用户表。这个工作其实并不难，考验的是数据PM沟通、提炼真实诉求，并整合成具体的需求的能力。以我司做内容服务的平台举例，用户属性表如下，基本覆盖了通用的用户群的分析：

图7：用户表维度举例

1.3 埋点指标定义-默认属性

除了前面提到的自定义事件和用户属性外，一般客户端或者第三方数据采集SDK还会采集一些默认的属性信息，这些可能不需要你单独去定义，但数据PM需要去了解平台获取的默认字段有哪些。

图8：默认采集字段（部分）

1.4 埋点数据上报监控

埋点的测试和异常检测不同于前后端可见的功能，测试的时候很难完全模拟到实时的操作场景，出问题的时候大多是用的时候捞数据发现不对劲，然后进行 排查，严重点的，是发出去的数据报表，被大佬看到后来反问质疑。这样的情况反复出现几回，会对整个数据团队十分不利，后期别团队再拿数据分析的时候，发现分析出的结论跟预想的不太一致，首先不是检讨产品或运营层面的问题，会先来质疑数据，让数据组来排查数据……

不了解数据流转机制的，会默认前台页面产生的数据，都应该能够被统计到，而数据从触发-上报成功-解析入库-统计更新这条链路上大量工作要做，而且有一些统计类数据的产生很依赖上游任务的效率和质量，导致数据监控是块难啃的骨头，其工作成果：要么能保证数据不出错；要么能及时发现并纠正错误，不要让错误数据进入到分析环节。前者实现难度高，数据血缘关系复杂，很难完全从源头把控清楚，我司目前也是出于后者的监控水平，即及时发现问题处理，尽量不让错误数据流出。

数据监控的工作成果很重要，但是工作过程往往不可见，存在感低，往往给与的重视程度不够高。我司实践并不够完善，大数据组目前是通过异常任务报警来接收异常，每天有一个值班同事跟进处理的方式来“勉强度日”。

2

获取数据

2.1 提需求取数

如果是初期的数据团队，还没有专门的数据分析部门的话，大概率数据PM会接各部门的数据需求。而在数据产品建设不够完善时，只能由数据PM和大数据的小伙伴来处理各类大小不一的数据需求了。

提需求取数，大概是最简单，也是效率最低的方式了。只要需求够明确，梳理好后按优先级发给大数据组，按排期来做就是了。但问题也出在梳理需求上，有些数据需求方的数据敏感度不够高，会出现先提了需求，拿到数据之后发现不是自己真正想要的数据，然后又提了一个追加需求，周而复始无穷尽也……作为数据PM，为了提高自己的工作效率，也为了让大数据组的兄弟们不要整天忙于各种ETL，有必要明确数据需求的规范，要求需求部门想清楚自己的分析诉求，自己想要的数据是否具备证明或者推翻前期猜想的逻辑？

我给各部门数据对接人提需求时的要求：

图9：提交数据需求的说明ppt截图

其中，【期望时间】是大多数人都不太在意、却是我认为最影响需求处理节奏的内容。提的时候不明确要的时间，只说了句【当然越快越好啦】，然后按正常排期处理后。需求方到了自己紧急要数据的节点了，或哭天喊地，或强硬要求，让数据组同事临时来处理。这种情况很影响已经规划了的工作。

2.2 SQL查询自助取数

按照接需求-处理需求的流程走一段时间后，会发现简单的、重复性（可能只是改了时间段，或者提取对象从A改成B）的需求占据了多数以上，不用走数据组，只要能连数据库，简单改改参数，自助取数也是能够实现的。初期我试过自己通过DBeaver这样的工具连接数据库取数，不光处理一些数据需求，我自己也能够通过自助取数对我司数据库的情况有了更深的了解。

SQL语言并不复杂，算是数据PM的通用技能之一。在写完一长串SQL代码，点击Run的那一刻，还会有一些心流的期待。我在跟数据组同事沟通后确认，将几个已经同步好了的离线表的查询权限开放给运营同事，交给他们一些简单却很常用的数据提取语句，是能够实现自助获取，释放一部分数据组的生产力。这中间除了基础的SQL语言能力之外，更重要的是了解数据库哪些表、哪些字段可用，把数据字段distinct出来后，能够理解每一个值所代表的意思，因此，数据PM在这里的工作主要是两部分：

1. 具备基本的SQL能力；

2. 与数据组同事建设并维护数据库字典表。

2.3 可视化平台取数和分析

通过SQL能够解决获得数据的问题，但是数据清洗、建立分析模型的工作还是要手动做，而且在没有很好工具的前提下，清洗、建模的工作学习成本不低，而且会花费大量的时间，无法彻底实现让数据使用者直接使用数据获得结论的程度。

可视化的数据分析平台是目前比较常见的解决方案，我本人没有搭建数据可视化平台经验，而且我自己也不建议C轮之前的公司自己搞，建议外采接入，实现成本和学习成本都是低的。而且在与这类专业的数据服务商对接的过程中，学习到很多数据架构、分析思路层面的东西。

对接此类平台，数据PM往往是第一批接触平台的用户，从POC（Proof of Concept）开始，了解数据平台如何打通设备和不同平台的用户信息、上报数据的机制、常规分析模型的用法等。数据PM要保证自己是公司里对数据指标（埋点设计）和工具最熟悉的人，这样后面才能够给其他小伙伴培训工具的使用。

可视化平台（自建/第三方）的优势在于：

1、使用者只需要关注使用层的数据，通过数据指标字典（后面会讲到）能够快速找到自己想要的数据；

2、有现成的分析模型可用，如事件分析、漏斗分析、留存分析等，且可以保存成概览，下次直接更新日期后查看即可；

3、可以在加上若干条件后，直接获取源数据（相比于SQL取数，又更简单了）。

这里再次提到文档的建设，数据PM可能会对接多部门多个人，如果自己不想陷入到各种沟通的汪洋大海，建议从最开始碰到需要自己解答的问题的时候，就记录下来，到一定量级后就整理一番，将那些共性的问题做成通用的内部QA手册，然后不断完善这个手册。

2.4 报表：定时报表&自助报表取数

如果前三步都做到了，基本上能满足公司90%以上的数据需求了。除此外，有一些按周期更新，面向直接使用（如领导层、投资人看的报表），的场景，需要通过报表来实现。定时报表能解决周期取数的重复性工作，相比人工取数更稳定高效，可以用更复杂的取数逻辑，直接从数据库中获取数据，同时也存在着不够灵活，不容易发现问题的缺点。

我司也只建设到定时报表阶段，自助报表取数是在之前听到一位中原银行的数据总监分享的实践。其核心是：在数据仓库中离线处理好面向主题的各张表，表与表之间降低耦合度，同时表与表之间通过主键进行关联，以实现个性化的拼表和并表。这块内容我不熟悉，不展开。

3

数据产品

3.1 基础：数据仓库

从获取到数据到产出应用层的数据产品，我认为数据仓库是关键。稳健的数仓是一个发力稳定的炮火（数据）输出，它像是整个数据产品化的中台：隔绝源数据和数据产品，通过ETL整理好源数据、将按主题处理好的数据表提供给各数据产品应用。

图10：数据仓库是数据产品的“中台”

稳健的数仓的效用在于：

1、整合企业内各端、各业务线的数据，统一管理，实现数据打通，避免重复造轮子；

2、为数据产品做基础，即使是实时数据的处理，相比于直接读数据库，从数仓消费数据更稳定、安全；

3、（一定程度上）解决业务同事对数据处理的依赖，所需数据直接从数仓获取，释放生产力。

数仓建设的难点在于：一边在修路（整合数据、规范数仓），一边也在跑车（新业务不断产生新的数据，业务端等不及整合）。这大概是所有信息技术公司的问题。对于数仓建设而言，先把业务形态稳定，且应用频次最高的几张表先在数仓中整理好，比如订单表、注册表和最基础常用的用户数据，如内容平台对用户阅读行为的记录表等。数仓建设先把低垂的果实采入囊中，提高运营同事、业务开发的工作效率，逐渐提高对数仓团队的信任，后面再推别的需求会更容易些。

3.2 自助报表取数工具

数仓建设到一定程度，基于基础数据表和元表（对数据仓库各表内容进行解释的表），可以满足自助取数的需求了。在上面有提到通过DBeaver、SSMS这类数据库工具，直接连接数仓取数，需要取数同事具体基本的SQL能力，另一种是将数仓的表进一步主题化、解耦化后，让使用人员通过一个前台页面，直接将所需要的的多张表通过主键关联好后，下载到本地的是一张拼接好、计算好的报表。

3.3 自建可视化数据平台

上一步仍然解决不了的问题是，表格数据的分析建模及可视化，分析的同事仍然需要自己处理数据，使用数据透视表等功能进行分析，效率不高。一个可视化的数据平台能够实现从获取数据-分析数据-展示分析成果的闭环。据我了解到的较大体量的公司，到后期还是会选择自建可视化平台。

以某家第三方数据平台的产品界面为例，作为SaaS平台，提供给客户的功能是相对固定的，客户可以在指标层面上有创新，但是分析框架还是有所限制的（对于大多数客户来说，这些通用分析框架已经足够使用了）。如果业务复杂度高、体量大，且最关键的，有具体的需求和资源支持来做可视化平台，最后都会走向自己建设的道路，可能会采购这类第三方平台的SDK做数据采集工具。

自建平台是大工程，除了开发资源，另一个就是评估有哪些业务指标和分析场景，即使是私有化部署的第三方数据平台也无法满足的。在最后评估ROI之后决定是否自建。对于大公司来说，很可能只是不想接第三方平台而已，就选择自己做了。（我司还没有做过自建平台，最早曾通过Superset这样的开源平台，做过简版的仪表盘和自助查询功能，后因组件支持度不够，在接入某数据平台后，逐步把指标迁移了过去）

图11：某第三方数据平台的首页界面

3.4 数仓Pro版：数据中台

从图10也看到了，数据仓库已经具有“中台”层面的服务理念了：处于中间，隔绝上下的直接流动，但自身提供服务上下的能力。而数据中台在我看来，是数据仓库的Pro版：接入对象更完整、数据单元更主题、服务对象更多元，最终产生了话语权更重要的结果。

数据中台的建设难点在于：如何处于与各业务线的关系？如果数据中台无法解决业务侧的问题，反而需要业务组同事参与接口开发；或者数据中台建设速度赶不上业务的迭代速度；又或者数据中台服务能力不稳定，常出bug等，是很难从容推进中台项目的。中台系统的建设一定需要得到公司高层认可和支持的，这样去谈业务整合才有讨论的基础，其次是在建设早期，先选择那些具有杠杆性质的业务先做，所谓的杠杆业务，ta可能不是主流业务，但自身苦于没有足够资源做系统化，所以先去找这类业务，合作度会比较高，而且一旦整合成功了，能够比较明显提高其工作效率。以此成功案例作为杠杆，既是给中台团队以信心，也是作为敲门砖去整合其他业务。

4

推广数据能力

以上，是从如何产生数据、如何管理数据层面的工作内容。再丰富的指标、再好用的工具，运营同事用不起来也是没有价值的。数据PM除了定义数据和管理数据外，另一块重要的工作是在公司内部推广数据能力，真正让数据为同事所用。从两个方向来解决这个问题：让同事知道有哪些数据指标并且快速找到；让同事们能够使用。

4.1 指标地图和数仓表地图

数据能力推广的第一个难点，是让平台上有哪些数据让大家知道。一个是在各平台埋设的指标，我司采用excel的方式进行管理，问题是指标一多起来，找起来不太方便，对于定义者（我）来说自然很容易找到，但是对于使用者来说则不太友好。即使搜中文名称，也会存在同一个地方，大家用不同的关键词去搜索，比如：模块、版块、板块。

因此在数据指标表的第一个sheet，设计了一个数据指标地图，将不同功能模块的数据指标进行了拆解和说明，运营同事找数据指标之前，先打开指标地图大概定位，然后再去对应的sheet表中寻找对应指标的细节定义和可下钻的维度信息。

图12 数据指标地图

另一块就是数据仓库的各种表的定义。从数仓里自助取数时，会有以下的问题：有哪些表、表格对应的是哪块业务的数据、有哪些字段，字段的含义是什么？这个需要和大数据组一起来明确具体内容了，这个工作并不复杂，就是需要开个小会进行确认，并且约定好，新增表格时，及时更新对表格的解释。

4.2 培训（工具使用+分析思路）

在了解了平台有哪些指标和数据后，下一步就是对工具使用的培训，和分析思路的培训了。

我司实践是：数据PM偏向负责数据工具使用的培训，数据分析团队偏向负责分析思路培训。另外，公司要求每个部门选出一个数据对接人，主要由ta来对接部门内的数据需求收集，简单数据分析需求要能够自行结局。因此要求ta需要比较深度了解指标和工具使用。这种方式的好处是，让真正接触业务的人，通过数据解决问题，或者提出值得用数据判断的分析诉求。同时，也让数据PM和分析团队的精力不致过于分散，把优先培训的对象放在对数据有兴趣、有责任的数据对接人身上，而不是公司全员上。（人人都是分析师？推广成本太高了）

我司前后接入过两家数据服务平台，会发现其工具的分析核心是相似的，其提供的分析模型也较为常用，基本上这几个分析模型能用起来已经能解决大多数的分析问题了。

图13 两家数据平台分析模型

如果没有接入分析平台，也没有自建，也没关系。对基础数据进行清洗后，使用PowerBI、或者最基础的Excel也是能够分析的，并且如果分析思路成为套路，可以把模型保存，下次更新数据就行了。工具可以指导分析思路、提高分析效率，但不是分析的瓶颈。

5

总结

数据PM工作的核心是让数据为公司业务产生价值。

涉及到的工作内容包括：生产数据-管理数据-数据产品-推广使用，过程中需要与大数据团队、数据分析团队进行比较密切的合作。如果贵司处于正在从业务思维往数据思维转型，或者处于数据基础能力建设阶段，数据PM的大部分工作还是跟底层数据指标打交道，每天打开最多的工具软件是excel。

在不断完善数据丰富度、准确度、使用度的过程中，希望你也能发现数据之美。

Life's short, I love excel.

------正文分割线------

点个“在看”吧