0°

数据产品经理如何从0开始做数据平台

此行至此+++数据产品经理如何从0开始做数据平台+++2018-06-28+++http://www.woshipm.com/pmd/1073453.html

数据平台在产品发展中的定位是怎样的呢?应该何时搭建数据平台?数据平台的作用又是什么呢?数据产品经理如何从0开始做数据平台?

我是一名创业公司的产品经理,从0到1做公司的产品,近两年,因公司业务发展的需要,开始做公司内部的数据平台,我也由一名业务产品经理转为数据产品经理。以下是我结合自身工作的一些总结,与大家分享。

数据平台的定位

产品经理看事情总是先面后点,我们也按照这个思路来展开话题。

那么数据平台在产品发展中的定位是怎样的呢?应该何时搭建数据平台?数据平台的作用又是什么呢?

请看下图:

1. 试错期的回音壁

我们的主产品是做社区O2O电商平台,上图也是以此为背景进行展开的。

我们的主产品2015年下旬上线,彼时公司对产品的定位还不清晰。连续几个版本基本上就是“试试试”,产品团队开展了大量的竞品调研以及用户调研,针对于社区业主,我们先后提供了物业服务、社交服务、优选商品服务、周边信息服务等。公司的业务部门也不断招人,组建新团队,支撑各个业务。

这个阶段,全公司上下都在埋头做业务,对于做数据平台,一是没意识,二是没概念,三是没精力,四是没必要,所以这个阶段的数据建设主要依靠第三方平台。通过埋点和漏斗,完全可以掌握产品的基本情况,哪个功能访问量高,哪个功能访问量低,迭代后的效果如何,一看便知。

(上图截取自友盟的demo )

2. 拉升期的度量尺

通过一年的内功修炼,我们逐渐搞清了套路,2016年中旬,开始做推广、拉用户。公司开始制定KPI,各个业务部门开始背指标,我们的自建数据平台也是从这时开始的。之所以开始做自建的数据平台,主要为了方便考核,大家都懂的。

平台的主要内容就是各类报表、分部门、分渠道的各类指标。

上图是我们的一张报表,因为我们的业务是围绕社区开展的,故此以社区为维度考核,这张报表监控了每个社区的注册用户数、认证用户数。

除了做报表,在这个阶段也要同步建立数据的权限管理,毕竟老板不希望每个员工都知道公司全部的数据。

3. 转化期的显微镜

熟悉产品生命周期的各位同行都知道,拉升期之后该开始做转化了。到了这个阶段,数据的事情就有些复杂了。我们在2017年,做了一整年的商城,配套也做了一系列数据产品。包括交易数据、用户数据、商品数据、实时数据、会员数据等。

这个阶段最主要的任务是为业务部门提供方便的数据分析的模型,发挥数据的显微镜作用,让数据能够即时、准确的反映业务实质、帮助业务进行改进。

关于数据模型的,后面的内容会提到。

4. 平台期的指挥舱

“指挥舱”这个词有点大,但概念却恰如其分。到了平台期,产品已经成为比较大的流量入口,各个商家开始重视平台的作用,投入人力、物力运营自己的店铺。这时,数据产品也要及时跟进,为他们的运营提供支持。就像淘宝、京东商家的数据后台,可以方便的帮商家查询各类信息。

这个阶段数据的第二个应用是推荐系统和搜索系统,当用户数和SKU数足够大时,让用户快速的找到自己想要的商品,能够极大的缩短决策流程,对转化率大有帮助。

当然,在这个阶段,我们利用数据还可以做风控系统,预测系统等大数据产品,帮助平台更加健康的成长。

现阶段,我们刚刚要开始做平台期的事情,所以在这方面的经验并不是很充分,以上的内容来自于自己的学习和判断,仅供参考。

数据平台的三大法宝

在数据平台的建设过程中,有诸多的要点,但有三个方面还是要单独拿出来说,因为他们实在是太重要了。指标、维度、模型我认为是数据平台建设的三大法宝。

1. 指标第一

指标!指标!指标!

对于指标这个概念的重要性,强调再多遍也不过分,我在这上面踩了不少坑。

刚开始做数据平台时,我们的CTO跟我说先整理指标和维度,我不以为然,在网上找了个帖子直接了事。结果一系列挖坑的过程就此开始了,产品上线后,业务说数不准,我说没问题,都核对过了。结果找来找去是双方对指标的定义不统一。

