需求上线不会分析数据,大厂老兵教会你

0 评论 5747 浏览 23 收藏 11 分钟

编辑导语:作为产品经理,数据分析便是日常工作,对于刚上任的新手小白无从下手,很是头疼。那么本文主要“围绕需求上线做数据分析”这一方面来进行解答,非常适合新手阅读学习。

产品经理的日常工作里,常常要做数据分析,很多同学对此很头疼。其实产品经理常做的数据分析工作,大体可以分为2种:

  1. 围绕需求上线做数据分析
  2. 日常or周期性的数据监控、盘点

今天我们重点来讲一下第1种,讲一讲需求上线后,数据分析应该怎么做?

一、分析结果

先说分析结果,一份及格的分析结果应该包含以下3点:

  1. 给这次的改动下结论。比如,是正向or负向?是否达到预期?
  2. 总结改动的主要影响。影响了哪些指标,具体涨跌比例是多少?
  3. 后续的to do。根据此次的情况做后续规划,是否需要继续迭代,如果需要,应该往什么方向做?具体做些什么?

二、分析思路

再说分析思路,可以从以下2个切入点入手,检查各数据指标的表现,遇到异常要重点研究、分析原因,2个切入点都要检查,才算完整完全。

1. 切入点1

需求上线先做合理预估,预估哪些数据指标会直接受需求上线的影响,用上线后的真实数据,跟预估做对比和印证。其中与预估不符的,需要重点分析、研究。

这要求你在需求上线前,就有能力预估出哪些指标会受影响,这就需要你日常有积累,足够了解你的用户,根据之前的实验结果,总结出规律和经验,才能提高预判的准确度。如果你刚接手某块业务,在这方面暂时没有积累,可以思考一下,当初做这个需求是为了解决什么问题?这个问题会影响哪些指标?理一下这些问题的答案,也能帮助你做合理预估。

注:想提高这方面能力,建议看看《俞军产品方法论》这本书,此处原引书中一段内容:

“如果你把方法论总结出来,在一定程度上证明了你的能力,那就提高了你做成另一个产品的’确定性’,企业也愿意为高一点的确定性买单。要形成方法论,很重要的一点是,要多做不同的业务,通过在新旧业务中比较异同,发现旧经验的适用和不适用,思考其中的通用性高低。”

2. 切入点2

拉出所有的大盘基础指标,观察需求上线对这些指标的影响,是否有预期外的变化。如果有某个指标,原本预估需求上线对其无影响,实际在上线后指标有变化,这样的指标也需要重点分析、研究。

什么样的指标可以划进大盘基础指标?虽然每个需求的侧重点和关注指标不同,但对业务来讲,核心指标一般是稳定不变的。只有能衡量业务结果的指标+与结果指标强相关的过程指标,才能算作大盘基础指标。比如,对电商业务,GMV、订单量、转化率就是大盘基础指标;对视频平台,DAU、浏览时长就是大盘基础指标。

为什么要看所有的大盘基础指标?因为不管本次需求的目的是什么,都是要为业务的大目标增长服务的。而真正公平公正衡量一个需求、一个项目、一个产品经理的价值,最根本的方法还是看对业务价值的提升,即大盘指标的提升做了多少贡献

3. 局部指标+大盘指标均非负向

如果你比较幸运,需求直接影响的局部指标,和大盘基础指标表现均非负向,看大盘指标可以帮助你真正衡量清楚需求的贡献和价值。

一个需求对局部指标影响再大,放到大盘里没有水花,从业务价值角度来讲,也不能算十分成功,当然,这类需求可能才是工作中占比较高的。

这时可以参照以下模板整理数据分析结果:

  1. 结论:迭代正向,符合预期。
  2. 整体大盘有收益时,如果对业务大盘是正向的,就把业务整体的收益展示出来。
  3. 局部情况描述,指标A上涨x%,指标B下跌x%,描述一下重点受影响的指标变化情况。
  4. 整体大盘无收益时,如果只对局部正向,对业务整体无影响,补充一下对大盘整体无影响。

