最近跟几个做产品的朋友聊天，发现大家兜兜转转都在说同一个现象：功能迭代没停、投放预算没砍、渠道也没动，产品增长却突然停住了。有的团队第一反应是加预算，有的马上改首页，还有的直接把锅甩给"负责增长的人"。但在动手之前，几乎所有人都漏了一个最基础的问题——你清楚你的增长是从哪一周开始不增长的吗？

这句话是我在一档常聊增长话题的播客里听来的。嘉宾给了一个很朴素的说法：增长骤停不是病，只是症状，背后可能藏着好几种完全不同的病根。想找病根，别靠猜，靠框架。后来我自己按那套思路反复用过几次，也做过一些简化，下面就是把五步诊断框架串成完整实操链路的过程记录。产品、运营、增长岗位的同学可以直接照着用；第一次面对增长停滞、不知道从哪儿下刀的人，尤其适合。

1. 先别急着"修增长"：看懂曲线掉头的三种减速模式

很多团队一看到增长掉头，就默认这是"同一个问题"，然后全员扑上去做各种优化。但真实情况是，增长停滞至少分为三种完全不一样的模式，每种模式指向的根因方向天差地别。我习惯先把曲线形状拿出来看三分钟，再决定后面怎么干。

1.1 断崖式下跌：第一时间去翻发布日志和埋点配置

断崖式下跌最容易被误判成"大盘不行了"，但绝大多数断崖都是自己造成的。我遇到过最典型的一次：某社区类产品一周内新增跌了四成，大家先质疑投放，后来翻埋点才发现是新版本把注册成功事件的上报时机改成了"激活后一小时"，大量用户被归到第二天，统计直接错位。

所以遇到断崖，第一件事不是拉数据开会，而是去看两个清单：最近两周的发布清单、数据仓库里的埋点变更记录。很多时候病根就写在里面，连诊断都用不上。

1.2 缓坡式衰退：病根藏在中期统计里

缓坡式比断崖难处理得多。它的特点是没有一个明确的"出事周"，而是每周末看周报都差一点点，两三个月后才发现增长率从每周8%悄悄滑到了每周3%。这种模式常见于投放预算持续加但转化效率递减，或者市场渗透率过了拐点。

缓坡式的麻烦在于，团队会因为"每周跌幅不大"而持续忽视它，等真正重视起来时，问题已经被叠加了好几层：渠道素材老化、用户获取成本上升、老用户回访减少全部混在一起。诊断这种模式，必须回到第2步的量化方法，先把拐点找出来，切忌只看月度汇总。

1.3 平台期：是产品价值触顶还是运营天花板

平台期是最迷惑人的——数字没有变差，只是不涨了。很多管理者会说"先稳一稳"，但我建议做一次压力测试：把当前正常运营动作全部停掉一周，如果活跃用户立刻大跌，说明产品本身没有增长引擎，之前全靠运营硬撑；如果停掉运营动作后数据依然平稳，说明用户留存是健康的，问题出在增量获取上。

搞清楚是这两种情况里的哪一种，后面的药方完全不同：前者要去补产品价值链路，后者要去补渠道和供给能力。

2. 下刀第一步：把"不增长"量化成可对比的指标缺口

诊断的第一个下刀点，不是找出"为什么"，而是先确定"从哪一周开始、降了多少、是哪个指标先降的"。这一步做得越扎实，后面越不会跑偏。

2.1 用周粒度锁定拐点，别被月均值骗了

我见过太多团队用月度数据看增长，结果一个月里第2周就已经出了问题，到月底平均下来只看到微降，硬是把一次急性事故拖成了慢性病。建议一律用周粒度，并且把新用户数、激活率、D1留存、每周活跃这几个关键指标全部拉出最近6到12个月的周趋势。

如果怕周数据抖动太厉害，可以做7日平滑，但不要直接切到月粒度。平滑的目的是滤掉噪声，而不是把真实的拐点抹平。

2.2 一个简单的滚动均值判断法

可以用一个很朴素的规则来确认拐点：计算指标最近4周滚动均值与最近8周滚动均值的比值，连续3周低于0.9，基本可以认定这条指标已经结构性地下了一个台阶。下面是一段可以直接跑的参考代码：