关于指标有两个方面经验跟大家分享。

(1)原始指标和聚合指标

在我们定义指标时,要分清楚那些是原始指标,那些是聚合指标。

业务上直接产生的数据就是原始指标;按照某个维度进行计算后的指标就是聚合指标。正常的顺序是先定义原始指标,再定义聚合指标。

举个例子说明:

一条订单记录,订单金额就是原始指标;计算一天的GMV就是聚合指标。

  • 定义原始指标时,概念要清晰,例如:定义订单金额时,算不算邮费、算不算优惠等。
  • 定义聚合指标时,维度要清晰,例如:我们公司的例会通常是每周六召开,所以我们在统计时设置了一个例会周的概念,例会周是从上周六到本周五。kpi指标都是按这个维度聚合。

(2)指标的迭代

指标要跟着业务的发展进行迭代。

我们在做会员时,有一个最基础的指标:增加会员数。这个指标看似简单,但我们经过了几个版本的修正。

请看下图:

上图中可以看出:概念和指标,会随着业务变化而变化。

值得一提的是:表中的指标都是聚合指标,在我们做这个定义之前还应该做好维度的定义,例如:净增会员数=新增会员数-减少会员数。新增会员数是按照充值的时间聚合;减少的时间按照退会或者出会的时间聚合(而不是这个用户成为会员的时间)。

我们应在数据平台建设的初期,建立好指标库,指标库尽量详尽和丰富。指标的概念应该与业务核对清楚,并由领导审批,最后交给技术。

指标库是全公司公共的概念,业务考核、产品迭代,都是以此为基准。

2. 维度第二

维度的存在,让指标变得更加立体,就像OLAP中的多维数据模型。事实上,维度的建设会比指标更加贴近业务,市场上的做电商的平台,可能大部分指标都是相同的,但每个平台一定会有一些特有的核心维度,这些特有的维度也恰恰定义了企业的商业模式。

下面是一些梳理维度的思路:

(1)显而易见的维度

一些通用的维度还是比较容易梳理的,下图以电商产品为例简要列了一些,供大家参考:

我们在梳理维度时可以直接分级,也可以先不分级,做模型的时候在需要的场景下再分级。

(2)与业务紧密相关的核心维度

上文提到,每个平台都有特定的核心维度,梳理这些核心维度,考验了产品经理对业务的理解能力和抽象能力。

举个例子来说明一下什么是核心维度:

事实上核心维度并不是指的优先级最高的维度,而是按照优先级排列的一系列维度集合。

(3)业务发展过程中出现的动态维度

细心的读者可能发现,在前两个小节中,我漏掉了一个重要的维度——用户维度。事实上在任何一个产品分析中,用户维度都是极其重要的。在我的概念中,用户维度是一个在业务发展过程中的动态维度。

那么,何为动态维度?

动态维度在一开始并不是显现的,不像时间、空间、业务实体这种来自于组织架构或者业务形态等,直接可以在业务流程图中读出的维度。动态维度需要业务发展过程中归纳提炼而出,并且会随着业务的发展不断变化。

回到用户维度,在业务发展的初期、中期、后期用户的画像和模型一定是不同的。依然用张老板饭店的例子为大家说明:(我们需要假设张老板在创业初期就能够获取用户数据)

用户维度是最重要的动态维度之一,与此同时,根据不同的业务,还会有其他的动态维度。例如:商品可以按照价格区间、利润率设置维度;店铺可以按照动销比、好评度设置维度;我们需要结合自身的业务,挖掘这种新的维度。

3. 模型第三

当我们建立好指标库和维度库后,接下来就是设计数据平台了,但在此之前,我们先来了解“模型”这个概念。

模型,相信大家都不陌生,像AARRR模型,RFM模型都是我们耳熟能详的经典模型。但模型的概念,在很多人心中也许是不同的。

比如:我们和研发聊模型时,研发的心中是:业务模型、数据模型、物理模型。对于数据分析或者数据平台设计过程中的模型,我心中的概念是:经过实践、在一段时间内固化下来的数据分析的方法。

数据平台的页面和图表,其实就是数据模型的体现。所以设计数据平台,其实就是建立分析模型的过程。

那么如何来做呢,接着跟大家分享:

(1)从KPI和业务入手

