业务型产品经理怎么做数据分析？

编辑导语:客观数据能够通过可量化指标来评估产品的改进方向,所以作为一名产品经理,必须养成数据思维习惯,熟练掌握数据分析方法论。数据分析的准确性与专业度,往往决定了一个产品发展。那么,业务型产品经理应该怎么做数据分析?

如果产品是个孩子,产品经理应当充当什么角色呢?有个比喻很恰当:产品经理是父亲,不负责具体生孩子,可一旦孩子闯祸了,优先找产品经理。

所以每一次新功能上线,产品经理都期望他能“争口气”,可以是更好的交互体验,也可以是相关指标有所提升。期望并不代表真实效果,产品上线后带来的真实效果需要通过数据进行客观描述。

一、为什么要做数据分析?

上线前:对产品经理而言,从众多需求中精心挑选出(拍脑袋)的需求时,在心中就会有初步的构想,新功能能够帮助产品覆盖哪些增量用户,新功能带来哪些关键指标的提升,提升幅度大约是多少?

上线后:用户使用后产生用户行为数据可以侧面验证这次的功能迭代优化,是否达到了预期的业务目标,具体的提升效果是什么样子?这本质上就是将业务问题转化为数据问题的过程。通过数据分析的结果,我们可以确定上线功能与预期效果之间的真实差异。

如果效果好于预期,则评估的结果可以作为运营同学大力推广的支撑点;当效果明显未达预期时,则需要基于用户行为进一步分析未达预期的原因,为功能的优化或改版提供新一轮的“脑暴”,因此数据分析是新功能上线后必做的一步。

往小了说,数据分析帮助产品经理不断优化产品设计和迭代,往大了说,数据分析用纯数据的方式非常有说服力,可以让决策者、大领导直观的感受到“数据分析、挖掘”的价值,验证自己的远见卓识,且能更好地为企业发展服务。

二、怎么做好数据分析?

上线新功能后如何做好数据分析,一要采集用户行为数据;二要分析用户行为数据;三要从数据分析中得出结论。

以下将一一进行展开:

1. 数据采集

用户行为数据对深入理解用户使用习惯起到至关重要的作用,目前用户行为数据的采集是通过数据埋点形式,通常有两种方式:

一种是由公司自主搭建数据分析体系:由研发人员在产品当中注入统计代码,而后上报进行分析;第二是快速接入市面上比较成熟的第三方统计平台(友盟、GrowingIO等)。

但对大公司而言,出于数据安全和个性化需求等因素考量,往往采纳前者,不过相比后者前者的人力成本和时间成本比较大。

1)项目成员对数据埋点有分歧的情况,如下:

产品同学:我要上报这个数据,对分析很重要!

开发同学:这个上报会影响页面性能,不能做!

所以,不是用户行为数据上报的越多越好,要兼顾性能。换个角度来想,大家目标一致,都是为了产品更好。

所以数据产品童鞋在提埋点需求的时候,可以多思考该数据是否是必须的,是否有其他的数据可以近似替代?在与开发同学对齐需求时,也可以多交流下,是否有对性能影响小一点的实现方式?

2)埋点上线后缺失数据字段的情况

产品同学:额,我要的付款时间字段怎么没有哇!

开发同学:额,你没有和我对这个字段!

产品同学关注的部分数据字段被开发同学忽略的情况的发生,通常理解下,业务数据更多的是前端和后台开发同学,为了保证功能完整运行所需要存储的数据。

若数据产品同学没有在需求阶段和开发同学对齐,可能就导致数据关注的部分字段被开发同学忽略的情况的发生。

3)埋点上线后发现数据没有上报的情况,如下:

后台同学:埋点需求已经发布上线了,可以用了。

产品同学:数据库没有数据哇。

是采集了没上报到服务器,还是服务器收到了没有推送到数据库?

所有流程验证一遍之后,可能发现只是其中某一个环节的问题导致,但整个排查耗费了大量的人力。

所以埋点需求在上线之前需要进行充分的测试验证,从数据上报,到服务器接收数据,到数据入库,这样全流程下来,能保证每个环节数据流的准确和完整性,可以节省了排查问题的大量时间。

4)埋点上线后发现数据上报有误差的情况,如下:

