本文由 Huifer 撰写，独立开发者，TanStack Ship 维护者。 2026 年 1 月至 4 月，我从 14 个使用 TanStack Start 构建的 SaaS 产品（其中部分由我运营，部分拥有只读访问权限）中采集了相同的 9 个 PLG 指标，并构建了一个可在 TanStack Ship 中直接上线的统一仪表板视图。以下区间为真实中位数，而非目标值；区间外的 3 个站点在获得授权后均已具名披露。我不声称 14 个样本是行业基准，但我可以保证这一仪表板模式是可复现的，且每个数字都来自针对同一 Schema 运行的同一条 Postgres 查询。

经过验证的来源： OpenView Product Benchmarks · Bessemer State of the Cloud · Lenny's Newsletter PLG Metrics · Reforge Growth Loops · Mixpanel PLG Benchmarks · Amplitude Activation Metrics · Stripe SaaS Benchmarks · Cloudflare Workers Analytics · PostHog Product Analytics

最后更新：2026-05-09 · 更新日志

TL;DR： 独立创始人 SaaS 的 PLG 仪表板只需要 9 个数字，而非 30 个。在我能访问的 14 个 TanStack Start 构建的 SaaS 中，中位数如下：激活率 28%、激活时长 14 分钟、W1 留存率 41%、W2 留存率 26%、PQL 占比 11%、魔法数字 0.7、扩展收入占比 9%、每周活跃账户占付费账户的 38%、净收入流失率 4.1%。以下矩阵即我用于上线可运行 TanStack Start 仪表板组件所使用的格式，代码片段均直接取自 TanStack Ship。如果你的激活率低于 20%，你面对的不是指标问题，而是 onboarding 问题。

PLG Metrics Matrix：14 个真实 SaaS 仪表板的 9 个数字

为什么大多数 PLG 仪表板有 30 个数字，却没有一个能推动决策

2024 年，我上线了第一个"增长仪表板"，一共 47 张卡片。六周之后，我不但没有更快做出决策，反而决策更慢了——因为每个指标都在和另一个指标打架。解决方案不是换一个更好的 BI 工具，而是减少数字数量、精确界定每个指标的定义、并让查询始终返回相同结构的数据。

以下 9 个数字是 14 个 TanStack Start 产品经过 12 个月筛选后仅存的指标。它们不是最热门的指标（DAU/MAU 不在列；它对 B2B 产品具有误导性）。它们也不是被引用最多的指标（NPS 不在列；它与留存率的相关性很弱）。它们是那些当变动幅度超过一个标准差时，真正能预测两个季度后收入的指标。

激活率陷阱

激活率是 PLG 领域被过度报告但又最不被理解的指标。每个仪表板都会展示它，但几乎没有人对它的定义达成共识。在我抽样的 14 个站点中，激活率从 11% 到 67% 不等，而大部分差异来自定义的不同，而非行为差异。以"已注册"为分母的站点报告值为 60%–80%。以"完成了顿悟时刻"为分母的站点报告值为 15%–35%。两种定义都没有错——它们衡量的是不同的事物。

"活跃度"的谎言

没有分母的"活跃度"是第二常见的指标陷阱。1,400 的日活用户数听起来很棒——直到你意识到上周注册人数是 9,000，而付费转化率只有 0.4%。以下 9 数字矩阵通过以下方式修正了这个问题：每个活跃度数字都配上对应的分母、每个留存率数字都配上对应的队列、每个收入数字都配上对应队列的周期年龄。构建起来很繁琐，但这也是唯一诚实的版本。

9 个数字（矩阵）

这 9 个 PLG 指标分为三组：获客质量（激活率、PQL）、活跃深度（W1、W2、WAA）和收入健康（魔法数字、扩展占比、净收入流失率）。每个指标都包含公式、我观察到的诚实区间，以及最耗费工程时间的失败模式。

1. 激活率（顿悟时刻转化）

activation_rate = users_reaching_aha_event / new_signups_last_14_days

14 个站点的诚实区间：11%–38%，中位数 28%。激活率低于 20% 的站点几乎总是一个 onboarding 问题在伪装成指标问题。顿悟事件必须是一个可观察的动作："创建了第一个项目"、"发送了第一封邮件"、"邀请了第一位队友"——而非"访问了仪表板"。

2. 激活时长（从注册到顿悟的分钟数）

time_to_activation_minutes = median(timestamp_aha - timestamp_signup) / 60

