数据产品经理必备技能之分析方法

很多人觉得,做数据产品经理就没有必要掌握数据分析相关技能了,终于可以远离了枯燥的数据分析工作。如果真这么觉得,那么就大错特错了,一个好的数据产品经理,不仅要有产品sense,还要有好的分析思路,因为一个数据产品需求大部分都是由分析需求固化而来的。很多时候,数据产品和分析是分不开的,一个好的数据产品经理,要掌握常用的数据分析框架和方法,才能使做出来的数据产品让数据分析师和业务人员使用更顺手,更贴近业务。

在进行数据分析之前,一般都会先想一下分析框架和分析方法,数据分析方法一般有常规分析、统计模型分析以及自建模型分析。掌握这三种分析思路,就能解决大部分分析需求,并根据分析需求固化为数据产品。下面重点讲一下这三个分析方法。

1、常规分析

其实很多公司80%的分析需求都是可以通过常规分析解决,很多分析师一般把业务相关数据从hive或者mysql中导入到excel,然后在excel中通过简单的表格、线图等方式来简单直观的分析数据。常规分析经常会用到同环比分析法和ABC分析法,即分析对比趋势和分析占比情况。

同环比分析应用到数据产品中常见的有业务周、月、日报等,例如,拿很多互联网公司都关注的核心指标DAU(日活跃用户数),周报里一般都会对比DAU的周环比变化,如果上涨或者下跌的比较大的话,就要进一步查找分析业务原因。

同比:某个周期的时段与上一个周期的相同时段比较,如今年的6月比去年的月,本周的周一比上周的周一等等。同比增长率=(本期数-同期数)/同期数×100%。

环比:某个时段与其上一个时长相等的时段做比较,比如本周环比上周等等。环比增长率=(本期数-上期数)/上期数×100%。

至于ABC分析法,一般是以某一指标为对象,进行数量分析,以该指标各维度数据与总体数据的比重为依据,按照比例大小顺序排列,并按照一定的比重或累计比重标准,将各组成部分分为ABC三类。举一个通俗易懂的例子,经过长期的观察发现:美国80%的人只掌握了20%的财产,而另外20%的人却掌握了全国80%的财产,而且很多事情都符合该规律。于是可以应用此规律在业务上,通过合理分配时间和力量到A类-总数中的少数部分,将会得到更好的结果。当然忽视B类和C类也是危险的,但是它确实得到与A类相对少得多的注意。

举一个比较简单的例子,在分析支付订单量的数据中,对各个城市的支付订单量做ABC分析法进一步分析,如图1所示,发现武汉、杭州、上海等地的支付订单量占比很大,这样就可以在运营活动中进一步关注占比比较高的城市,重点支持下这部分城市的活动推广。

图1 各城市支付订单量占比情况

2、统计模型分析

当掌握了很大的数据量,希望在数据中挖掘出更多信息的时候,一般都可以应用成熟的模型进行比较深入的分析,例如,经常会面对如下的业务场景:

  1. 预测产品在未来一年内的日活用户数会按什么趋势发展,预估DAU;
  2. 上线了某个营销活动,预估活动效果怎么样,用户参与度情况;
  3. 对现有用户进行细分,到底哪一类用户才是目标用户群;
  4. 一些用户购买了很多商品后,哪些商品同时被购买的几率高。

针对于第一个案例,要用到回归分析,可以理解成几个自变量通过加减乘除或者比较复杂的运算得出因变量,例如预估DAU,因变量是DAU,和他有关的自变量有新增用户、老用户、老用户留存、回流用户等,然后根据历史数据,通过回归分析拟合成一个函数,这样就可以根据未来可能的自变量,进一步得出因变量。现在常用的回归分析主要有线性和非线性回归、时间序列等。

举个简单的例子,通过之前的业务支付订单量要预测未来的订单量情况作参考,在排除其他因素干扰的情况下,可以通过简单的线性回归根据支付订单量的历史值,进一步拟合出未来90的支付订单量曲线情况,如下图2所示。

图2  线性回归预测支付订单量

针对第二个案列,根据以往活动的数据,分析活动的各个影响因素在满足什么情况时才会产生我们想要的效果,并可以根据有活动时和没有上线活动时的各项数据输入到系统中,这个函数就会根据判断活动效果会与哪些因素有关,目前常用的分类分析方法有:决策树、贝叶斯、KNN、神经网络等。

