SaaS 增长
这块看板有 10 张卡片
4 × KPI2 × 漏斗1 × 趋势1 × 留存2 × 分组表
这块看板上的指标
注册数 · 试用转化率 · 订阅数 · 新增 MRR · 试用开始数 · 活跃功能用户
问题在哪
注册和收入之间的三个断点
产品、增长、财务各拿一块。模板把它们放到一块看板上。
注册了但没激活
引导完成率不知道，因为没人上报最后一步。漏斗到注册就停了。
盯这个数： 引导完成率
功能装了没人用
按功能看使用量是某人一季度跑一次的数据库查询。feature_used 把它变成按账户的每日图表。
盯这个数： 活跃功能用户
到开票才发现流失
取消从计费系统事后传来。账户级留存能提前几周看到那段安静期。
盯这个数： 订阅流失率
模板指标
从注册到流失的 19 个指标
注册、激活、采用、试用、订阅、扩张和流失。名称与装完后的控制台一致。
| 指标 | 定义 | 格式 | 所在看板 |
|---|---|---|---|
| 注册数 | UNIQUES(signed_up) | 数值 | SaaS 增长 |
| 登录用户数 | UNIQUES(logged_in) | 数值 | 产品采用与留存 |
| 引导完成率 | UNIQUES(onboarding_complete) / UNIQUES(signed_up) * 100 | 百分比 | 产品采用与留存 |
| 功能使用次数 | TOTALS(feature_used) | 数值 | SaaS 增长 产品采用与留存 |
| 活跃功能用户 | UNIQUES(feature_used) | 数值 | SaaS 增长 产品采用与留存 |
| 人均功能使用 | TOTALS(feature_used) / UNIQUES(feature_used) | 数值 | — |
| 试用开始数 | TOTALS(trial_started) | 数值 | SaaS 增长 |
| 注册试用率 | UNIQUES(trial_started) / UNIQUES(signed_up) * 100 | 百分比 | — |
| 订阅数 | TOTALS(subscription_started) | 数值 | SaaS 增长 |
| 试用转化率 | TOTALS(subscription_started) / TOTALS(trial_started) * 100 | 百分比 | SaaS 增长 |
| 新增 MRR | PROPSUM(subscription_started.mrr) | 金额 | SaaS 增长 |
| 升级 MRR | PROPSUM(subscription_upgraded.mrr_delta) | 金额 | — |
| 收款金额 | PROPSUM(payment_succeeded.amount) | 金额 | SaaS 增长 产品采用与留存 |
| 邀请数 | TOTALS(invite_sent) | 数值 | — |
| 邀请接受率 | TOTALS(invite_accepted) / TOTALS(invite_sent) * 100 | 百分比 | 产品采用与留存 |
| 流失订阅数 | TOTALS(subscription_cancelled) | 数值 | — |
| 流失 MRR | PROPSUM(subscription_cancelled.mrr) | 金额 | 产品采用与留存 |
| 订阅流失率 | TOTALS(subscription_cancelled) / TOTALS(subscription_started) * 100 | 百分比 | 产品采用与留存 |
| 工单数 | TOTALS(support_ticket) | 数值 | 产品采用与留存 |
指标名称和公式来自行业包。TOTALS 数事件次数，UNIQUES 数人数，PROPSUM 对某个属性求和。本页所有数字都是示例数据。
模板装上的看板
每块看板由一组卡片组成：KPI、漏斗、趋势、留存、分布和分组表。装上以后可以改、复制、分享。
产品采用与留存
这块看板有 10 张卡片
5 × KPI2 × 趋势1 × 漏斗1 × 分布1 × 分组表
这块看板上的指标
活跃功能用户 · 引导完成率 · 邀请接受率 · 订阅流失率 · 功能使用次数 · 收款金额
漏斗
注册、完成引导、用上核心功能
激活漏斗用 7 天窗口。−46% 的角标标出引导和第一次真正使用之间的那一步。
注册激活漏斗
7 天窗口注册
2,400
完成引导
1,248
功能使用
674
按套餐拆
plan 是 signed_up 上的属性。自助套餐和销售协助套餐的激活率放在一张图上比。
数账户，不数人
把漏斗切到账户组织。同一租户的三个成员变成一个激活或没激活的账户。
试用到付费给 30 天
试用付费漏斗用 30 天窗口，第 28 天转化的试用也算。
包里的其他漏斗
- 试用付费漏斗注册 → 开始试用 → 订阅开始 · 30 天窗口
- 邀请漏斗邀请成员 → 接受邀请 · 14 天窗口
团队怎么用
SaaS 团队最先放上看板的东西
激活、按账户的采用、扩张，以及流失预警。
用法 1
把激活量成一个真实步骤
onboarding_step 和 onboarding_complete 给了漏斗中段。feature_used 带稳定的 feature 键，是整个模板围绕的价值时刻。
- 注册激活漏斗，7 天窗口
- 引导完成率作为 KPI 卡片
- 对一直没激活的注册做路径分析
注册激活漏斗
7 天窗口注册
2,400
完成引导
1,248
功能使用
674
用法 2
按账户看采用，不按点击
每个成员的 feature_used 都汇总到 group=account。账户排行显示哪些租户深度在用，哪些只登录过一次。
- 账户排行：活跃用户、功能使用、收款
- 由使用量和工单算出的健康分
- 按账户属性分群：套餐、席位、行业
示例场景： Orbit Media 付了 22 个席位，一个月只用了 58 次。客户成功在续约前打了电话，而不是续约后。
账户排行
最近 30 天| 账户 | 套餐 | 活跃用户 | 功能使用 | 收款 |
|---|---|---|---|---|
| Northwind Labs | Team | 14 | 1,860 | $1,190 |
| Acme Robotics | Business | 31 | 1,420 | $2,940 |
| Blue Harbor | Team | 6 | 640 | $590 |
| Kestrel Health | 试用 | 3 | 92 | — |
| Orbit Media | Business | 22 | 58 | $1,980 |
用法 3
用 MRR 跟踪扩张和流失
subscription_started、subscription_upgraded 和 subscription_cancelled 各带一个 MRR 数字。新增、扩张和流失 MRR 在一条趋势上，挨着收款金额。
- 新增 MRR 和流失 MRR 趋势
- 取消原因作为枚举属性
- 邀请漏斗看团队扩张
收款金额 vs 流失 MRR
收款流失 MRR
1月3月5月7月9月11月
用法 4
在取消之前抓住安静的账户
按账户数的注册后周留存，会在计费系统传来取消的两周前就往下掉。对这个分群设告警，客户成功就有了提前量。
- 按账户的注册后周留存
- 告警：付费账户 14 天内没有 feature_used
- 工单在同一个档案上
注册后账户留存（周）
| 注册同期群 | 账户 | 第1周 | 第2周 | 第3周 | 第4周 | |
|---|---|---|---|---|---|---|
| 9月1日当周 | 212 | 100% | 64% | 51% | 46% | 44% |
| 9月8日当周 | 236 | 100% | 66% | 53% | 48% | |
| 9月15日当周 | 198 | 100% | 61% | 50% | ||
| 9月22日当周 | 241 | 100% | 69% |
统计 × 客服
在第 14 天之前，联系卡住的试用
一个试用账户到了第 9 天还没用上核心功能。上下文卡片显示套餐、席位、上次登录和他们停下的那一步引导。邀请就针对那一步提供帮助。
- 对停在设置页的试用主动邀请
- 上下文：套餐、试用天数、席位、最后使用的功能
- AI 从你的文档答设置问题，再转给客户成功
示例场景： 第 9 天收到邀请的试用转化率 27%，没收到的 16%。同样的套餐，同样的来源结构。
账户上下文
- 套餐
- 试用 · 第 9 / 14 天
- 席位
- 3 名成员
- 最后一步
- 连接数据源
- 上次登录
- 2 天前
- 来源
- Google Ads · 品牌词
- /signup
- /onboarding/2
- /settings/integrations
- /docs/connect
app.yourtool.com/settings/integrations
TC
Sam · 客户成功
你好！看起来数据源这一步卡住了。我现在陪你一起接上？大概四分钟。
事件
13 个事件，3 个必需
引导和功能使用是浏览器事件；计费事件从服务端上报，发票号作为 insert_id。
| 事件 | 显示名 | 触发时机 | 必填属性 | 来源 |
|---|---|---|---|---|
signed_up必需 | 注册 | 账户创建时；服务端上报并带 login_id，之前的匿名行为自动合并。 | — | 服务端 网页 |
logged_in | 登录 | 每次登录，任何端。 | — | 服务端 网页 App |
onboarding_step | 引导步骤 | 设置流程的每一步，带步骤名和序号。 | step | 网页 App |
onboarding_complete | 完成引导 | 最后一步设置完成时上报一次。 | — | 网页 App 服务端 |
feature_used必需 | 功能使用 | 每次使用核心功能一条；feature 用稳定的英文键。 | feature | 网页 App |
invite_sent | 邀请成员 | 成员邀请同事时；一次多人就带 count。 | — | 网页 App 服务端 |
invite_accepted | 接受邀请 | 被邀请人加入时由服务端上报。 | — | 服务端 |
trial_started | 开始试用 | 服务端上报，带 plan 和 trial_days。 | plan | 服务端 |
subscription_started必需 | 订阅开始 | 首次付费订阅时由计费系统上报；mrr 折算为月度金额。 | planmrr | 服务端 |
subscription_upgraded | 升级 / 加席 | 计费系统上报，带 from_plan、to_plan 和 mrr_delta。 | — | 服务端 |
payment_succeeded | 付款成功 | 每期账单收款；insert_id = invoice_id。 | invoice_idamount | 服务端 |
subscription_cancelled | 取消订阅 | 计费系统上报，带 mrr 和原因码。 | — | 服务端 |
support_ticket | 提交工单 | 工单创建时，带分类和优先级。 | — | 网页 App 服务端 |
事件名、必填属性和来源来自行业包。标为「服务端」的事件必须由你的后端上报；订单号、发票号作为 insert_id 去重。
场景
两个产品团队，两块看板
场景示例，非真实评价。
我们从没写过埋点方案。全埋点把点击收上来，AI 起了名，我在收件箱里确认了六个事件。当天下午激活漏斗就能用了。
JL
J. L.
产品经理 · B2B SaaS
按套餐看试用转化率，Team 是 31%，Business 是 9%。Business 的试用从来没走到集成那一步。我们把它挪到了第一天。
PR
P. R.
增长 · 开发者工具
以使用者视角撰写的场景示例，非真实评价。
SaaS 模板会装上什么？
13 个事件；19 个指标，含引导完成率、试用转化率、新增和流失 MRR；3 条漏斗；2 块看板：SaaS 增长、产品采用与留存。
公司怎么计数？
登录后调用 group(‘account’, tenantId)。成员的事件挂到账户上，漏斗、留存和排行都可以按公司读。一个成员可以属于多个账户。
哪些事件必须从服务端来？
subscription_started、subscription_upgraded、payment_succeeded、subscription_cancelled、trial_started 和 invite_accepted。事件表里标为「服务端」，建议从计费 webhook 上报。
什么是价值时刻？
feature_used 带着你认为是核心动作的那个 feature 键。激活漏斗和产品健康分都建在它上面。
引导需要先写埋点方案吗？
全埋点先把点击记下来，收件箱给出建议名称。在那里确认 onboarding_step 和 onboarding_complete，或者从应用里显式上报。
财务能只看 MRR、不看产品数据吗？
可以。席位可以限定只看「SaaS 增长」看板。收款金额和流失 MRR 直接来自计费事件。
开始使用
安装 SaaS 模板
建项目，在应用里加代码，登录后调用 group()，从服务端上报计费事件。第一个试用转化时增长看板就填满了。
- 13 个事件
- 19 个指标
- 3 条漏斗
- 2 块看板
含免费版。服务端 SDK 支持 Node、Python、PHP、Go。