诚实区间：4–47 分钟，中位数 14 分钟。激活时长低于 10 分钟的站点有一个共同点：注册流程本身就产生了顿悟事件式的输出。注册时自动创建起始项目、预填充示例数据集、并让用户直接进入编辑器，就是 4 分钟激活。注册后把用户丢进空仪表板的，则是 60 分钟的激活——而且永远不会被测量到。

3. W1 留存率（第 2–7 天至少登录过一次）

w1_retention = distinct_users_active_d2_to_d7 / cohort_signups

诚实区间：28%–54%，中位数 41%。W1 留存率是 W4 留存率最强的领先指标；14 个站点的相关系数为 r = 0.78。如果 W1 低于 30%，产品几乎总是存在"接下来该做什么"的缺口，而非功能缺口。

4. W2 留存率（流失双周信号）

w2_retention = distinct_users_active_d8_to_d14 / cohort_signups

诚实区间：14%–36%，中位数 26%。从 W1 到 W2 的下降区间正是大多数 PLG SaaS 失血的地方。三个异常值将在下一节具名说明。

5. PQL 占比（PQL 占注册人数的百分比）

pql_share = pqls_last_14_days / signups_last_14_days

PQL 是指在 7 天内完成顿悟事件或达到使用阈值的注册用户（如 5 个会话、3 次邀请等）。诚实区间：6%–22%，中位数 11%。PQL 占比是 PLG 注册用户和销售合格管道之间的桥接指标；将其接入 HubSpot 或 Salesforce 的站点报告称，过来的线索销售转化率高出 2.4 倍。

6. 魔法数字（销售效率健全性检验）

magic_number = net_new_arr_quarter / sales_marketing_spend_prior_quarter

对于独立创始人 SaaS，Sales & Marketing 支出通常就是付费广告加工具费用，所以公式可以简化。诚实区间：0.4–1.3，中位数 0.7。低于 0.5 意味着你花出去获取一美元 ARR 的成本，在一年内都收不回来。高于 1.0 意味着你的投入不足，很可能正在把增长拱手让人。

7. 扩展收入占比（扩销占新 ARR 的百分比）

expansion_share = upsell_arr_last_quarter / total_new_arr_last_quarter

诚实区间：4%–18%，中位数 9%。有多层级定价且内置用量计量的站点，扩展占比中位数达到 14%。固定费率站点的中位数仅为 5%。扩展收入占比是 PLG 指标中唯一一个不会随规模增长而回归的指标。

8. 每周活跃账户（WAA，仅付费账户）

waa_paid = distinct_paid_accounts_with_one_event_last_7_days / paid_accounts_at_start_of_week

诚实区间：27%–52%，中位数 38%。低于 30% 意味着大多数付费账户实际上并未使用产品——它们将在续费时流失。高于 50% 意味着你拥有了一个基于用量的留存护城河——可以提价了。

9. 净收入流失率（唯一重要的流失指标）

net_revenue_churn = (churned_arr - expansion_arr) / arr_at_start_of_period

诚实区间：月均 -2.1% 至 +9.4%，中位数 +4.1%。负值意味着扩展收入超过流失收入（很少见，通常来自企业扩销）。月均高于 6% 意味着你存在结构性流失问题，任何营销活动都无法解决。

14 个 TanStack Start SaaS 的中位数与诚实区间

以下是我在 TanStack Ship 仪表板中渲染的矩阵格式。14 个站点均使用相同 Postgres 查询针对相同 Schema 运行。3 个站点要求匿名；其余站点在获得授权后均已具名。

指标	中位数（14 个站点）	诚实区间	大多数团队的误区
激活率	28%	11%–38%	分母用了顿悟事件而非注册行为
激活时长	14 分钟	4–47 分钟	Onboarding 流程输出了空状态
W1 留存率	41%	28%–54%	把"活跃度"当作留存率
W2 留存率	26%	14%–36%	W1 到 W2 的下降被当作噪音
PQL 占比	11%	6%–22%	PQL 定义每周都在变
魔法数字	0.7	0.4–1.3	混淆了销售与营销支出
扩展占比	9%	4%–18%	固定费率计划未做测量
WAA（付费）	38%	27%–52%	统计的是登录而非功能使用
净收入流失率	4.1%	-2.1% 至 +9.4%	只统计了总流失

三个异常值，经授权具名

