先把那天写清楚
2023 年 11 月的一个周三下午，大概四点多，我被叫到会议室门口。领导的原话是这样的：「最近留存有点问题，你想想办法把它做上去。」没有数字，没有截止日期，没说哪个留存，也没说这是不是我一个人的事。我当时点头说行，然后回工位打开数据后台，盯着那条曲线看了差不多四十分钟，鼠标都没动一下。
后来我算过，这句话我理解出了至少四种意思：7 日留存、30 日留存、新用户次日留存、或者是付费用户的续费率。它们背后的活完全不一样——前两种可能动产品，后一种八成得动销售和客服。我当时没意识到这个模糊性，直接从最熟悉的地方下手了。
我先干的那件蠢事
我的第一反应是搞推送。理由现在看挺荒唐的：推送是我最熟的东西，改起来最快，不需要求人，一个人就能上线。我写了两周，A/B 测了六版文案，从「你有一份报告待查看」到带用户昵称的版本，最长的那版有 27 个字。数据回来之后我盯着看很久：7 日留存从 23.1% 变成 23.4%。样本是一万两千多用户，p 值 0.31，这个差异基本可以当作噪声。
那两周我记得最清楚的不是数据，是周五晚上十点多我还在改第七版文案，改完发给一个同事看，他隔了半小时回我三个字：不太行。就三个字，也没有下文。我当时挺破防的，但也没敢问哪里不行——因为我心里其实也没底，我不知道这个方向对不对，我只是想让自己看起来在忙。
真正把我敲醒的是另一件事。我们组另一个同事也在做同一个任务，他花了两周做了套新用户引导的动画，做得挺漂亮，上线之后留存也没怎么动。我们俩在楼梯间碰见，互相看了一眼，谁都没说话。那一下我意识到，我们可能连题目都没读懂。
转折点是一张只有三行的 Excel
第四个周一早上，我没写代码，做了个特别土的东西：一个 Excel，横轴是日期，纵轴是留存率，只有三列数据——新注册用户 7 日留存、新注册用户 30 日留存、付费用户 30 日留存。我把它截图发过去，问了一句「你要的是哪个」。
他回了：「差不多，不过我要的是付费用户那条，另外是看月度不是看周度。」
就这么一句话。后面我自己复盘，如果早三周问这一句，能省掉大概 60 个小时的无效工作。
拿到准确的问题之后，事情反而变简单了。付费用户 30 日留存当时的数字是 41.6%，目标定的是 48%，时间给到 12 月底。我拉了一张 cohort 表，SQL 大概长这样：select date(reg_time) as d, count(distinct case when datediff(active_date, reg_time)=29 then user_id end)/count(distinct user_id) from users group by 1——跑完之后我发现一件事：流失的人里，有六成是在注册后前三天走的，而前三天里，有七成的人卡在新手引导的第三步。
真正的毛病在接口上
我当时的预期是引导流程的文案或者步骤设计有问题，结果打开性能日志一看，不是。第三步那个页面同时打了三个接口，是串行的，一个等一个，总耗时 4.8 秒。加上那一屏默认加载了四张用户头像，每张 400KB 左右的 PNG，还没做压缩。
改的东西其实不复杂：三个接口改成并行请求，头像换成 WebP 格式压缩到 12KB 左右，第三步的加载时间从 4.8 秒降到 1.1 秒。改完的第二周，付费用户 30 日留存到了 49.3%，比目标高了 1.3 个点。
但这里有个我到现在都觉得别扭的地方：这个结果跟「留存」这个任务词本身几乎没关系，它本质是个性能问题。如果我一开始就按「留存不行」这个思路去优化产品设计、优化推送、优化引导文案，我可能三个月都摸不到边。问题在一句话里被藏起来了。
我现在的做法，和一些可能不对的看法
我现在的流程是三件事，顺序不能反。第一件，把任务里的动词换成名词加数字——「做上去」换成「付费用户 30 日留存到 48%」；第二件，找出这句话背后到底是谁在问，很多时候你的领导也只是在转述他领导的话，他自己也没把口径想清楚；第三件，用最小成本先做一张图、一个表格、一份三行的样稿去确认，别急着写代码或者写方案。花两小时做这张表，比花两周做方案划算得多。
我知道这个说法不一定对所有人都成立。有些团队就是快节奏，领导也确实烦这种「反复确认」的人，觉得你在拖延。所以操作上我会把握一个度：先确认一次，用最低成本的方式；如果对方也含糊，那就自己定一个数字和期限，白纸黑字发过去，说「我先按这个口径做，有偏差随时叫停」——把决定权交回去，但先把题目写出来。
说到底，我这几年的感受是：工作里真正难的部分，往往不是解题，是题干本来就没写完。而我们大多数人的本能是赶紧解题，因为解题有安全感，看得见进度，还能显得自己很努力。定义问题恰恰相反，它看起来什么都没干，还挺像是在偷懒。但如果只让我留一条经验，就是这条。