中台产品经理实战(19):数据中台搭建方法论集合(下)

1 评论 2752 浏览 6 收藏 12 分钟

编辑导语:在上篇文章《中台产品经理实战(18):数据中台搭建方法论集合(上)》中,本文作者带领我们完成了中台预建设。接下来,作者又为大家讲解数据中台建设的完整方法论,进入中台建设的解决方案设计,看看具体方案要如何实践,本篇文章为下篇。

一、步骤1:数据集中化存储

在上篇文章中我们谈及了,要进行数据集中化存储,并通过数据中台的建设,从而完成各业务线的改造。

具体来说数据集中化存储就是在进行企业级维度的数据管理,会涉及如下三个子任务:

  1. 各个业务产生的数据汇总;
  2. 数据加工:统一采集、清洗、管理方法(将各个业务线的数据清洗方法以模板形式配置在企业数据引擎中);
  3. 全局数据模型生成。

(某数据清洗引擎运作原理)

完成这三个任务,对应的我们也建立起了一个企业内部的数据自流转体系。

二、步骤2:数据集中加工

在完成了数据集中化管理后,下一步要做的就是建立数据口径管理,实现统一集中计算,具体来说在数据中台中为了实现集中计算,要进行口径管理的一共包含如下4个维度:

举个例子来说,在上篇文章(中台实战19)我们将数据集中化到了数据中台进行存储,但是此时来自各个业务线的数据并不能直接使用,因为不可避免的会出现各个数据名称不统一的情况。

A业务线中会员数据名称:

B业务线中会员数据名称:

此时就需要将各个业务线的数据名称进行统一,这里我们通常会用软映射的方法将不同的业务线数据进行统一起来,也就是建立一张数据表进行字段映射管理。

但是刚才说到的是对现有数据进行管理,对于新的产生的数据我们需要进行归一化管理,以便能让数据进入数据中台时就能统一,此时我们就需要使用一套公司级数据载体进行管理:

  1. 建立唯一指标体系树
  2. 建立统一数据事件

我们来一个个看:

三、步骤3:数据指标体系

这一步我们就开始去建设我们的指标体系,但是在以往的指标体系管理工具中,我们经常会面临到的一个问题是,不同人对数据指标体系有不同的需求。

例如老板更关注的是顶层结果指标,如毛利,成本,盈亏平衡等,但是具体到运营同学身上,可能更关注的是昨日某事件的点击率,转化率这些过程指标。

所以在建设数据中台时,我们要在公司内部建立起一套自上而下的指标体系,以此满足各层级不同需要。此处也相当于是我们把整个公司内部的指标进行了一个梳理。

这里也就是我们数据中台中经常能见到的三级指标体系概念。

我们大体上将指标按使用角色分为三类:

  1. 一级指标:解决管理层的需求,如交易额,净利润,毛利等;
  2. 二级指标:解决执行层路线评价需求,如渠道A收益,链路转化路径长度等;
  3. 三级指标:解决执行层具体执行效果,如步骤转化率,广告位点击率等。

需要注意的是,第三级指标一定要聚焦到用户的动作监控上,例如搜索框场景下,搜索成功率,注册填写页各步骤点击率/转化率,购物车加购时间,购物车等待时间,收藏次数等各个维度的用户行为。

在数据中台中集成这三类数据将帮助我们快速搭建起一个完整的指标框架。

四、步骤4:数据指标管理

当我们建立起了不同层级的数据指标体系后,接下来会遇到的一个问题,在我们指标越来越多后,经常会出现各个指标之间冲突以及难以理解和管理。

例如A业务线存在指标7日渠道转化率,B业务线也存在7日渠道转化率,但是A,B两个业务线对于渠道转化率的定义是不同的。

具体来看这两个业务线中的转化定义:

  • A业务线的渠道转化:指的是用户在网页端完成注册既称为该用户作为活跃用户;
  • B业务线的渠道转化:B业务线因为拥有APP客户端,所以运营定义当用户下载客户端并登录后再计算用户转化。