import pandas as pd # df 至少包含两列：week（周）和 metric（要观察的指标） # 建议把新用户数、激活率、D1留存、每周活跃分别跑一遍 df['ma4'] = df['metric'].rolling(4).mean() df['ma8'] = df['metric'].rolling(8).mean() df['ratio'] = df['ma4'] / df['ma8'] # 连续三周 ma4 不足 ma8 的 90%，基本可以确认拐点 df['flag'] = (df['ratio'] < 0.9).astype(int) df['flag_3w'] = df['flag'].rolling(3).sum() print(df[df['flag_3w'] >= 3][['week', 'metric', 'ma4', 'ma8', 'ratio']])

跑完后你会得到一个精确的"嫌疑周"。有了这个锚点，后面所有拆解都围绕"嫌疑周之前和之后"来做对比，而不是笼统地说"最近增长不好"。

2.3 先排除口径变化，再谈业务原因

这一步是很多人跳过的，也是最容易误诊的环节。所谓口径变化，就是指标没变，但"度量方式"变了。常见的有：新用户定义从"注册成功"改成"首次使用核心功能"；归因窗口从7天改成24小时；第三方SDK升级后事件名变了；后台看板某天悄悄改了过滤条件。

怎么排除？很简单，找三个同一含义但不同统计路径的指标做交叉验证。比如客户端埋点数和服务端日志数对比，如果两个数据源出现同样的拐点，那大概率是真实变化；如果只有一个数据源跌了，另一个纹丝不动，先别研究业务，去查数据链路。

3. 第二刀和第三刀：用"新增×激活×留存"拆解衰减矩阵

确认了拐点时间之后，就要把"整体增长"这个大口袋拆开，看看究竟是哪个引擎熄了火。这一步需要回答的问题只有一个：新用户没有变少、老用户留不住、还是来了的人没有被成功激活？这三个方向对应完全不同的解法。

3.1 把北极星指标拆到三个增长引擎上

绝大多数产品的北极星指标都可以被拆成下面这个关系：

新增贡献 = 新用户数 × 激活率 存量贡献 = 存量用户数 × 用户回访率 整体活跃 = 新增贡献 + 存量贡献 + 召回贡献

这里的核心思路是：不要把"周活跃下降"当成一个单一问题，而是先算清楚，这一周活跃下降里，有百分之多少来自新用户减少，多少来自老用户回访减少。很多团队诊断了半天，最后发现新用户流入一直很稳，问题全部出在老用户回访率连续五周下滑，而这时候你去改投放渠道，等于给死人喂饭。

3.2 同期群对比：找出"最先变坏的那批人"

单纯看整体留存曲线会有个问题：它会把不同时期的用户混在一起，看不出是"所有人都在变差"还是"某一批人进来后变差了"。

正确做法是做同期群对比。以拐点周为分界线，取之前8周的新用户和之后8周的新用户，分别画出第一周活跃、第二周活跃、第四周活跃的归一化曲线。如果两条曲线几乎重叠，说明留存机制没有变化，问题出在用户质量或获客数量上；如果拐点后的同期群曲线明显低于拐点前，说明产品对这批新用户的承接能力出了问题。

3.3 一张衰减矩阵表，让主次矛盾自己浮出来

把多个指标按周排列，标出每个指标相对拐点前的下滑幅度，你会得到一张很直观的衰减矩阵。下面是我在某个模拟项目里做过的示例：

这张表一出来，主次关系非常清楚：新用户数最早下滑且幅度最大，激活率和D1留存只是跟随，D30留存完全稳定。这说明病根在获客端，不在产品价值端。这时候整个排查范围就从"全公司变量"收窄到了"投放、渠道、落地页"这几块。

4. 第四刀：渠道、场景与人群三张表的交叉定位

衰减矩阵告诉我们"是哪个指标坏了"，但还不够定位到具体病灶。第四刀是把问题继续往下切，切成渠道、场景、人群三个维度的交叉表。

4.1 渠道×周趋势：先判断是内因还是外因

把新用户数按来源渠道拆开，再回到刚才的拐点周。这里有个百试百灵的判断准则：如果只有某一个渠道在跌，其他渠道都平，那大概率是外因——这个渠道的算法调整、出价水位变化、素材疲劳，甚至对手在同一个渠道加价抢量；如果所有渠道都在同一周开始跌，先怀疑内因——首页改版、价格调整、品牌负面事件、或者埋点统计出问题。

我踩过一个大坑：某次全渠道下滑，我们以为是平台规则变化，花了两周去查外部原因，最后发现是落地页上的一行诱导注册文案被合规团队删了，导致所有渠道的转化率同步下跌。所以全渠道同步异常时，先查"所有用户都会经过的公共路径"。

