激活路径
激活(Activation)在 SaaS 里通常指用户达到某个会显著提高留存概率的里程碑。对 agent 产品来说,这个里程碑不能只看账号动作,因为注册、安装和首次登录都还没有证明 agent 真的完成了工作。
更合适的激活定义是:首次成功任务(First Successful Task, FST)。这里的“成功”不只是任务跑完,而是用户认为结果有用、可采纳、值得再次使用。
激活漏斗
这个漏斗不是行业标准答案,而是分析框架。每一层都对应一个不同的问题:
1. 注册 → 首次发起任务
用户需要想清楚“我可以让 agent 做什么”。这一步的损耗常常来自任务表达负担,而不是登录摩擦。
应对方式是提供少量高质量首任务模板,让用户不用从空白输入框开始。模板应和产品的稳定能力一致,而不是展示最复杂的能力。
2. 首次任务发起 → 任务完成
Agent 完成率高度依赖任务类型。首任务应从最稳定的 workflow 出发:输入少、步骤短、外部依赖少、失败后容易解释。
反例是把首任务设计成“基于一份很长的材料生成完整方案”。这类任务更能展示上限,但上下文、工具、评价标准都更复杂,不适合承担激活。
最优首任务的特征:
- 输入信息少
- 输出可立即评估(用户看一眼就知道好坏)
- 历史完成率稳定
- 单任务耗时可预期
- 失败后能给出明确下一步
3. 任务完成 → 用户接受
Agent 返回了输出,不等于用户接受输出。质量门槛要看用户是否愿意使用、复制、发布、保存,或基于结果继续下一步。
测量方式:
- 显式反馈:任务完成后询问是否符合预期。数据清楚,但会打扰用户。
- 隐式信号:复制、保存、发布、二次编辑、立即重提任务等行为。
- 人工抽样:对关键客户或关键 workflow 做质检,避免只依赖行为数据误判。
4. 接受 → 7 日留存
激活之后还有关键一跳:用户是否回来。一次成功可能让用户觉得“很厉害”,但如果没有进入真实工作入口,很快就会被遗忘。
应对:
- 基于首任务类型推荐相邻任务
- 集成到用户已有工作流(浏览器扩展、桌面应用、Slack/Teams 集成)——降低“想起来用”的门槛
- 在用户再次获得价值之前,谨慎触发升级销售
指标口径
| 指标 | 公式 | 看什么 | 注意事项 |
|---|---|---|---|
| 首次任务发起率 | 首次发起任务的注册用户数 / 注册用户数 | 用户是否知道该让 agent 做什么 | 不要把打开模板、浏览示例算作任务发起;以真正提交任务为准。 |
| 首次任务完成率 | 首次任务成功结束数 / 首次任务发起数 | 首任务是否足够稳定 | 应排除用户主动取消;超时、工具失败、无法给出结果都应计入失败。 |
| 首次任务接受率 | 被用户接受的首次任务数 / 首次任务完成数 | 输出是否达到真实质量门槛 | 接受信号要按产品定义:复制、保存、发布、确认、继续下一步,不能只看 thumbs up。 |
| FST 后回访率 | FST 后 7 天内再次使用的用户数 / FST 用户数 | 首次价值是否进入使用习惯 | 自助产品可看 7 日;企业工作流可能更适合 14 日或一个完整业务周期。 |
| 注册 → FST 全漏斗 | FST 用户数 / 注册用户数 | 获客、引导、能力与质量是否共同成立 | 必须按渠道、cohort、首任务类型拆分,否则平均值会掩盖真正断点。 |
阈值不应照搬。自助产品、企业部署、开发者工具和行业 agent 的基线差异很大,最好按 cohort、渠道和首任务类型拆开看。
常见误区
- 追求“零摩擦注册”忽略首任务质量——注册转化率高没用,FST 漏斗一塌糊涂;常见于优化北极星指标错位时
- 首任务过度复杂以“展示能力”——产品团队倾向于让首任务展示 agent 最难的能力(“看,能写完整商业计划书!”),但失败率高反而劝退
- 激活完成后立即推销升级——用户首次正面体验后被立刻推销,转化率不会高,反而损害信任
- 不区分激活与留存——激活完成率高但留存率低,说明首次价值是“惊艳但用不上”,需要重新设计任务类型而不是优化激活漏斗
与其他章节的衔接
- 任务完成率与质量层指标:metrics/overview
- 用户上线流程的具体执行:playbooks
- 激活推荐任务的 cost 控制:economics/controls-and-roi
这页有帮助吗? 谢谢反馈。