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

推荐订阅源

H
Help Net Security
G
Google Developers Blog
aimingoo的专栏
aimingoo的专栏
博客园 - 聂微东
酷 壳 – CoolShell
酷 壳 – CoolShell
小众软件
小众软件
Stack Overflow Blog
Stack Overflow Blog
美团技术团队
博客园_首页
T
Tailwind CSS Blog
博客园 - 三生石上(FineUI控件)
B
Blog
D
DataBreaches.Net
腾讯CDC
C
Check Point Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
U
Unit 42
月光博客
月光博客
V
V2EX
Vercel News
Vercel News
T
The Blog of Author Tim Ferriss
The Cloudflare Blog
博客园 - 叶小钗
Y
Y Combinator Blog

人人都是产品经理

为什么你的产品找不到差异化?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-10-20 · via 人人都是产品经理

在数字化时代,数据已成为企业运营的核心驱动力。然而,如何将数据转化为实际的运营成效,是许多企业面临的挑战。本文深入探讨了数据分析在运营中的关键作用,以及如何通过数据赋能来提升运营效率和效果。

做数据分析的同学最常服务运营,也最怕运营纠结。因为本身运营的工作和数据分析有高度关联,以至于大家在网上看到的数据分析文章,十篇里有六篇是运营写的。

运营对数据分析涉入的如此之深,以至于经常在分析思路、分析方法、分析结论上和数据分析师们怼起来。

今天我们就先看其中最大的一个问题。运营的工种有很多(如下图),其中活动运营是策略性最强,和数据分析关系最紧密,也是怼得最多的岗位,今天就用它举例子。

请听题:某游戏APP,用户活跃率在5月出现轻微下降情况,活动运营小组决定做一个签到打卡的活动,提高用户活跃度(具体提高多少没说),现活动前后数据如下图所示。

活动运营小组坚持称:如果不是做活动,5月份自然增长是下跌的。

老板认为这是扯淡。

活动运营小组称:数据分析师应利用人工智能大数据,精准分析出自然增长率。

问:你是数据分析师,你该怎么办?

01 科学旗号下的荒唐事

首先问,这个题的题眼在哪里?

A、用户活跃率减少

B、自然增长率

C、人工智能大数据

思考一秒钟

我们先反问一个问题:某天,一个人拿着弓来问你:“请用人工智能大数据精确分析一下,我比自然命中率高了多少”你会怎么办?你会抄起键盘开始叭叭写代码吗?——不会!你会先问他:“你射的是啥?”

如果他说:我也不知道射的啥,你帮我分析分析?你会咋办?你会用人工智能大数据分析他要射什么东西吗?——当然不会!有礼貌的话,你会让他先把自己射的箭找到;没礼貌的话,你可以直接口吐芬芳了。因为即使是幼儿园的小朋友都知道:射箭要先树个靶子。

这是常识。

所以整体的题眼是:具体提高多少没说。甚至题目本身都是有问题的。请注意问题的来源是活跃用户数量减少。结果运营在设目标的时候变成了用户活跃度。一字之差,含义就从清晰变模糊。

  • 到底什么算“度”
  • 含义是用户活跃人数,为啥不直接用?
  • 含义是用户活跃率?大家的公式是否一样?
  • 含义是综合计算的,计算公式和权重又是啥?

指标本身不清晰,又没有明确指出要提升多少,对活动后分析是一场灾难。简直就是射箭故事的翻版。问题是:为啥会出这么奇葩的事。

02 荒唐背后的苦衷

真正在企业上过班就知道:并非所有决策都是高度理性的,比如:

  • 这是常规活动,运营只是拿着模板改了改就推上线了
  • 这是老板亲自指示干的,咱也看不懂,咱也不敢问
  • 这是一种商业直觉:我感觉有问题了!等到真观察到再改已经来不及了
  • 这是一种迷信:你们不是有人工智能大数据吗,应该duang!一下就有了吧

