惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

U
Unit 42
F
Fortinet All Blogs
Martin Fowler
Martin Fowler
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
IT之家
IT之家
Blog — PlanetScale
Blog — PlanetScale
罗磊的独立博客
V
V2EX
Vercel News
Vercel News
Apple Machine Learning Research
Apple Machine Learning Research
J
Java Code Geeks
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
T
Tailwind CSS Blog
I
InfoQ
Engineering at Meta
Engineering at Meta
WordPress大学
WordPress大学
S
SegmentFault 最新的问题
H
Help Net Security
腾讯CDC
D
Docker
P
Proofpoint News Feed
GbyAI
GbyAI
博客园 - 三生石上(FineUI控件)
aimingoo的专栏
aimingoo的专栏

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
别再同环比,这五步让数据分析更深入
接地气的陈老师 · 2024-09-24 · via 人人都是产品经理

在数据分析的迷宫中,我们常常追求的不仅是答案,更是答案背后深层次的逻辑与洞察。《别再同环比,这五步让数据分析更深入》这篇文章,就是那把解锁复杂数据难题的钥匙。作者陈老师,一位资深的数据专家,将带领我们穿越数据的表层,深入到分析的核心。从简单的数据提取到复杂的因果探究,每一步都是对分析能力的锤炼。

很多同学总觉数据分析做得不深入,到底该怎么做?今天结合一个具体的例子,分享下如何做一个深入的数据分析项目。

深入级别:0级

某天,你收到一个需求:“看下我司APP新增的A功能,过去5天内累计使用1+次的人有多少(去重)”。这问题太简单了,直接跑个数丢过去即可,“过去5天累计使用人数10000人”搞掂。

但是这种分析完全不深入,甚至压根不能叫“分析”,这就是提个数而已。确实,当需求是很具体的取数指标+统计时间的时候,这就是取个数,第0级深入就是如此。

深入级别:1级

某天,你又收到一个需求:“看下我司APP新增的A功能,过去5天有多少人在用”。

听起来和之前的问题差不多,但注意,“多少人”并不是一个明确的指标,只是个笼统的说法,细分起来,有:

1.5天内累计使用1+次的人(去重)

2.5天内累计有多少人次使用(不去重)

3.5天内,每天有多少人在使用

4.5天内,累计使用5、4、3、2、1天的人有多少

5.5天内,各使用频次人数(1、2、3……10、10+次)

……

好几个指标拼起来,才能把这个多少人说明白。有些同学会觉得,这么搞是不是太麻烦了。我就默认他是看不去重的人次呗。实际上,工作中相当多的重复取数,加班加点,被业务追着屁股催数,就是从“没确认清楚需求,自己默认一个业务不想要的指标”开始的。特别是你问业务:想看哪个口径。业务会说:都看。这时候最好自己先提前想多几个,避免重复返工。

这种主动思考,才是深入分析的起点。因为这几个指标对业务都有用:

1.   看去重的人数,可以评估总用户渗透了多少

2.   看每天人次,可以看出发展趋势

3.   看各类型累计使用天数,可以判断有多少重度用户

4.   看各类型累计使用天数,可以判断有多少重度用户

而且,我们发现,第0级的成果,成为第1级产出的一部分。后续也是一样,越深入,设计的指标、维度越多,问题会越复杂。

深入级别:2级

某天,你又收到一个需求:“看下我司APP新增的A功能,过去5天使用的人,付费行为是不是比其他人更好”。

注意,这里也没有明确的数据指标,因此得先拆解问题:

1、主语是:过去5天使用过A功能的用户。那得先知道有多少人在用?第1级深入的数据,这里都需要加上。

2、付费行为:付费行为是个笼统说法。是付费金额,还是频次?没说清就先都拎出来看。

3、比其他人更好:什么是其他人?是全体用户,还是未使用该功能用户。从问题场景上看,应该区分出过去5天内未使用过该功能,并且至少活跃1次的用户,这样才有可比性。

有了这三步拆解。可以把这句不清晰的需求,落地成一个取数需求:

1.   过去5天内使用过A功能用户基本情况(人数,使用天数分布,使用频次分布)

2.   过去5天内使用过A功能用户付费行为(多大比例,付费人群的5天内累计付费金额,5天内付费频次,人均付费金额,人均付费次数)