4.2 场景×行为路径：激活瓶颈卡在哪一环

如果问题出在激活率或早期留存上，就把新用户从注册到首次体验核心价值的关键行为路径拉出来，按步骤做漏斗。常见的场景有：注册页填写、邮箱验证、新手引导、首次创建内容、首次触发核心动作。

这种拆解要自带时间维度：把拐点前后的漏斗每一步转化率并排比较，你会看到究竟是哪一环突然出现了堆积。以前排查某个内容产品时，我们一度以为是推荐算法变差了，漏斗拆完才发现是新手引导里的"上传头像"步骤从选填被改成了必填，光这一步就拖掉了四成新用户。

4.3 人群×版本与设备：把特殊异常捞出来

不同人群在不同版本上的表现往往差异巨大。建议按操作系统版本、App版本、注册方式、地域等维度把用户分层，然后计算每层在拐点前后的指标变化率。

如果下滑集中在某个旧版本或某种登录方式上，那就是局部故障，处理起来很快；如果所有维度全面下滑，才需要回到产品定位和竞争层面去思考。这个动作的价值在于，它能把"全行业都在跌"和"只有我们跌"区分清楚。做法也很朴素：找三个同类产品的公开趋势做对照，如果整个大盘都在跌，你没必要焦虑到推翻产品策略。

5. 第五刀：最小验证实验，把"嫌疑"变成"确诊"

前面四刀做完，你手里会有一堆嫌疑变量，但嫌疑不等于定论。第五刀的目的，是用最小成本设计一个验证实验，让数据来确认病根。很多团队走到这一步就急着上优化方案，结果改了一堆东西，数据好了却说不清是哪个动作起的作用，数据没变好更是一头雾水。验证实验就是用来避免这种糊涂账的。

5.1 回滚是性价比最高的验证手段

如果嫌疑对象是某个版本改动，最直接的验证就是回滚。先圈定一个完整的用户周期作为观察窗口，把有问题的改动回退到上一个版本，灰度给10%到20%的用户。如果这些用户的关键指标立刻恢复到拐点前的水平，基本可以确诊就是这个改动导致的负反馈。

我在一个资讯类产品上真实经历过一次：新用户激活率从48%掉到40%，产品团队坚信新版引导更好看，但回滚灰度一跑，老引导的激活率回到了47%。后来虽然没有完全回滚，但新引导被重新设计成了更短的一步式流程。没有这个回滚实验，我们大概率会在错误的方向上继续优化两个月。

5.2 用"复盘重启"验证外部因素

如果嫌疑来自外部渠道或市场因素，比如某个投放渠道效率下跌，可以用"复盘重启"来验证：把暂停两周的投放策略以极小的预算重新跑起来，看是不是仍然出现同样的问题。如果重启后效率恢复，说明之前的下跌是临时性波动；如果重启后依然很差，那就是渠道基本面变了，比如素材库存质量下降或者用户需求转移。

这个方法同样可以用于验证"是不是竞品抢量"：在一个局部市场故意把出价提到高位，观察转化率是否恢复，来反推之前的下滑是否因为竞价失利。注意验证预算一定要小，目的是拿到结论，不是为了冲量。

5.3 验证时间窗：两个用户周期内必须有反应

设计验证实验时，一定要提前定好成功标准和时间窗。我的经验是：观察窗口至少覆盖两个完整的用户周期。如果产品看D7留存，那么至少跑两周；如果看订阅续费，那要看完整订阅周期。时间窗太短，实验结果会被噪声淹没；时间窗太长，又可能错过快速止损的时机。

另外还要记住一个反直觉的点：验证实验没跑出显著差异，本身也是一种重要结果。它意味着你的嫌疑对象大概率是错的，这时候要回到第4步的交叉表重新看，而不是硬着头皮去改已经确定的改动。

6. 一张病根清单：常见根因、验证信号和整改动作

就算框架在手，很多新手还是会在"到底病根是什么"这一步卡住。下面这张表是我根据多年实操整理的常见病根对照，可以作为第5步实验设计的参考起点：

6.1 渠道质量下滑

渠道质量下滑很隐蔽，因为表面上看，新增量没有明显变化，但激活率和早期留存会先于新增量出现微降。等到新用户数真正开始跌时，渠道质量其实已经恶化很久了。验证方法很简单：把该渠道新用户的D1、D7留存和自然渠道新用户对比，如果差距持续拉大，说明这个渠道带来的用户匹配度正在变差。整改不是简单加预算，而是要么换投放素材，要么直接降预算。