关于第三个案例,可以用聚类分析,细分市场、细分用户群里都属于聚类问题,这样更方便了解用户的具体特征,从而针对性的做一些营销等,常见的聚类分析一般有K均值聚类、分布估计聚类等。

关于聚类分析,最常用的就是对用户进行分类,首先,要选取聚类变量,要尽量使用对产品使用行为有影响的变量,但是还是要注意这些变量要在不同研究对象上有明显差异,这些变量之间又不存在高度相关,例如,年龄、性别、学历等。然后,把变量对应的数据输入到模型中,选择一个合适的分类数目,一般会选拐点附近的几个类别作为分类数目,如下图3。接下来,要观察各类别用户在各变量上的表现,找出不同类别用户区别去其他用户的重要特征,选取最明显的几个特征,最后进行聚类处理。

图3 R2曲线

关于第四个案例,要用到关联分析,在电商中的应用场景比较大,最经典的案例当属啤酒与尿不湿的搭配销售,常用的关联分析有购物篮分析、属性关联分析等。

做关联分析一般要理解频繁项集和关联规则两个概念,频繁项集是经常出现在一块儿的物品的集合,关联规则暗示两种物品之间可能存在很强的关系。

下面用一个例子来说明这两种概念:例如图4,给出了某个杂货店的交易清单。

图4 订单交易情况

频繁项集是指那些经常出现在一起的商品集合,图中的集合{葡萄酒,尿布,豆奶}就是频繁项集的一个例子。从这个数据集中也可以找到诸如尿布->葡萄酒的关联规则,即如果有人买了尿布,那么他很可能也会买葡萄酒。

另外,为了评估关联分析的效果和可信性,定义了可信度或置信度这两个概念。规则{尿布}➞{啤酒}的可信度被定义为”支持度({尿布,啤酒})/支持度({尿布})”,由于{尿布,啤酒}的支持度为3/5,尿布的支持度为4/5,所以”尿布➞啤酒”的可信度为3/4。这意味着对于包含”尿布”的所有记录,我们的规则对其中75%的记录都适用。

3、自建模型分析

当以上两种分析方法都不能满足业务的分析需求时,这时候就需要自建模型进行分析,例如每个公司的业务模式都不太一样,当要分析用户在生命周期产生的价值(LTV)时,就需要根据自己的业务模式进行自建模型分析,对于一般依靠广告营收的公司,LTV会与用户活跃天数和Arpu(每用户平均收入)值有关,而Arpu值方面,每个公司都有自己的广告营收模式,所以Arpu值细分下去都是不太一样的。自建模型是为了满足业务需求,将各个指标灵活自由组合,从而保证分析的有效性和针对性。

具体来看,定义LTV=平均活跃天数*Arpu值=平均活跃天数*(指标1* 参数1 + 指标2* 参数2 + 指标3 * 参数3+……),其实,处了平均活跃天数需要预测外,后面的几个指标的值都比较明确,直接输入固定值就可以。

平均活跃天数预测方式:

图5 留存率曲线

图6 DAU曲线

如上图5和6的所示根据实际留存率和实际ArpuDau进行截断天数内平均活跃天数预测:

(1)INPUT /每日实际留存数,OUTPUT/beta(α,β)曲线,预测哪一天就根据beta曲线返回对应值【预测非线性拟合,起始点和终点权重较大】

对beta曲线目前分为三个partition:

  • 乐观预估:因ArpuDau持续上涨导致波动过大,输出值过大。
  • 稳健预估:为保证输出值稳定平滑,进行log导数限制。
  • 当前平均预估:在稳健预估无法输出有效值时采用此预估方法,根据当前留存和Arpu值作为重点,对未来进行预估。

(2)ArpuDau根据实际情况按公式进行每日计算,一段时间后Arpu值趋于稳定。

(3)LTV公式= ∑(留存beta1*Arpu1+留存beta2*Arpu2+….+留存betak*Arpuk),可简单理解为∑留存beta*∑ArpuDau

k值由模型调用者决定,660天LTV预估同样可由模型调用者进行修改调整。

其实,以上的分析方法和思路,数据产品经理只需要掌握基本的20%就能解决80%的问题,剩下的20%的问题,可以交给更专业的数据分析师们去解决,当然,多学一些分析方法,对以后的数据工作还是很有帮助的。毕竟,数据产品和数据分析是分不开的,都是基于数据需求解决一定问题出发的,选择什么方法去解决问题,还是需要具体深入到业务中去。