前文中提到,需要建立内部数据平台时,企业已经发展到了一定阶段,所以不管有没有模型的概念,事实上,在管理层和业务人员的心里已经有了模型。从领导的角度,模型会体现在下发的KPI上,从业务的角度,会体现在各自的业务分工或流程上。

我们仍然以张老板的饭店举例,假设饭店处于第二阶段:张氏酒楼承接散客和酒席。

下图是为张老板设计的每日数据台账:

我们在给张老板的报表中,首先按照两个业务“散客”、“酒席”将三个关键指标营业额、顾客数、菜品量进行了拆分。

我们为什么这样拆,可能是张老板为这两个业务线定了不同的KPI,也可能是这两个业务分由两个人分管。但最重要的原因是:这两条业务线的运营流程是不同的。我们首先需要把这两项分开,才能进一步分析。

(2)模型的类型

上图只是一个示例,所谓数据平台,就是通过一张一张的图表,把业务的真实情况反映出来。展现给各个相关的岗位人员,帮助他们改进做法。

我归纳了几个模型类型,供大家参考:

  • 拆解模型:上面的例子就是一个拆解模型。当我们遇到相对独立的维度时,可以用拆解模型,例如:按业务拆、按地域拆、按用户拆。
  • 流程模型:当我们在分析一个流程性的业务时,适用于流程模型,比较经典的:AARRR模型,漏斗模型都是属于此类。
  • 对比模型:数据,对比才有意义。所以我们在分析数据时,最常用的就是对比模型。例如:环比,销售品类相同的不同商家之间的对比等。
  • 归纳模型:归纳模型要稍微难一些,有点类似于上文提到的动态维度,我们需要在摸索中总结,找到评价和总结某个事物的核心指标和维度。例如:RFM模型、用户画像、店铺画像等都属于归纳模型。

4. 三大法宝之外

除了上面说的三大法宝,构建数据平台还有一些其他要素:

(1)可视化

说白了就是什么情况下用什么图,怎么设计和组合图形,才能准确、形象的传达信息。事实上数据可视化是一门比较高深的艺术,我印象里国际上好像还有类似的比赛,这方面的资料、书籍也比较多,都比我专业许多,就不展开说了。

(2)权限

数据权限是比较重要的,做数据产品经理,应该在一开始就树立数据的保密意识。

这部分大致上分为功能权限和数据权限:

  • 所谓功能权限:就是按照菜单划分权限,有的人能看到这个菜单,有的人不能;
  • 所谓数据权限:就是虽然大家都能看到这个页面,但每个人看到的都是筛选过的数据,仅是自己能看到的范围。

我们在这方面做的比较简单,相信在大型公司,权限部分要复杂的多,还请大牛朋友指点。

(3)结构

这里说的结构,我想表达的是数据平台的各个菜单怎么来设置,都放哪些内容。数据平台说白了是个B端产品,B端产品在意的是效率,所以我们的页面结构,通常情况下是按主题来分的。

当然有条件的也可以让业务自定义看板。下图是截取的友盟、腾讯移动分析、GrowingIO、诸葛io的菜单截图,供大家参考,大家也可以自行登录相应的网站查看demo学习。

总结

怎么从0开始做数据平台:

  1. 找定位:看到底需不需要做,做到什么程度;
  2. 订指标:制定尽量详尽的指标库;
  3. 画维度:按照重要程度列出与业务相关的维度;
  4. 建模型:与数据用户一起,构建每个岗位的分析模型。

完成这四部之后,就可以做原型图,写需求了。当然过程中还要注意、权限的管理、可视化的运用、以及结构的编排。

那么有了以上这些就够了吗?

其实这只是一小部分,能够顺利搭建数据平台,还有三个关键点:

  • 一是企业的管理层是否支持,包括政策上的支持,资源上的支持。在资源紧张的情况下,领导是否愿意拿出一部分资源来做数据平台;
  • 二是研发资源是否匹配,大家都知道做大数据是有一定的技术门槛的,这块出了问题,很可能造成后期数据不准、查数据慢、迭代困难等;
  • 三是业务上要有使用数据的习惯,这个大家都懂得,要让你的用户和你的产品一起进步。

 

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

题图来自Unsplash,基于CC0协议

本站声明:网站内容来源于网络,如有侵权,请联系我们,我们将及时处理

「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论