3.   过去5天内未未使用过A功能,且活跃的用户的活跃天数、付费比例,付费金额,付费频次,人均付费金额,人均付费次数)

这样,两个群体一对比,就能出结论了。然而这么做,很快会引发下一个问题:“为什么使用A的人群比其他群体高/低?”

深入级别:3级

某天,你又收到一个需求:“分析下为啥使用A功能的人付费更好?”注意,先问是不是,再问为什么,是回答问题的基本要求。因此在拆解问题的时候,得先把深入2级功课都做完。做实了“A的付费更好”以后再分析原因。

分析原因的时候,假设很重要。需求既然关注A功能,那A功能到底有没有用就是关键。在分析原因的时候,证伪比证真更容易,所以我们可以先剔除一些明显的错误答案,比如“A功能用户本身都是高付费群体”,这一下就能把“A功能对付费转化有用”直接干掉。

但这样,逻辑上还是站不住,因为:

1.   本身消费高,但是用了A功能以后消费更高了

2.   本身消费高,但是比不用A的人更高

3.   消费低的人,用了A也有提高

4.   消费低的人,不用A只会更低

……

即使看到数据:A群体消费天然比不用的高,还是有至少这4种可能性要排除。所以得列清楚假设逻辑树,逐一排查可能性。这也是我们说的:验证观点,需要同时找正反两面的例子。

注意,即使这样,还是有反驳观点。因为我们都是基于过去数据分析,很有可能一个反驳观点是:“A功能只能吸引到这一小簇用户,不能做大”或者“A用户只是尝新,过了这段时间就没有效果了”这两个观点,都涉及未来数据情况,因此需要观察一段时间才能有结论。

如果我们等不了那么久,还可以做测试,比如测试:“做不大”这个点,可以主动向其他群体推广A功能,观察A功能增量以及留存效果,如果增量少,或者有增量但是留存差,那就可以推论:确实做不大。想要做深入分析,测试与长期观察是不可少的,好结论需要时间沉淀。

深入级别:4级

某天,你又收到一个需求:“分析下A功能对用户有啥影响?”看起来问题表达更简单了,可要解这个问题却更复杂了。因为从0级到3级,我们只讨论了“付费”这一个影响,实际上还有可能有更多影响,比如活跃、留存、转介绍等等。每个方向都得经历这么漫长的拆分、分析,才能得出综合结果。

到这里,我们的分析已经非常有深度了。有趣的是,我们的问题,反而非常简单。实际上,如果一个问题:

1.   有清晰的衡量指标

2.   有明确的判断指标好坏的标准

3.   有明显的指标间影响逻辑

4.   基于封闭的业务场景,容易测试

那这个问题就是很容易解决的。

可现实中的问题,常常是:

1.     口语化表达的

2.     包含了多个方面的

3.     没有清晰判断标准的

4.     杂糅了很多影响因素

5.     没有时间、场地给我们慢悠悠测试

这时候就能从头开始,一点点梳理。把本篇文章的顺序倒出来,就是从0开始梳理业务问题的场景。

当然,并不是所有的分析都需要这样从头到尾过一遍。

有可能提问人自己完全没概念,此时可以先给到1级深度数据,让他建立认知,再给2级深度的数据,引导他关注差异。

有可能提问人嘴上说得含糊,但心里有明确的目标,这时候可以进行深入沟通,清晰需求。

有可能提问的人不需要严密的论证,有部分证据即打算直接下结论,这时论证其最疑惑的点即可

这时候唯一不要干的,就是不沟通,自己拍脑袋随便仍几个数,或者到网上找所谓“模型”生搬硬套。这样闭门造车,返工、加班、被diss都是经常的事。

如果在某个业务场景下,我们已经做了很多次验证,论证了业务问题的关键指标+判断标准+因果关系,这时候就可以直接套用,这就是我们说的:业务分析模型。不过在沉淀出来之前,还是得多做论证的,特别是因果关系论证,做的不够细致,分分钟被打脸。

有同学还会问:老师,我的领导经常不提问题,让我自己从数据里发现点啥,该咋办?这是数据分析中典型的:无提问场景。我们以后分享。

本文由人人都是产品经理作者【接地气的陈老师】,微信公众号:【接地气的陈老师】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

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