6.2 新用户激活摩擦

激活摩擦的典型特征是：注册数还行，打开App的人也不少，但走到"首次体验核心价值"这一步的人少了一大截。这通常出在注册流程过长、新手引导太复杂、核心功能入口太深这几个地方。处理这种病根，不需要动底层产品逻辑，把引导路径砍短、把必填项改选填，效果往往立竿见影。

6.3 老用户价值感下降

老用户价值感下降是最难诊断的一类，因为DAU可能变化不大，只有打开频次和核心动作次数在悄悄减少。建议盯着两个指标：人均每周触发核心动作的次数，以及深度使用用户占活跃用户的比例。如果这些值在持续下降，说明用户对产品价值的感知在变弱，常见解法是推出新的使用场景、改版核心交互，或者优化提醒触达策略。

6.4 数据口径与埋点问题

我发现数据问题导致的"增长骤停"占比高得惊人。每次诊断前先问一句：数据仓库最近有没有变更？SDK有没有升级？有没有新增或删改事件？如果都没人知道，就按第2步的双链路对比去查。数据问题虽然不是业务病根，但它会浪费你最宝贵的诊断时间，必须设为一个固定的排查前置项。

6.5 外部替代方案挤压

外部挤压的特征是：所有渠道的新增都在跌，但老用户留存反而正常，甚至在竞品那里表现得更好。这种情况不是修补某个功能就能解决的，要做的是重新找出你的产品跟替代方案之间最差异化的场景，把资源集中到那个别人很难复制的环节上。要在产品框架层面调整，而不是靠运营小动作挽回。

6.6 第三方平台规则变化

这里说的平台规则变化包括某个系统权限更新、推荐算法调整、或者应用商店分发逻辑变化。它和渠道质量下滑的区别在于影响范围更广，往往是整个生态来源同时下跌。处理方式不是对抗，而是把获客渠道尽量分散，同时调整归因方式，避免让单一平台的波动绑架整体增长。

7. 诊断路上我吃过的亏：三类"假病根"和一个值得养成的小习惯

有了框架，不代表不会翻车。以下几类错误我基本都在真实项目里犯过，写出来是希望大家少走弯路。

7.1 幸存者偏差：别只盯着还活着的用户

做诊断时，人天然容易去访谈那些还在活跃的老用户，听他们说"产品很好用、我们离不开"。这些反馈会让你得出"留存没问题"的错误结论，但真正该问的是那些来了就走、用了三天就消失的人。后来我做诊断的时候，会强制自己先看流失用户的最后一周行为记录，再决定要不要采信访谈反馈。流失用户的沉默，比活跃用户的赞美信息量大得多。

7.2 确认偏误：让数据为自己的直觉背书

这个问题我犯过好几次：心里先认定是上次改版导致增长停滞，然后拉数据时只看改版相关指标，对反向证据视而不见。后来我养成了一个笨办法：在拉数据之前，先把我的猜想和"如果这个猜想是错的，我应该会看到什么数据"写在记事本上，强迫自己去检验反面假设。这个步骤只要花十分钟，却能有效避免后面两三周的无效排查。

7.3 指标幻觉：北极星指标选错，诊断全白做

所谓指标幻觉，就是把一个"看起来重要"的虚荣指标当成了北极星。比如以页面浏览量作为核心指标，结果用户只是刷得多，却没有任何行为价值。一旦北极星本身不能代表用户真实价值的实现，你基于它做的所有诊断都是在给错误目标打工。建议每隔一个季度重新审视一下：我们的激活定义里，用户做到哪一步才算真正体验到了价值？如果这个定义让人无法回答，那先别管增长，回去调整指标体系。

7.4 写"诊断笔记"：把排查时间从两周压缩到三天

最后分享一个我特别想推荐的小习惯：每一次增长诊断都开一份独立的笔记，按"拐点周、嫌疑变量、排除证据、验证实验、结论"这五栏记录。一开始写会觉得麻烦，但几次之后，你会攒出一个系统性的"已知病根症状库"。下次再碰到类似的曲线形态，直接翻笔记对照，至少能节省一半的排查时间。

我自己现在的做法是，每次诊断结束强制写一页纸复盘，包括当时判断错的地方。这套五步框架本身不难，难的是在每一步都保持冷静，用数据而不是情绪驱动决策。增长停滞从来不是突然发生的，它只是在等一个看明白的人。