产品思考:上线后的数据分析

1 评论 5524 浏览 26 收藏 9 分钟

编辑导语:数据分析对于产品工作是十分关键的,但是在日常工作过程中常常会出现各种各样的问题,本篇文章作者分享了产品上线后的常见的数据分析等内容,一起来学习一下吧。

数据分析是产品工作中重要的一环,但真实工作场景中,会受到诸多的限制,包括但不限于数据缺失、脏数据极多、数据工程与数据分析的资源缺失、项目时间等等。

很多项目,都是在没有完整数据分析支持的情况下落地的。

这篇文章想聊下常见的数据分析和几类项目的数据分析。

前者多是知识的堆砌,后者多是个人的经验。

一、常见的数据分析

统计课上将各类方法分为描述性统计与推论性统计,但在实际的业务情景中,需要的数据分析结论能明确的指导业务动作。需要了解,面对各类情景,需采用怎样的分析方法。

一个大佬的总结到,常见的、高频的数据分析方法或情景有三类:对比、下钻、分布。这三者能覆盖大多数产品的工作了。其余的数据分析模型,聚类、分类等在实际中应用的较少。

1. 对比

将两组样本进行对比。包括横向的对比,比如A样本组 vs B样本组,以及纵向的对比,比如A样本组在a时段的表现 vs b时段的表现。

假设检验中常用的方法为t检验、f检验,但据我观察除非样本量较小,或者相对值较小的情况,很少用到假设检验的方法去判断差异显著性,更多的是基于两者对比的差值来做判断。

2. 下钻

下钻指的是将1个一级指标拆解为n个二级指标,再拆解为m个三级指标。

包括行为的下钻(漏斗分析、路径分析等),也包括指标的下钻(DAU拆解等)。

下钻分析过程中,常用的分析原则为“MECE原则”,指的是拆解过程中每一级指标间不遗漏、不重叠。

3. 分布

分布指的是看一组样本的某个数据的表现,包括集中趋势(平均值)以及离散趋势(标准差)等。往往通过散点图或箱线图的形式呈现。

同时,基于分布,也可以看未来的数据表现趋势,比如通过不同时间点留存值的分布,看未来时间上留存的表现趋势。

二、几类项目的数据分析

“项目上线后的数据分析”,这个影响的因素太多了,公司、个人、项目等等。

不同方向的项目,能够调用的数据资源,分析的价值,难度都是不一样的。

但对于每一个产品,通过数据结果来证明项目价值与作用,在当今这么卷的背景下,是工作中重要的一环。

1. 低难度——策略试验

策略类产品往往上线前就有完整的数据假设,实验方案与资源,上线后的数据分析并不困难。

能拿到精确的结果。需要注意的是实验分组需规避其他实验组的影响,不过大多有实验平台,或者依靠哈希值分组,能够较好的处理这一点。

2. 中难度——活动向&C端功能向

大多有明确的数据指标导向,比如拉新、拉活、拉营收等等。

这些活动的数据分析,核心需要规避掉其他无关因素对结果的影响。

最常见的影响因素是时间,一个时间段内可能有多个活动进行,需要选取样本时进行一定的筛选,保证样本间的对比是无其余近期上线活动、功能的干扰。

另一个在对比时需要规避的是样本组内其余变量的干扰。

比如,参加活动的有可能天然是那些积极的用户,这些用户本身就比不参加活动的用户有更好的互动、营收,那么结果的信效度就会受到挑战。

常见的方式是通过用户分层,来细化分析,这一方式简单,但比较粗糙。

我更认可的是采用倾向性匹配得分(PSM),通过罗辑回归,选取1-2个对目标变量(活跃)影响最大的核心维度(如历史付费),通过控制样本间1-2个核心维度的指标相同(方差齐性),来保证样本间对比的有效性。

3. 高难度——体验优化&通用能力

这些需求项目在业务中也经常遇到,但立项之初核心解决的问题可能更偏向用户的具体诉求,而非某一个具体的指标。

体验优化的项目是其一。

举个不恰当的例子,原先app中所有的交互都是不一致的,高度不一样,弹窗并发等等,体验很差,设计和产品同学把所有的交互UI都统一了,逻辑也更合理,是一次体验优化。

但这种体验优化,短时间内其实很难表明其价值,或者很难用数据来衡量其价值。这就需要长期的观测,或者是依赖用户研究的支持,通过NPS等指标来辅助分析。

但如果在一个非常卷的公司里,可能产品还没拿到长期或其他的数据分析,就已经因为没有数据能证明项目价值被开除了。

基础能力建设的项目是其二。

一些业务的基础能力(非中台能力),比如美颜能力(不是很恰当的例子),这是一个非常核心但基础的功能,如果是从0建设起来,在用户层面一定是有价值的,但其核心影响的指标是?

后向的观测指标是?这些指标往往非常的多,但每一个可能相关性都不是那么高。那么,剩下的指标可能就是该功能的渗透率了。

对于这类项目,会遇到一个尴尬的点,核心观测指标是功能的渗透率,但功能渗透率并不说明价值,需要其他的后向指标来辅助。

功能向体验优化是提升产品的用户价值的,但这些短期内难以有明显的数据变化趋势,同时效果很难归因。这类项目往往也争取不到数据资源,需要依赖产品本身的数据能力。

还有一类是B端的项目,但我对B端不熟悉,就不再展开了。

上述在数据分析上的难度,往往是由于项目前期没有明确的量化假设所造成的。

需要提前想清楚项目贡献的数据的表现差异,尽可能的通过版本灰度期间的数据对比,通过前端的埋点数据,进行分析,拿到可信的结果。

 

本文由 @斯金纳的咕 原创发布于人人都是产品经理,未经许可,禁止转载。

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 跟日常工作很贴近,受教了

    来自广东 回复