2014 年 4 月到 2017 年 3 月，我在北京木仓科技股份有限公司的初创团队做产品，负责驾考宝典 App 的 MVP 设计与整体架构。三年时间里，这款产品的日活跃用户从 300 万增长到 600 万，实现了翻倍。 今天回头看，真正决定这个结果的，不是某一个功能，而是两件很朴素的事：早期架构留没留出空间，以及有没有人认真做用户标签。
起点：先看清楚自己站在什么赛道上
「驾考」这个需求有一个很特别的性质：它是低频的事件型需求，却带来高频的期间型使用。 一个人一生可能只考一次驾照，听起来是典型的低频；但在真正学车的那两三个月里，他几乎每天都要刷题、看视频、做模拟考。 低频的入口，配上高频的使用期 —— 这个结构决定了产品的核心不是「拉新一次」，而是把用户使用期内的每一天都服务好。
这也解释了为什么在案例复盘里，这段经历被概括为「用户增长」而不是「拉新」。 在一个学员必然会离开的产品里，日活的意义不在于「留住」一个人，而在于让他在使用期内的活跃天数尽可能多、尽量不流失。 目标一旦这样定义，后面的架构选择与标签体系就有了明确方向。
MVP 设计的取舍：先把主干跑通
初创团队做 MVP，最大的诱惑是「什么都想做」。但在资源极度有限的阶段， MVP 的价值不是覆盖最多功能，而是用最短路径验证「这件事有人真的在用」。 我们当时的选择是：围绕驾考宝典 App 本身，先把最核心的使用链路跑通，让学员「进得来、用得上、考得过」。
值得注意的是，这套 MVP 里除了 App 本身，还包含了两块很容易被忽略的基础设施 —— 自研 IM 通信系统与推送系统。在很多团队把这两件事当成「接个第三方 SDK 就行」的时候，我们选择了自研。 这不是为了技术炫技，而是因为它们是与用户建立日常触达的基础通道：只要用户还在学车期，推送就是把他拉回来刷题的钩子，IM 就是承载答疑与交流的场域。
回头看，当时判断一件事该不该进 MVP，其实就三条：一、它是不是核心使用链路上的一环；二、它能不能被数据验证效果； 三、它未来有没有可能被复用。三条里能命中两条的，才值得在 MVP 阶段就投入。
架构决定天花板：为什么坚持自研 IM 与推送
产品架构这件事最残酷的地方在于：它的问题不会在第一天暴露，只会在第二年、第三年集中爆发。 一个在十万用户量级下「能用」的架构，到了百万、千万量级就可能处处是瓶颈。
以推送为例。它的本质是「在正确的时间，把正确的消息，发给正确的人」。当用户规模是几十万时， 全量推送也能凑合；但当你要做到按人群、按进度、按状态分层触达的时候，推送系统就必须具备与用户标签体系打通的能力。 如果推送是外包给第三方的黑盒，这种细粒度的分层触达就很难实现。自研带来的最大价值，不是省了成本， 而是把「触达能力」和「用户理解能力」握在了自己手里，可以自由组合。
IM 通信系统同理。它承担的不只是「聊天」，更是把用户的提问、互动、反馈沉淀成产品可以理解的信号。 一个自研的 IM，意味着这些信号可以直接进入分析体系，而不是停在别人的服务器上。 早期架构给未来的增长留没留口子，直接决定了后期能跑多快。
用户标签体系：29 组画像与 300+ 细分标签
如果说架构是「骨架」，那用户标签体系就是「神经系统」。在这段经历里，我们一共创建了 29 组用户标签画像、300+ 细分标签，并引入了神策用户画像能力来支撑分析。
为什么要做到「300+ 细分标签」这种颗粒度？因为驾考这个场景的差异，远比表面看起来更细。 同样是在刷题的学员，处在不同的备考阶段、面对不同的科目、处在不同的地区、有着不同的学习节奏， 他们需要的内容与提醒完全不同。标签的意义，是把「一群用户」拆成「一群处境相似的人」。 只有拆到这个程度，个性化才不是一句空话。
29 组画像的价值在于分层：先按大类把用户分组，再在组内用 300+ 细分标签刻画差异。 这样既能向上做整体判断，也能向下做精准动作。标签体系不是越多越好，而是「能对应到具体动作」才有价值。
DAU 从 300 万到 600 万：增长是怎么发生的
需要说明的是，增长从来不是某一招的结果。把当时的动作拆开看，是「触达 + 内容 + 分层」三件事同时在起作用： 推送系统负责把用户叫回来，内容负责让他有得看、有事做，标签体系负责决定「对谁用什么方式叫」。
这套组合带来的直接好处是可迭代。因为触达是可分层的，每一次推送的效果都能被分人群回收， 于是「哪个阶段该提醒什么」这个问题，就有了数据答案，而不是靠猜。产品就这样一轮一轮地调整， 活跃天数一点点往上走。增长的复利，来自可测量的迭代；而可测量，前提是有标签。
在一个用户必然会离开的产品里，日活的意义不是「留住他」，而是让他在使用期内的每一天都被服务好。把这件事做扎实，数字自然会来。
—— 驾考宝典项目复盘沉淀：四条可复用的产品方法论
这段经历过去了很多年，但其中有几条经验，我在后来的信贷、环卫、通信、影视等完全不同的行业里，依然在用。
- 先定义目标，再定义功能。把「拉新」换成「使用期内的活跃天数」，整个产品的优先级排序会完全不同。
- MVP 只押核心链路。能命中「核心链路、可被数据验证、可被复用」两条以上的，才值得在 MVP 阶段投入。
- 架构要为下一阶段留口子。早期是不是自研推送与通信，决定了后期能不能做细粒度的分层触达。
- 标签体系要能对应动作。29 组画像 + 300+ 细分标签的意义不在「多」，而在每一个标签背后都能挂上一个具体动作。
如果要把这四条再压缩成一句话：产品的天花板，往往在它还没有长大之前就已经被定下来了。 你在 MVP 阶段选择自研什么、坚持记录什么、把标签拆到多细，都会在几年后以「增长空间」的形式还给你。
如果重来一次，我会改的三件事
复盘如果只讲做对的地方，价值会打折。站在今天回看那段经历，有三件事如果能重来，我会做得不一样。
第一件，标签体系上得太「重」。29 组画像、300+ 细分标签这个规模，在数据治理能力还不足的早期， 会产生大量「建得起、养不起」的标签。更稳妥的做法是，先把与核心动作强绑定的那一批标签做扎实， 再按季度扩容。标签的价值不在数量，而在每一个都真的被用上。
第二件，推送的「度」把握得不够精细。触达能力一旦握在自己手里， 很容易从「精准」滑向「频繁」。当时如果更早建立一套触达频次与打扰的约束规则， 中长期的用户体感会更好。这件事的教训是：能力越强，越要给自己定边界。
第三件，跨团队的方法沉淀偏晚。很多判断当时只存在于少数人的脑子里， 没有及时写成文档与规范。产品方法论的复利，来自它能不能被团队里下一个人接手。 今天我做任何项目都坚持把结论写下来，源头就在这里。
资料来源：本文数据引自本站 商业化案例 页面「驾考宝典 App · 用户增长」条目与 创始人经历 页面 2014.04–2017.03 履历。