Android开发:我给页面1命名为双十一狂欢活动

IOS开发:我给页面1命名为双十一活动页

数据产品同学需要参与到业务数据沉淀需求讨论中,统一好字段属性。因为当启动评估后,发现数据维度不够,再推动研发落地对应字段后启动评估,整个评估的时间周期明显被拉长了。

这就是因为前期数据同学没有和开发充分沟通的结果。

2. 数据分析

量化即增长–当数据准备好了后,该如何进行数据分析呢?

产品功能的每次迭代优化,都期望能够对核心指标产生积极影响,这就要求数据和业务形成有机结合,相互促进的良好局面。好的数据量化不仅是业务增长的前提,也是抓手。

随着增长理论的深入,很多产品都设立了自己的北极星指标,作为衡量产品一个战略周期的关键成果指标。

但由于关键指标过于宏观,可能对于业务策略制定和执行的指导性不强。因此,我们需要拆解出可以影响关键指标的因素,并将这些因素对应到具体的、可落地、可度量的行为上,从而保证执行计划没有脱离大方向。

这里介绍一下我们最常使用产品数据分析框架–OSM模型 (Objective、Strategy、Measurement)三个词的缩写,其中:

Objective (业务目标):明确业务要提升的目标是什么?

Strategy (实现策略):为了提升目标所需要采取的策略是什么?

Measurement (评估指标) :尽可能使用数据语言描述策略是否达到了提升目标?

利用OSM模型梳理自己产品的数据框架,不同产品的数据体系差异也主要体现在这里。比如游戏行业,可能更多的关注用户留存率;而针对电商平台,可能更多的关注转化率。

拿电商平台的转化率来说,我们对购买下单的关键路径进行漏斗分析,比如从浏览商品到最后下单购买成功,这其中每一个步骤的转化率是多少,跳出率是多少,对于漏的比较多的那个步骤我们需要重点分析,因为这关系着平台的最终盈利。

因此我们最终会将转化率提升作为我们的核心指标,并将这一目标利用OSM模型进行拆解。然后确定了一个可以数字化的执行计划,每一个评估指标的波动,都可以评估其对核心指标的影响,继而我们也可以知道每次的功能代优后应该产生的效果。

举栗说明:商品总成交额=用户流量数*成交转化率*客单价,我们可以分别从这3个点来细化:

3. 分析结果

数据分析之后还有一个重要的工作,那就是推动分析结果的落地,没有落地的分析结果都是无用的分析。

上面也提到,如果评估出来功能效果满足预期,我们可以推动运营同学将新功能包装并对外推广。但是,如果当我们发现新上线的功能效果远远低于预期,这个时候难道仅仅是把这个效果同步出去就完事了吗?

当然不是,正确地打开方式是分析哪里出现问题以及为什么会出现这个问题。

这里我们尝试着从用户、产品、竞品三个当面将问题细化,然后用假设检验分析方法对细化地问题进行一一验证,可综合使用对比分析方法。先明确问题出现在哪里,以电商某商品下单转化率低为栗子,如图:

那针对以上的可能原因,我们逐步一一进行定位分析,最终得出的结论是:用户购买竞争对手的商品,一是因为竞品的价格优势,而是因为自身产品的售后出现问题。

我们定位了效果不好的原因,如果这时我们对如何优化有好的想法了,我们就可以直接找领导去聊聊策(ren)略(sheng)。

但如果对优化策略还没有好的方案,就可以组织一场脑暴,让大家好好沟通一下分析结果以及他们对于优化的思考。毕竟,人多力量大。等到大家敲定了优化方案,接下来就是方案的落地,以及下一轮效果评估啦～

当功能效果达预期时,数据分析是运营同学的后盾,保证运营推广不走偏。我们需要注意的一点是,每一次数据分析后,运营同学也会进行效果复盘。

这个时候我们也应该关注一下,运营推广的内容具体效果提升是什么样子的?活动期间的数据是否和活动前给出的数据存在明显差异?产生差异的原因等等。

三、写在最后

最后,有点小想法,如果每个产品经理都能用数据分析的方法或者思路对自己进行剖析或者总结,或许我们就会少一些迷茫,多一些自我驱动、独立思考和总结的能力。