此时我们可以学习并借用阿里带来的数据解决方案:OneData方法。

OneData方法从本质上来说就是将指标定义进一步细化为两类:

  1. 原子指标:不可拆分的最小颗粒度指标,如活跃数/点击率等;
  2. 派生指标:在原子指标上增加若干维度修饰词组成派生指标。

因此我们在公司内部定义唯一指标时,就可以按照这样的公式来产出指标(派生指标):

原子指标+修饰词 = 派生指标

这里的修饰词可以分为两类:

  1. 面向主题域管理:按照具体的业务线、主题域、业务过程进行定义修饰词,如A业务线留存率,B业务线留存率;
  2. 以时间周期,行为类型定义修饰词,如7日/14日等。

这里传统的留存率指标可以被详细拆解为:留存率+事业线+某模块+7日。

五、步骤5:数据事件集中管理

在工作中,很多时候我们都是在处理各个业务线的突发业务问题分析,例如下述几个场景:

  1. 订单量下降了,帮我看看原因是什么?
  2. 用户注册量下降了,帮我看看原因是什么?

而如果我们用产品的语言进行分析一下后上述场景实际就是这两个需求:

  1. PM:下单事件分析->购买路径的流程分析
  2. PM:注册事件分析->用户从下载到注册的流程分析

在很多地方这样的需求也被称之为数据事件分析,而实际上所谓的数据事件就是一组连续的数据指标集合,这其中每一个数据指标都是按照对应用户的每一步行为操作逻辑关系进行排列的。

例如一个设计导流的功能主流程是这样的:

对应的数据事件就应该是这样组成:

上述表格也是我在整理公司内部数据事件时的统一模版,这样能让我清楚的知道都有哪些事件以及这些事件对于不同的指标的依赖是什么?

因此我们在进行数据中台建设时就应该将整个数据事件在此汇总,以便集中管理。

六、步骤6:设计数据事件

除了集中管理数据事件,更重要的部分是要能进行数据事件定义,这里就需要用到通用事件设计模型。

通用事件设计模型可以分为三个部分:

1. 拆分问题找到具体衡量各元素组成指标

eg:如复购率事件监控=A渠道复购率+B渠道复购率+召回渠道复购率。

2. 定义各描述项的具体权重

eg:在上述拆分出的三个构成因素中定位影响最大的元素,如召回渠道复购率是重要影响项。

3. 结果辅助参考

eg:定义出各指标后,如何根据具体指标变化的得出结果,如复购率根据长时间检测,发现下降3%以内属于正常波动,而超过3%属于复购异常,需要定位原因。

七、步骤7:企业级数据应用

基于数据中台的建设后,我们可以进行二次数据应用开发:

  1. 全局用户推荐系统:集合各业务线的用户偏好,进行用户推荐;
  2. 全局用户画像:集合各业务线的画像数据,生成全公司级的用户画像;
  3. 公司业务资产数字化:通过前面统一了各业务线数据后,可以建立超级节点,实时计算监控全公司的业务数据。

至此我们一个完整的数据中台建设方法论合集就描述完了,大家可以根据自己的业务实际情况进行有的放矢的参考,搭建适合自己公司的数据中台。

最后想要了解更多中台搭建实战内容,或者想要学习掌握更多高阶产品经理的必备技能,可以来看看我的这本《中台产品经理宝典》一书。

#相关阅读#

中台实战(17):支付中台(服务中心)实战

中台实战(12):中台建设的三大误区

中台实战(11):中台产品经理能力模型

#专栏作家#

三爷,微信公众号:三爷茶馆,人人都是产品经理专栏作家,2019年年度作者。《中台产品经理宝典》作者,原万达高级产品、MBA特约讲师、独立创业者,现某支付公司产品线负责人,拥有多款集团项目从零到一经验并带领实现商业化布局。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 自上而下的数据指标体系在原型上面是要从权限上约定吗

    回复