本文抽象介绍了一个产品数据体系建设，以支持产品了解数据如何采集、计算与展现。

近期有师弟师妹不断问到产品经理必备技能中，数据分析是怎么回事？产品怎么就有数据可以分析了？

简单了解了下其产生问题的原因与诉求，将其问题拆分为二：

1. 产品的数据体系如何建设？
2. 如何进行数据分析？

关于问题2，网上已经有足够丰富的资源进行学习与讨论，这里不再赘述，简而言之根据运营或迭代的目的进行深度思考与结论沉淀。

以下内容仅针对问题1在产品数据体系思路层面进行介绍，主要面向平台类产品策划。不足之处请多包涵。

一、为何要建设数据分析体系？

任何一个产品的迭代与运营都需要数据进行指导，基于线上数据情况，可以更准确的支持策划与运营同学做出有效决策。

二、数据分析体系包含哪些部分？

不同行业与不同公司对产品体系的定义与诉求不同，这里仅以平台类抽象举例，包含：存储格式、上报逻辑、计算逻辑与展现方式。

三、为什么包含这些内容？

如果PM想监测一种数据，首先需要打开数据报表来查看（即展现方式），而数据报表的制作依赖要拿到这些数据(即上报逻辑)，这些数据上报后如何在后台计算才可以支持报表快速展现(即计算逻辑)，这些数据均基于用户行为触发而生成，因此需要在用户触发某个行为时进行数据上报（即上报逻辑）。

最后，数据上报如果是杂乱无章的，则在进行数据提取时会遇到各种各样复杂的问题，因此我们需要给数据上报定义一个格式，格式和开发约定好，以此格式为依据，开发进行后台数据库定义存储(即存储格式)。

四、每个内容详细是什么？

存储格式

即开发与产品同学约定好的数据上报格式，产品同学根据这个格式制定数据上报账单，开发同学根据这个格式进行数据存储，拿最简单的数据格式举例：

上报逻辑

约定好上报格式后，产品侧根据自身目的定制上报账单，举例：

开发拿到此账单后，根据“上报时机”进行数据上报，上报后数据直接存储到后台以构建的数据库中，即完成数据采集。

其中，“页面id”和“标记id”用于给每个上报分配其“唯一识别标识”，方便后面做出具处理。上报时机则根据自身产品进行定义，通常会有“点击时”、“曝光时”和“停留时”几类。

计算逻辑

通常，产品发布后我们会拿到海量数据上报，如果不对这些数据进行过滤和计算，则后期提取时则耗时巨大。因此需要在数据存储后对数据进行一次过滤，目的是剔除无效数据并加快数据提取速度。这里涉及涉及到比较复杂的数据挖掘算法，每个公司都会搭建专门的数据研发团队，不再赘述，仅用下图简单描述。

展现方式

通常情况下，数据经过一层处理存储到过滤表后，依旧不是我们最终想要的数据，部分数据需要再处理一次并制作数据报表以支持后续快速查看，这里涉及到两个问题：

1，过滤表中的数据如何做成数据报表？
2，数据报表通常有哪些？

第1个问题，这里就与之前的“数据账单”有关，根据之前的数据账单，构建数据处理逻辑，给到开发进行进一步开发，并根据你的目的绘制数据报表格式。拿上面的数据账单举例：

比方说，我想监测“每天点击某个按钮的性别分布是怎样的？”，那么我需要给开发提需求，以“拓展字段1”为区分，开发数据报表，其中标记id为1，仅提取该标记下的数据。报表样式如下：

之后开发即可了解如何进行报表开发，后面只需要等待开发完成，每日定时监测报表数据即可。其他类型的报表逻辑同上。

第2个问题，不同产品的报表区分维度不同，比较常用的有用户数据与用户行为类数据，如果是平台类产品还应该包含内容类数据。

• 用户数据：基于用户生命周期的各项数据。
• 用户行为数据：用户在使用产品时各个页面各个按钮的操作记录。
• 内容类数据：app内容用户消费情况与流转情况(新闻/商品/游戏等均为内容)

五、总结

本文主要介绍一个产品的数据体系建设逻辑，主要包含：“存储格式”、“上报逻辑”、“计算逻辑”和“展现方式”。多数内容抽象到1到2个点进行介绍，仅仅为对数据分析后台建设感兴趣的同学进行思路疏通。

另外，不同公司有不同的数据建设框架，市面上也有不少性价比较高的数据SDK可以直接拿来使用，但思路大同小异。

以上，如有意见或深入问题探讨，可随时联系。

本文由 @观花 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议