作者介绍
@阿泱
一个热爱数据产品的工具人。
“数据人创作者联盟”成员。
01引言
“数据仓库的搭建帮助笔主保证了上层应用的数据质量,对数据需求可做可不做有了把控,对数据需求的输出速度有了把控。因为接触数据仓库,对指标口径也有保证。很多时候笔主是依照于需求顺藤摸瓜摸出来的数仓体系,不断打磨,不断合并,才产生的结果,可复制的内容可能不是太多,仅供参考。”
前一篇笔主分享了自己是通过平台工具+数据仓库搭建的数据产品。这一篇主要分享一下数仓建模,数据仓库搭建。
上案例:
01 业务背景
用户在平台中留下了非常多的行为,浏览、点击、加购、下单等等。每天业务都会说我想看一下首页的访问用户,我想看分类页的访问用户,我想看进入商品详情页的用户有哪些等等,平台还有哪些可以优化的点,现在商品这么多,用户感兴趣的商品有哪些呢。早上10:00数据还没出,数据延迟报警,业务方投诉数据慢;想修改一个bug,明明只动了一个地方其他地方也错了;好多模型指标一样,数值不一样;一个需求一个模型,数据资产极速膨胀。
那怎么样把这些片段的数据组装,产品化、体系化的落在数仓里面,从而提升数据开发效率、降低数据存储的成本、提高数据准确度呢?这是数据产品需要解决的问题
总结分为3个点,业务建模、逻辑建模、物理建模。
-
业务建模主要是了解原子数据,了解业务,用原子数据对业务进行还原
盘点原子数据产生逻辑
调研业务的合作方式
梳理数据轮廓和分析场景
-
组建业务分析模型
-
逻辑建模是根据业务对数据进行分层,
-
物理建模是根据存储形式和开发手段进行落库落表(前一篇中数梦承接的需求)
02 业务建模
如下图,笔主的课题是用户行为,所以笔主选择的角度是用户操作,从他进入商城到最终下单的一整个业务过程。(业务过程的切入点会有很多,大家可以自行找需要的切入点)
第一步:盘点自己有哪些业务数据,即原子数据有什么,是怎样产生的
结论:原子数据有点击(微信框下拉、点击加入购物车)、浏览(访问商城首页、访问商详页)等,这些数据都是通过埋点获得。
第二步:调研业务分工,配合方式内容,业务目标
结论:这部分重点调研业务侧是怎么样配合的,帮助你做业务需求拆解,把握业务重点。按照业务的思维去看数据,即保证了业务对数据的满意度,又可以让数仓跟上业务的发展脚步。
第三步:补充业务轮廓,分析场景(如上图,主节点其实是人员分工,子节点是应用场景&分析视角)
结论:这部分是基于你对业务的了解和数仓的了解,用数仓的原子数据还原业务。包含大致轮廓,业务是什么,我们要回答业务什么样的问题,用什么样的指标回答业务的问题。这部分大家可以多看看网上的一些分析方法,尽可能准确且多的丰富分析场景
第四步:转化成数据体系的语言即业务建模
结论:这部分主要是用到了AARRR模型增长模型,从用获取->激活->留存->裂变->变现。流量大盘代表获取,资源位分析代表激活,用户留存和用户转化代表留存,营销活动代表裂变+变现。
03
逻辑建模
开发会根据分析场景去规定哪一层输出什么内容,每一个主题,每个一个中间层需要新增那些属性,那些指标其实是根据业务建模的分析场景来定的。数据产品需要尽可能多的输入合理有价值的分析场景,在底层预留字段,这个过程可以很大程度的保证数据的准确性。
结论:笔主会把自己的分析思路、业务组装逻辑告诉给开发,开发会按照应用层反推一些中间层。大家不用推翻重做数仓,可以慢慢了解数仓,一点点的超自己的分析模型去迭代。笔主会参与应用层、主题层、汇总层这三层的数仓模型。应用层主要把控维度和指标,其他只是提大概的建议。
04
物理建模
这部分就不说了,主要是开发在负责。这一点开发会根据任务的调度,数据的复杂度,实现的难度等对数据进行建模。有可能一个数据是从两个模型中取。
上层的数据应用给大家分享一下
写在最后:
前面说到业务建模重点关心人员分工和分析场景,分析场景依赖指标衡量结果是否达成。指标来源于业务场景,来源于运营思路、产品分析思路,把用户的分析思路固化下来,沉淀成数据产品,直接以结论信息传递给用户,提升用户的看数效率。在这个过程指标的口径很重要,需要确保大家对同一指标的理解是一致的下一篇分享指标管理。