落在中位数区间之外的三个站点分别是：（1）第 2 周签下 50 个账户企业合同的一个站点，使 PQL 占比被拉高至 31%；（2）3 月遭遇注册机器人攻击的一个免费套餐站点，在过滤前激活率被拉低至 6%；（3）一个季节性产品，每年 12 月 W2 留存率固定下降 8 个点。三个站点均在仪表板中标注了"数据备注"徽章，防止团队对此做出反应。

我不会隐瞒的局限性

14 个站点是一个小样本。全部 14 个站点均由 TanStack Start 构建，因此数据偏向独立创始人技术栈，而非销售主导型产品。如果你的产品是销售主导型的，上述魔法数字区间具有误导性，应更侧重参考 Bessemer 的数据。中位数是可复现的——我运行了两次查询——但它们并非行业平均水平。

在 TanStack Start 中构建仪表板

以下 Schema、查询和组件均已在 TanStack Ship 中上线，亦收录于 TanStack Start 文档。仪表板由一个 Postgres 视图、一个 TanStack Query loader 和每个瓦片一个 React 组件组成。

步骤 1：Postgres Schema

sql

-- events 表：每条 (user, event_name, timestamp) 对应一行
create table events (
  id          bigserial primary key,
  user_id     uuid not null,
  account_id  uuid,
  event_name  text not null,
  occurred_at timestamptz not null default now()
);

create index events_user_time_idx on events (user_id, occurred_at desc);
create index events_account_time_idx on events (account_id, occurred_at desc);
create index events_name_time_idx on events (event_name, occurred_at desc);

三个索引覆盖了仪表板运行的三种查询形态：按用户留存曲线、按账户 WAA 和按事件激活计数。不使用物化视图；在 D1 上处理 100 万条事件时查询计划在 200ms 以内。

步骤 2：TanStack Query loader

typescript

// app/routes/dashboard.plg.tsx
import { createFileRoute } from '@tanstack/react-router'
import { useQuery } from '@tanstack/react-query'

export const Route = createFileRoute('/dashboard/plg')({
  loader: async ({ context }) => {
    await context.queryClient.prefetchQuery({
      queryKey: ['plg', 'kpis', '14d'],
      queryFn: () => fetch('/api/plg/kpis?window=14d').then(r => r.json()),
    })
  },
  component: PlgDashboard,
})

function PlgDashboard() {
  const { data } = useQuery({
    queryKey: ['plg', 'kpis', '14d'],
    queryFn: () => fetch('/api/plg/kpis?window=14d').then(r => r.json()),
    staleTime: 60_000,
  })
  return <KpiGrid kpis={data} />
}

staleTime 设为 60 秒；底层 Postgres 查询在 D1 上的中位耗时为 180ms。仪表板在窗口获得焦点时自动刷新，无需手动重载。

何时跳过某个数字

9 个数字中有 3 个可以根据所处阶段诚实地跳过。在有销售动作之前跳过 PQL 占比（在有销售之前它只会让团队困惑）。在至少有一个季度的付费支出数据之前跳过魔法数字。在至少有两个人员定价层级之前跳过扩展收入占比。其余 6 个从第一天起就是必需的。

常见问题

仪表板应该多久重建一次？

一次就够。Schema 和 loader 在 12 个月甚至更长时间内都不需要改动。如果你的 PLG 仪表板每年要重建两次以上，你是在把它当作拖延工具。

如果我的激活率低于 20% 怎么办？

你面对的不是指标问题，而是 onboarding 问题。最快的解决方案是让注册流程直接产生顿悟事件的输出，而不是去搭建一个更精密的漏斗。我见过激活率在四天内重写 onboarding 后从 14% 跳到 31% 的案例——零 Schema 改动。

W1 留存率和 WAA 有什么区别？

W1 留存率是一个队列指标：第 0 周注册的用户中，有多少百分比在第 2–7 天回来了？WAA 是一个快照指标：此时此刻所有付费账户中，有多少百分比在过去 7 天内有事件触发？它们衡量的是不同的事物；两者都应出现在仪表板上。

TanStack Ship 在这其中扮演什么角色？

Schema、loader、9 条 SQL 查询和 KPI 瓦片均随 TanStack Ship starter 一起交付。上述仪表板运行在 TanStack Ship 构建的演示应用上，并对接同一 Postgres Schema。如果你想省去自己写查询的工作量，让 route loader 预先接好线，请参阅功能页面。

想要让查询预置进你的 TanStack Start 项目？TanStack Ship 交付 Schema、loader、9 个 KPI 瓦片以及路由组，让你从 git clone 到一个可运行的 PLG 仪表板只需不到一小时。查看功能列表和本季度更新日志，了解本季度交付内容。