作者介绍

@阿泱

一个热爱数据产品的工具人。

“数据人创作者联盟”成员。


01引言


“数据仓库的搭建帮助笔主保证了上层应用的数据质量,对数据需求可做可不做有了把控,对数据需求的输出速度有了把控。因为接触数据仓库,对指标口径也有保证。很多时候笔主是依照于需求顺藤摸瓜摸出来的数仓体系,不断打磨,不断合并,才产生的结果,可复制的内容可能不是太多,仅供参考。”


前一篇笔主分享了自己是通过平台工具+数据仓库搭建的数据产品。这一篇主要分享一下数仓建模,数据仓库搭建。


上案例:


01 业务背景

用户在平台中留下了非常多的行为,浏览、点击、加购、下单等等。每天业务都会说我想看一下首页的访问用户,我想看分类页的访问用户,我想看进入商品详情页的用户有哪些等等,平台还有哪些可以优化的点,现在商品这么多,用户感兴趣的商品有哪些呢。早上10:00数据还没出,数据延迟报警,业务方投诉数据慢;想修改一个bug,明明只动了一个地方其他地方也错了;好多模型指标一样,数值不一样;一个需求一个模型,数据资产极速膨胀。


那怎么样把这些片段的数据组装,产品化、体系化的落在数仓里面,从而提升数据开发效率、降低数据存储的成本、提高数据准确度呢?这是数据产品需要解决的问题

总结分为3个点,业务建模、逻辑建模、物理建模。

  • 业务建模主要是了解原子数据,了解业务,用原子数据对业务进行还原

    盘点原子数据产生逻辑

    调研业务的合作方式

    梳理数据轮廓和分析场景

  • 组建业务分析模型

  • 逻辑建模是根据业务对数据进行分层,

  • 物理建模是根据存储形式和开发手段进行落库落表(前一篇中数梦承接的需求)


02 业务建模

如下图,笔主的课题是用户行为,所以笔主选择的角度是用户操作,从他进入商城到最终下单的一整个业务过程。(业务过程的切入点会有很多,大家可以自行找需要的切入点)


第一步:盘点自己有哪些业务数据,即原子数据有什么,是怎样产生的

结论:原子数据有点击(微信框下拉、点击加入购物车)、浏览(访问商城首页、访问商详页)等,这些数据都是通过埋点获得。


第二步:调研业务分工,配合方式内容,业务目标



结论:这部分重点调研业务侧是怎么样配合的,帮助你做业务需求拆解,把握业务重点。按照业务的思维去看数据,即保证了业务对数据的满意度,又可以让数仓跟上业务的发展脚步。


第三步:补充业务轮廓,分析场景(如上图,主节点其实是人员分工,子节点是应用场景&分析视角)


结论:这部分是基于你对业务的了解和数仓的了解,用数仓的原子数据还原业务。包含大致轮廓,业务是什么,我们要回答业务什么样的问题,用什么样的指标回答业务的问题。这部分大家可以多看看网上的一些分析方法,尽可能准确且多的丰富分析场景


第四步:转化成数据体系的语言即业务建模


结论:这部分主要是用到了AARRR模型增长模型,从用获取->激活->留存->裂变->变现。流量大盘代表获取,资源位分析代表激活,用户留存和用户转化代表留存,营销活动代表裂变+变现。


03

逻辑建模

开发会根据分析场景去规定哪一层输出什么内容,每一个主题,每个一个中间层需要新增那些属性,那些指标其实是根据业务建模的分析场景来定的。数据产品需要尽可能多的输入合理有价值的分析场景,在底层预留字段,这个过程可以很大程度的保证数据的准确性。



结论:笔主会把自己的分析思路、业务组装逻辑告诉给开发,开发会按照应用层反推一些中间层。大家不用推翻重做数仓,可以慢慢了解数仓,一点点的超自己的分析模型去迭代。笔主会参与应用层、主题层、汇总层这三层的数仓模型。应用层主要把控维度和指标,其他只是提大概的建议。


04

物理建模

这部分就不说了,主要是开发在负责。这一点开发会根据任务的调度,数据的复杂度,实现的难度等对数据进行建模。有可能一个数据是从两个模型中取。

上层的数据应用给大家分享一下





写在最后:

前面说到业务建模重点关心人员分工和分析场景,分析场景依赖指标衡量结果是否达成。指标来源于业务场景,来源于运营思路、产品分析思路,把用户的分析思路固化下来,沉淀成数据产品,直接以结论信息传递给用户,提升用户的看数效率。在这个过程指标的口径很重要,需要确保大家对同一指标的理解是一致的下一篇分享指标管理。






点赞(106) 打赏

评论列表 共有 0 条评论

暂无评论
立即
投稿

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部