统计中dp与ep的关系（DPM在数仓建设中的作用）

如今，互联网中的数据仓库，已不单单是数据开发工程师的责任，随着业务的发展和细分，对产品经理提出了更高的要求。

开发工程师往往不能够第一时间深入理解业务，或者说理解的不够透彻，完全交给数仓工程师开发的数据仓库，不但时间过长（需要理解时间成本），而且不能很好的支持业务。这就需要数据产品经理参与数仓的开发中。不但要参与数据的建模和逻辑的梳理，还要做好数据的管理和规划。

本文不讨论数据建模的过程，只聊聊在数据的管理和规划中，数据产品经理应承担的工作内容和职责。

互联网公司，往往依托用户的行为，来搭建用户的相关行为模型进行分析，所以关于用户行为上报的数据，是最基础的数据也是最重要的数据。只有合理、规范的上报，数据才会产生价值。那么如何做好埋点，并且怎样管理好埋点呢？

简单来说：需要的数据进行埋点，以交互为底、业务价值为依据、时间为起点、需求为最终目标进行埋点的设计。

一个埋点对应一个标识，通常一款产品包含数百个埋点，也会随着业务和产品的变化，埋点需要增删修改等，所以对埋点管理也是一个重要的步骤。

埋点管理的内容大致包含如下：

埋点文档中必须写出埋点上报时机，同时描述准确；

参数里记录的是针对埋点行为，所包含的信息，埋点行为不同，对应的信息也不同，所以不能作为公共字段记录在数据表中，会以json形式，记录在字段中，分析时需要使用具体的信息，可通过函数解析出来（get_json_object）。

备注信息的意义就是解释说明，例如文档中只记录了物品和怪物的id，具体的名称没有记录，是因为日志中存储汉子易出现乱码，仅记录id即可达到分析需求，并且减少数据量。

同时，埋点文档中，除了第一页sheet表中展示埋点文档外，其后几页需要写出含多个枚举值参数的编码表，方便数据人员进行分析对照。

埋点文档设计完成后，即可提交至研发同学，进行宣讲。用户行为分析是基于埋点完成，其重要性不言而喻，所以后期埋点验收也需要产品经理的参与，确保埋点的准确性。

如图，目前业内几种埋点方案类型的比较。参考不同类型埋点的特点，在具体的功能场景时，根据具体情况选择对应方案，进行埋点方案的设计。

所谓数据字典，就是用来描述数据指标的一个公司内部的埋点规范。它将数据定义、结构、数据类型、数据逻辑、数据源等进行了一个汇总的文档。那么它的生产与管理过程是怎样的呢？

收集环节是需要对数据字典进行一个详细的定义。需要知晓在业务分析中，数据的使用方关注哪些数据指标、归因包含哪些维度。单纯的从业务产品去思考，会存在缺失，通过与产品/运营同学的交流，可以使字典的内容更加完善。

主要包含两步，新标准的制定和旧标准的修改。新标准除了收集业务方的需求和建议外，还要参考一下业内最新的标准，这样可以满足业内的特定需要。

如果旧标准与现有业务存在冲突，那么就需要积极的与旧标准的业务方沟通，进行因地制宜的协同与调整。

业务数据是企业运营各个环节的共用实体，连接企业的各个系统，如果存在业务数据不一致，上有无法对接运营系统，下游无法进行数据分析和整合，各个系统间的数据无法进行关联，对企业的运营支持就很有限。

那么如何做好这些业务数据的管理呢？

埋点全链路协同流程

以上就是数据产品经理在数仓开发过程中，对数仓的工作内容和职责，主要是集中在数据管理这里，这是一项非常繁琐且重要和有挑战性的工作。如果中间的歧义产生较多，那么就会反馈到业务上来，当进行更深层的业务逻辑分析时，会产生更严重的问题。