现在已经进入了大数据时代,每个公司对数据的重视程度都提高到了前所未有的程度,只要是进入到一定规模的公司,不论是考虑到数据的安全性,还是数据的使用效率,都会搭建自己的BI平台来管理查看数据,因此,掌握搭建BI平台的各种知识,也是数据产品经理必备的一项技能。

下面,按照BI平台的版本迭代路线,讲一下BI建设的四个阶段:实现可拓展的展示报表(1.0版本)、自助分析功能(2.0版本)、添加功能性分析工具(3.0版本)、实现业务场景模板(4.0版本) 。

1.实现可拓展的展示报表

BI平台首先要完成的就是对指标的报表性展示,大家首先想到的解决方案无非是前端写页面,后端接口在数据库查询相应字段,直接吐出数据。可是,这种传统的方式太依赖于前端,如果增加一个指标,前后端修改的成本都比较高。因此,为了以后BI平台的可扩展性,可以通过前端配置json,并在API下一层添加了QueryAdapter来把Api的接口翻译成相应的Sql,然后通过Sql查询数据库的形式,来提高前端的扩展性和报表的灵活性,具体架构如下图所示:

图1 可扩展的报表架构

这里要讲两个概念,单图(chart)与看板(dashboard),单图主要是对指标进行某种样式的展示,例如日活的折线图、日活的表格、多平台日活对比图等,并可以对单图进行多个维度的查询操作,它提供了:

  • 维度:可以选择多个维度,向下进行钻取;
  • 时间:可以选择昨天、过去7天、过去30天、过去90、过去180天、过去365天以及自定义天数;
  • 图表样式:目前支持折线图、横向柱图、竖向柱图、表格、地图、饼图等图表。

看板(dashboard)能够帮助将相互关联的单图集合在一起,兼顾全面性与单独性,既能够从多个图表中发现关联,也可以对单个图表进行深入分析,方便每天查看相应的数据。 看板可以供不同的业务人员实现不同的使用场景:

  • 产品经理的看板可能是项目的核心指标;
  • 市场人员的看板可能是监控各个渠道来源指标;
  • 销售的看板可能是潜在客户的活跃度…

对于支持自定义图表的单图(chart)而言,在前端配置的json格式中,需要明确以下几个字段:

  • dataSource:数据源,也就是单图(chart)要查询的数据库、数据表,它包含了数据的地址、端口、数据库格式、数据库、数据表等,是数据展现的基础。
  • metrics:这是是要展示的指标,包括指标的计算类型、指标的id、指标名称、指标别名等,
  • dimensions:指标的维度,也就是相当于Sql中的group,也就是分析人员想按照什么样的分组来查看数据。
  • filter:这部分是用来设置过滤器,前端报表用来筛选查询条件的,它要规定每个维度应该以何种规则来过滤,是等于、不等于、大于、小于还是包含,还要规定维度的查询字段和查询值,简单表示下就是下面这种格式,当然还有很多字段可以添加以便进一步扩展功能,具体filter的格式可以参考下图。

图2 filer格式

  • orders:输出结果应该以哪一个指标进行排序。通常使用时间字段来进行排序设置。

除了以上几个重要字段外,还可以设置time、limit等字段来扩展更多功能,这里就不一一详述了。

看板(dashboard)的实现逻辑也与上面相似,不同的是还添加了看板中包含哪些单图(即包含的每个chart的id),以及这些单图在看板中的位置等信息。

有了上面的支持可拓展的json配置格式,就可以在BI平台配置出符合自己需求的单图(chart)与看板(dashboard)了。至此,已经能满足日常的报表展示需求,BI平台也完成了V1版本的迭代。

2.自助分析功能

以上只是满足固定数据的展示,可是,数据产品经理经常面对的情况是,业务人员的需求是多种多样的,如果这些需求都让负责BI平台的产品经理来配置的话,既增加工作量,又有很大的沟通成本,这时候,业务人员就需要一个能够自己在平台上快速方便搭建报表的方式。

自助分析功能这部分主要包含创建单图(chart)和创建看板(dashboard)两部分,这两部分都是基于前期灵活可扩展的json图表配置,并在此基础上,能够创建一些复杂的计算字段,例如,想计算平均停留时长这个指标,它是由总停留时长除以dau计算而成的,总停留时长和dau都是基础指标,在数据表中是已经存在的,那么就可以定一个计算字段,命名为平均停留时长,计算公式为sum(dwell/dau),如下图3所示:

图3 创建计算字段

自助分析功能的核心是创建单图功能,使用人员可以选择图表样式,现在常用的图表类型有表格、折线图、柱状图(横向柱图、竖向柱图)、饼图、漏斗图、堆积图等,然后选择数据源里的数据表,把对应的数据表中的字段拖拽到时间、维度、指标栏中,然后选择查询便可以在显示区进行预览,还可以设置过滤条件,进行一些维度的过滤,并可以设置是否在前后端显示,具体功能见图4。

图4 创建单图(chart)页面

在基本功能的基础上,还有一些细节功能需要去优化,例如,有时候折线图从0为Y轴为起点很难看出波动,这样就可以设置指标显示的范围,让它在一定范围内显示,从而进一步缩小显示区间,突出趋势变化,另外,还可以支持一些实时数据的展示功能等。

完成创建单图功能后,就可以基于已经创建的单图上,选择已经创建的单图,动态拖拽到看板(dashboard)的合适位置,从而组成满足自己分析需求相关的看板,形成日常性报表组合。

最后不得不提一下数据源管理功能,因为所有的单图(chart)和看板(dashboard)都是基于数据源进行分析的,好的数据源管理可以提高数据源的利用率、降低重复创建数据源,进一步提高效率,并且还可以进一步拓展数据的存储形式,除了支持Mysql存储,还可以支持Druid、Phoenix等。另外,数据源管理要考虑业务的复杂性,能够满足复杂的多表join,支持自定义SQL查询。最后,数据源管理也要注意对数据权限的控制,最好能够做到对表中字段这种细粒度的权限管理,进一步提高数据的安全性。

3.功能性分析工具

一个完善的BI平台,不仅仅是单纯展示数据的,还要能够能为数据分析师、业务人员提供一些常用的数据分析工具,例如用户行为路径、用户分群与用户详情、系统监控等工具,可以方便使用人员方便快捷的分析更精细的业务场景。

以用户分群和用户细查为例,日常中经常需要把满足某个或者某些条件的用户区分出来,然后查看这批用户的一些关键指标以及一些行为事件等,例如,想了解iOS平台上,最近五天内连续沉默的用户,使用人员选择这些条件组合后,就可以获取一批userid的列表,让后查看每个userid的用户属性、用户行为轨迹、用户活跃度趋势、用户阅读文章列表等信息,由于不方便透露一些用户信息,用户细查页面就以原型图的形式给予示例,见图5。当然获取某些条件下的userid对集群来说是有一定的计算压力的,要等一些时间计算完成后才能给用户显示。

图5 用户细查原型页面

4.业务场景模板

BI数据系统是要更方便的服务于不同的业务场景进行数据分析的,每个业务场景总会沉淀下来一套固定的分析思路和分析架构,这套固定的分析架构就可以放在BI平台上来实现,例如渠道分析、用户留存分析、用户活跃分析及日常的周月报等。通过分析模板,可以方便快速的查看数分析数据,提高效率。

例如活跃用户分析来说,根据平时的分析习惯,一般要将活跃用户拆解为不同的活跃用户群体,进一步查看活跃用户的构成及这部分用户的变化情况,从而针对每部分的不同群体进行优化和分析。例如可以按照下图的分析框架创建一个看板(dashboard),由一下七个单图(chart)组成一个日常的分析模板。

图6 活跃用户构成分析模板

梳理好分析框架后,就可以在BI平台上建立起固定的模板,很大的方便的满足了日常的业务场景分析。

搭建一个完善的BI平台,是需要不断打磨优化产品的,搭建平台的目的无非就是提高工作效率,方便大家快捷高效的获取数据,以上只是我在搭建BI平台的一些经验心得,分享出来与大家一起交流。

作为一名数据产品经理,还需要多了解业务,多使用自己的产品,如果BI平台自己使用都不方便,那么更何况数据分析师,乃至数据经验比较少的业务相关人员呢?另外,对于BI平台,以上四个阶段并不是适用于所有公司。不同的业务阶段的需求都是不一样的,初创公司没有太多的人力和时间来搭建自己的平台,可以引用市面上的第三方产品,例如友盟、BDP等,做的都已经相当成熟,还是要针对每个公司的具体阶段而定。

 

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/859.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息