4. 大盘有指标表现负向

如果需求对大盘指标有负向影响,那么要根据不同情况来拆分

第1,需要分析清楚原因,具体分析方式后文会讲。

这里需要指出一点,正常情况下,PM不应该在设计方案阶段,就定一个明确对局部有益,但对业务整体有损的方案。

重申一下,衡量一个产品经理的价值,最根本的方法还是看他对业务价值的提升做了多少贡献。

第2,如果整体和局部指标表现不一致,要考虑清楚后续动作是什么?

一般只要业务整体负向,我们都建议缩小需求影响。

如果是ABtest实验,建议调小实验比例,或者直接关闭实验。如果需求是直接全量上线的,一般直接回滚,使业务恢复到需求上线前的状态。

(1)局部指标非负向,大盘指标负向

分析过程是,首先产品要先简单尝试理解、解释数据预期外变化的原因

如果可以理解,且通过其他方式交叉验证了理解和归因是正确的,则可以视为预期有误,实际表现正常。

先缩小需求影响(具体参见上文),之后再根据本次数据分析得到的经验调整方案,重新上线新迭代,直至达到预期目标。

如果产品尝试后仍不能理解表现异常,认为指标变化不合理,可以把异常同步数据同学,并一起复核数据,验一下埋点上报、取数等环节,保证数据准确性,而非数据统计问题导致与预期不符。

之后,在数据侧还应该尝试总结异常指标的变化规律,比如,异常指标的变化幅度是否与某几个指标高度一致或完全相反。

我们可以通过总结变化规律,研究规律,查找影响指标的根本原因。而找到导致大盘异常的根本原因,又可以帮助PM正确理解上线的迭代动作有哪些深层次的意义。

很多时候,一方面获得收益和另一方面有所损失,是一件事情的一体两面,是需要平衡的两头。收益往往容易被看到(也许不好量化),但损失却更容易被忽视,有些需要经年累月的积累,才能真正了解损失的实际影响

我们每一次的数据分析,都要尽量挖掘出迭代带来的收益和损失,这样才能正确的评估这次改动带来的影响,以及是不是应该做这样的改动。

以下是该情况下,最基础的数据分析结果模板

  1. 结论:迭代对指标A、B有正向影响,但对大盘负向,计划先关闭实验or需求回滚,再做优化
  2. 局部情况描述:指标A上涨x%,指标B下跌x%,列出受影响较大的指标
  3. 大盘情况描述:指标C下跌x%、指标D下跌x%,列出受影响较大的大盘指标
  4. 后续to do:说明你计划后续如何调整方案,或者尝试往哪个方向做优化

(2)局部指标+大盘指标均负向

老老实实找负向的原因,想后面要怎么做优化吧,最好再考虑一下,为什么当初会定这样的方案。

让低质量的方案上线,这对各方面的资源都是一种浪费,长期这样下去,PM会逐渐失去合作方的信任,推任何项目都容易受到挑战,没有人愿意再跟你合作项目。

仍附上该情况下,最基础的数据分析结果模板:

  1. 结论:迭代负向,计划先关闭实验or需求回滚,再做优化
  2. 局部情况描述:指标A上涨x%,指标B下跌x%,列出受影响较大的指标
  3. 大盘情况描述:指标C下跌x%、指标D下跌x%,列出受影响较大的大盘指标
  4. 后续to do:说明你计划后续如何调整方案,或者尝试往哪个方向做优化

(3)一种极特殊情况

补充一种极特殊情况——符合预期的负向。

有时候我们不得不做一些必然降业务核心指标的需求,比如为了遵守政策要求所做的合规需求。这类需求在上线前,往往已经经过业务大佬们的充分讨论,产品层面的方案一般没有调整空间。

PM只需要按照既定方案上线,上线后重点统计清楚业务各方面损失多少,如果你发现可以通过后续迭代挽回损失,可以作为后续to do加在分析结论里。

 

作者:胡胖,公众号:胡胖快跑(ID:hupangrun)

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

题图来自 Pexels,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!