时间: 2021-07-30 10:56:31 人气: 8 评论: 0
本文抽象介绍了一个产品数据体系建设,以支持产品了解数据如何采集、计算与展现。
近期有师弟师妹不断问到产品经理必备技能中,数据分析是怎么回事?产品怎么就有数据可以分析了?
简单了解了下其产生问题的原因与诉求,将其问题拆分为二:
关于问题2,网上已经有足够丰富的资源进行学习与讨论,这里不再赘述,简而言之根据运营或迭代的目的进行深度思考与结论沉淀。
以下内容仅针对问题1在产品数据体系思路层面进行介绍,主要面向平台类产品策划。不足之处请多包涵。
任何一个产品的迭代与运营都需要数据进行指导,基于线上数据情况,可以更准确的支持策划与运营同学做出有效决策。
不同行业与不同公司对产品体系的定义与诉求不同,这里仅以平台类抽象举例,包含:存储格式、上报逻辑、计算逻辑与展现方式。
如果PM想监测一种数据,首先需要打开数据报表来查看(即展现方式),而数据报表的制作依赖要拿到这些数据(即上报逻辑),这些数据上报后如何在后台计算才可以支持报表快速展现(即计算逻辑),这些数据均基于用户行为触发而生成,因此需要在用户触发某个行为时进行数据上报(即上报逻辑)。
最后,数据上报如果是杂乱无章的,则在进行数据提取时**遇到各种各样复杂的问题,因此我们需要给数据上报定义一个格式,格式和开发约定好,以此格式为依据,开发进行后台数据库定义存储(即存储格式)。
即开发与产品同学约定好的数据上报格式,产品同学根据这个格式制定数据上报账单,开发同学根据这个格式进行数据存储,拿最简单的数据格式举例:
约定好上报格式后,产品侧根据自身目的定制上报账单,举例:
开发拿到此账单后,根据“上报时机”进行数据上报,上报后数据直接存储到后台以构建的数据库中,即完成数据采集。
其中,“页面id”和“标记id”用于给每个上报分配其“唯一识别标识”,方便后面做出具处理。上报时机则根据自身产品进行定义,通常**有“点击时”、“曝光时”和“停留时”几类。
通常,产品发布后我们**拿到海量数据上报,如果不对这些数据进行过滤和计算,则后期提取时则耗时巨大。因此需要在数据存储后对数据进行一次过滤,目的是剔除无效数据并加快数据提取速度。这里涉及涉及到比较复杂的数据挖掘算法,每个公司都**搭建专门的数据研发团队,不再赘述,仅用下图简单描述。
通常情况下,数据经过一层处理存储到过滤表后,依旧不是我们最终想要的数据,部分数据需要再处理一次并制作数据报表以支持后续快速查看,这里涉及到两个问题:
1,过滤表中的数据如何做成数据报表?
2,数据报表通常有哪些?
第1个问题,这里就与之前的“数据账单”有关,根据之前的数据账单,构建数据处理逻辑,给到开发进行进一步开发,并根据你的目的绘制数据报表格式。拿上面的数据账单举例:
比方说,我想监测“每天点击某个按钮的性别分布是怎样的?”,那么我需要给开发提需求,以“拓展字段1”为区分,开发数据报表,其中标记id为1,仅提取该标记下的数据。报表样式如下:
之后开发即可了解如何进行报表开发,后面只需要等待开发完成,每日定时监测报表数据即可。其他类型的报表逻辑同上。
第2个问题,不同产品的报表区分维度不同,比较常用的有用户数据与用户行为类数据,如果是平台类产品还应该包含内容类数据。
本文主要介绍一个产品的数据体系建设逻辑,主要包含:“存储格式”、“上报逻辑”、“计算逻辑”和“展现方式”。多数内容抽象到1到2个点进行介绍,仅仅为对数据分析后台建设感兴趣的同学进行思路疏通。
另外,不同公司有不同的数据建设框架,市面上也有不少性价比较高的数据SDK可以直接拿来使用,但思路大同小异。
以上,如有意见或深入问题探讨,可随时联系。
本文由 @观花 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自 Unsplash,基于 CC0 协议