下载 7 万次,不如一个按钮的位置值钱

刚开始做 App 的时候，我特别迷信功能。

总觉得增长来自新功能。

收入不行？

加功能。

留存不行？

加功能。

下载停了？

还是加功能。

那几年我做过不少项目，也踩过不少坑。

后来有一个项目，慢慢把我这个习惯改掉了。

因为它让我第一次非常直观地看到：

很多时候，一个按钮的位置，真的可能比你做一个月新功能还值钱。

1. 我以前总以为，产品做不上去，是因为“还不够丰富”

这个App有一段时间，30 天下载量能到 7 万左右。

如果只看 top line，其实不算太差。

至少不是那种一眼就知道没机会的项目。

但问题在于，下载有了，收入却一直没有达到预期。

这时候特别容易得出一个很顺手的结论：

“说明功能还不够。”

于是我当时的思路也很简单。

列需求。

开新入口。

补新玩法。

加新能力。

总之先把“产品看起来更丰富”这件事做出来。

这是很多独立开发者都很容易走的一条路，因为它最符合直觉，也最像在做事。

但问题是，功能上线和业务改善，很多时候根本不是一回事。

忙活一圈之后，我再去看数据，变化并不明显。

不是完全没变化。

而是远远配不上投入。

这时候我才开始认真怀疑：

也许问题不是“功能太少”，而是我根本找错了优化对象。

2. 真正决定收入的，往往不是新功能，而是几个关键转化节点

后来我开始换一种方式看 Firebase。

不再先看下载量，也不再只盯总收入。

而是去拆用户路径，尤其是关键漏斗节点。

比如：

• – 用户完成一次核心行为之后，下一步会不会继续

• – 用户什么时候触发免费额度上限

• – 触顶之后，是点广告继续、点订阅，还是直接退出

• – 进入 paywall 之后，CTA 有没有被点

• – trial start 到 paid 的转化怎么样

• – 激励广告有没有成功展示，展示后有没有拿到 reward

当我开始这么看数据之后，很多事情突然变清楚了。

我发现用户不是因为“功能不够多”离开的。

很多用户甚至根本没走到那些新功能。

他们在更前面的关键节点，就已经流失了。

也就是说，我之前拼命往产品后面加东西，但用户根本没走到后面。

这就像你在商场二楼装修得特别豪华，但大部分人连一楼收银台都没过。

你做得再好，也很难产生结果。

3. 那个我以前没太当回事的弹窗，后来变成了最值得研究的页面之一

举个很典型的例子。

用户达到免费使用上限之后，会看到一个选择页面。

从产品实现角度看，它一开始只是一个普通弹窗。

从业务角度看，它其实是整个变现系统里最敏感的分流节点之一。

因为用户在这一刻会做出很明确的决策：

• – 继续使用

• – 看激励广告继续使用

• – 进入订阅页

• – 或者直接关闭 App

很多收入，不是在用户下载时决定的。

也不是在你做了多少新功能时决定的。

而是在这个瞬间决定的。

后来我把这个节点单独拎出来看，发现它本质上就是一个微型漏斗：

• – 先有 `limit hit`

• – 再看用户点不点 `watch video`

• – 或者会不会转去 premium

• – 再往后才是 reward、trial、subscription 这些结果

一旦你这样拆，产品就会从“感觉问题很多”，变成“知道该先动哪一段链路”。

4. 后来我做的一个很小的实验，让我彻底不敢轻视按钮顺序这种事

有一次实验我印象特别深。

当时我们做的，不是新增功能，不是重做页面，也不是改一整套订阅策略。

只是调整了一个关键页面里两个按钮的展示顺序。

比如原来是：

• – 先看广告继续

• – 再看开通订阅

后来换成：

• – 先看开通订阅

• – 再看广告继续

这种改动，从工程量上说非常小。

如果用 Remote Config 控制，甚至都不一定需要重新发版就能切。

代码改动可能不到半天。

从产品说明上看，它也小到几乎没法写进更新日志。

但从业务上看，它改的不是“按钮摆放审美”，而是用户在关键分流点看到的第一选择。

这背后影响的是一整串指标：

• – `action_limit_hit` 之后的点击分布

• – `WatchVideo_click` 的占比

• – paywall 入口点击率

• – paywall open rate

• – trial start

• – rewarded ad revenue

• – 用户触顶之后是否继续使用

这就是为什么有些 UI 微调，最后能带来比新功能更明显的业务变化。

因为它改的不是表面样式。

它改的是决策顺序。

那次之后我第一次非常明确地意识到：

很多产品问题，并不是功能不够。

而是关键路径没有设计好。

5. 现在回头看，我做过最值钱的改动，很多都小得不起眼

现在再回头看。

我做过最有价值的一些改动，往往不是开发周期最长的功能。

反而是那些当时看起来有点“不值一提”的小调整：

• – 一个按钮的位置

• – 一个弹窗出现的时机

• – 一个 CTA 的顺序

• – 一个默认选项

• – 一个页面的视觉层级

• – 一个关键路径里的主次关系

这些改动单独看都不大。

但如果它们发生在主漏斗上，价值就会被放大很多倍。

这也是为什么我后来做产品时，会不断提醒自己：

先别急着加功能。

先去看用户到底是在哪里离开的。

先去找真正的瓶颈节点。

先确认问题发生在漏斗前面，还是后面。

因为很多时候，真正限制收入的，不是产品“没有更多功能”。

而是用户根本没顺利走到你希望他做决定的那个地方。

所以后来我越来越相信一句话：

下载 7 万次，不如一个按钮的位置值钱。

不是因为功能不重要。

而是因为在很多阶段，决定业务结果的，往往不是功能总量，而是关键路径上的转化效率。

如果你也在做产品，我还挺建议你回头看一眼自己的主漏斗。

别先问“还要做什么新功能”。

先问：

• – 用户最常走的是哪条路径？

• – 哪个节点流失最大？

• – 哪个页面最影响收入？

• – 哪个按钮其实在替你决定业务结果？

很多时候，答案不会在 roadmap 里。

答案就在一个你以前没太当回事的按钮上。