总之,真实企业里,大概:

  • 30%的活动方案没有写清楚,只有个含糊的:“提高消费/提高活跃”
  • 30%的活动方案用词不严谨,活跃度、活跃值、活跃力一类的玄幻概念满天飞
  • 30%的活动方案没有做过测算,都是拍脑袋决策,甚至提1亿的目标,只为口号顺口
  • 只有大概10%方案能认真写清楚:提高用户活跃人数,5月dau维持在XX水平以上

当然,在管理规范的大企业里,这种乱象少很多。但是同类问题在大部分企业都存在,事先不写清楚目标,事后指望大数据来分析。甚至企图通过人造一个很低的、负增长的自然增长率,来蒙混过关。真要是碰上这种事,咋办呢?

首先,坚决不扯什么“自然增长率”。特别是在这种短期活动很密集的业务里。如果一定要扯,采用买定离手的机制:大家事先谈好自然增长率是多少,事后就看这个数,不要再调整。这就跟下棋的时候拒绝悔棋是一个道理。

  1. 做什么目标,事先说清楚,从X%提升到y%;
  2. 找清晰、直观的目标,避免玄幻/复杂概念;
  3. 找与核心KPI相关的目标,避免杂项干扰。

这是彻底解决问题的三大原则。

当然,这么做会遇到两个挑战:

挑战1:有些运营就是不知道咋定目标,帮帮忙?

挑战2:有些活动就是事先没定目标,咋补救?

03 设定目标的基本方法

设定目标有三种基本方法:

  1. KPI分解法
  2. KPI倒推法
  3. KPI场景法

分别对应三个场景:

  1. 活动目标是KPI指标
  2. 活动目标是KPI过程指标
  3. 活动目标是KPI关联指标

有同学会问:为啥都和KPI挂钩?

答:如果做的事跟KPI没啥关系,那你也知道这个事的重要紧急程度了。

大张旗鼓做和KPI无关的事,本身就有可能是影响KPI的原因哈。

KPI分解法举例:

 

KPI倒推法举例: 

 

KPI场景法举例: 

平时和运营保持良好的沟通非常必要,这样在策划早期,数据分析师就能介入。既能协助运营理清思路,又能帮助运营算清目标,还能为上线后监控、事后复盘做好准备,一举三得。事前工作到位,事后不用吵架,大家合作共赢,是最好的状态。

04 事后补救的基本方法

如果事前没有定目标,一定要事后补救的话,牢记:核心不是什么自然增长率,而是“业务到底需要把指标做成什么样子”。特别是如同开头的情况。

整体目标已经扑街的情况下,事后再纠结自然增长率,往往会沦为甩锅大战。

这时候可以分三步做:

第一步:定方向

第二步:找方法 

第三步:看细节 

通过这样的操作,至少能结束稀里糊涂的状态,明确:我们到底要把曲线做成什么样。判断本次的方法要换成那种。在细节里,为下一次迭代找到优化方向。

注意,这么做更多是基于“目前已扑街”的判断。这么做在评估活动效果上并不科学。如果想科学评估活动,得事前设计好实验,分好测试组和参照组,测试用户响应效果。还是那句话:提前多准备,事后少纠结。

很多同学会说:即使这样做,我们公司的领导还是很迷信,运营还是很无脑,出了问题还是到处甩锅,咋办!即使这样,陈老师也建议大家先掌握:这个事该怎么做。

这样遇到问题,至少大家能判断:到底是我的问题,还是别人的问题。至少能知道该往哪个方向努力。这也是真实商业场景和科学实验室的区别:你就是得带着镣铐跳舞,在有限的数据,各种类型的同事,过高过低的期望值之间走钢丝。

有同学会说:咦?咋只少了一半打架,另一半是啥?答:是活动事后分析的另一个永恒纠结的问题:你做这个又怎样!为什么活跃用户人数不能再高点?高了怎么多又如何呢?它一个指标高了,其他低了,又咋办!

这就是我们常说的综合评估问题(陈老师习惯简称:又如何问题),有兴趣的话,我们以后再分享。

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

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