业务数仓建模，平台工具+数仓构建数据产品

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

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

上案例：

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

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

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

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

  盘点原子数据产生逻辑

  调研业务的合作方式

  梳理数据轮廓和分析场景

• 组建业务分析模型

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

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

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

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

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

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

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

第三步：补充业务轮廓，分析场景（如上图，主节点其实是人员分工，子节点是应用场景&分析视角）

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

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

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

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

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

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

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

写在最后：

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