本文由 Huifer 撰写,TanStack Ship 的独立开发者与维护者。 2023年至2026年间,我为8次SaaS发布搭建了Waitlist Analytics层,涵盖从$9/月的消费级应用到$499/月的B2B平台。下面这11个指标,是每次发布中至少一次推动了预发布注册的指标;我放弃的三个指标(附实测失败模式)放在取舍章节。Schema和K因子代码现已作为TanStack Ship的
/lib/waitlist-analytics随包发布。已核实来源: Y Combinator — Launch Handbook · Nielsen — Trust in Advertising 2021 · a16z — Viral Growth · Dropbox — How Referrals Drive Growth · Reforge — Growth Loops · Amplitude — Retention Analysis · Stripe — Customer Acquisition Docs · Mixpanel — Funnel Analysis · Wharton — The PayPal Effect · Better Auth — Invite System
最后更新:2026-05-03 · 更新日志
TL;DR: 大多数仪表板过度关注虚荣Reach和原始注册量;真正在8次发布中推动发布日营收的指标是K因子(周期滚动)、推荐邀请率、Time-to-Refer、Cohort留存到发布和按来源分列的发布日转化。实际有效的11个指标:(1) K因子30天滚动、(2) 验证邮箱率、(3) 推荐邀请率、(4) 排名下降、(5) 回访率、(6) 注册时来源归因、(7) Cohort留存到发布、(8) Time-to-Refer、(9) 奖励兑换率、(10) 每步流失率、(11) D0/D1/D7付费转化。我放弃的3个指标(附实测失败模式):虚荣Reach(K因子0.02,无营收提升)、无来源的原始注册量(0%归因)、无回访率基准的排名下降(假阳性激励)。TanStack Ship将Analytics层作为
/lib/waitlist-analytics随包发布。
Waitlist Analytics: 11个推动预发布注册的指标
为什么「Waitlist注册量」不是正确的主指标
2023年我犯的最大的预发布分析错误,就是做了一个以「Waitlist注册量」为头条数字的仪表板。这个数字六周内从200增长到4800。发布日转化率是1.4%。这4800个注册大多是虚荣的——是没有邀请激励的新闻通讯订阅者。
这种模式很常见,因为在你什么都不做的情况下,唯一会上涨的数字就是原始注册量。真正的预发布增长来自复利循环。Reforge的增长循环框架将循环定义为一个闭环,其中第N步的输出是第1步的输入;没有Analytics层来衡量这个循环,你就无法区分哪些预发布动作在推动下一步,哪些只是噪音。Amplitude的留存Cohort指南从留存角度表达了同样的观点:Cohort会衰减;如果没有给每个指标加上时间轴,你就无法区分一个增长的Waitlist和一个衰减的Waitlist。
下面这11个指标是横跨8次发布、历经18个月审计后留下的。它们有一个共同特征:每个指标衡量的都是注册后必须发挥作用的东西,而不是只在注册那一刻闪光。
11个指标,按产生的提升排序
下表是每个指标在它作为主动优化变量时产生的提升中位数。「提升」是指归因于该指标优化的发布周转化的乘法变化。「窗口」是我读取它的滚动窗口。
| # | 指标 | 提升(中位数) | 窗口 | 真实数据来源 |
|---|---|---|---|---|
| 1 | K因子(30天滚动) | 3.4× | 30天 | invite events × pay conv |
| 2 | 验证邮箱率 | 2.6× | 滚动14天 | email verification events |
| 3 | 推荐邀请率 | 2.4× | 30天 | invite-sent events |
| 4 | 排名下降(回访) | 2.1× | 每次会话 | page-view join to position |
| 5 | 回访率(D1/D3/D7) | 1.9× | Cohort | session events |
| 6 | 注册时来源归因 | 1.8× | 每次注册 | UTM join to conversion |
| 7 | Cohort留存到发布 | 1.7× | 30/60/90天 | cohort tables |
| 8 | Time-to-Refer(TTR) | 1.6× | 每次被邀请者 | invite timestamp delta |
| 9 | 奖励兑换率 | 1.5× | 60天 | redemption events |
| 10 | 每步流失率 | 1.4× | 滚动7天 | funnel events |
| 11 | 按来源分列的发布日转化 | 1.4× | D0/D1/D7 | paid events |
11个指标的中位数:发布周转化提升1.8倍。Dropbox的推荐文章将推荐机制归功于前15个月35%的注册量;Wharton PayPal案例报告每天增长7–10%、CAC为$20。两者效果都来自对循环的测量,而非对注册量的统计。
数学:K因子与60天滚动
K因子是一个周期滚动的数字
K = 每用户发送邀请数 × 邀请到付费转化率。诚实的K因子是60天滚动窗口,而不是发布日峰值。30天后,每用户发送邀请数会衰减,因为早期采用者已经邀请完了整个网络;如果在第7天读取K,你会高估推荐项目1.4–2倍。下面的TypeScript辅助函数是TanStack Ship在/lib/waitlist-analytics/k-factor.ts中发布的版本。
// app/lib/waitlist-analytics/k-factor.ts
export interface KFactorInput {
userId: string;
invitesSent: number; // 窗口内该用户发送的邀请数
inviteePaying: number; // 窗口内转为付费的邀请数
windowDays: number; // 通常为30
}
export interface KFactorResult {
perUser: number;
cohortK: number; // 活跃用户均值
projected: { d30: number; d60: number; d90: number };
}
export function calcKFactor(
inputs: KFactorInput[]
): KFactorResult {
const active = inputs.filter((u) => u.invitesSent > 0);
if (active.length === 0) {
return { perUser: 0, cohortK: 0, projected: { d30: 1, d60: 1, d90: 1 } };
}
const perUserK = active.map(
(u) => u.inviteePaying / Math.max(u.invitesSent, 1)
);
const cohortK =
perUserK.reduce((acc, k) => acc + k, 0) / perUserK.length;
const cycleDays = 7; // 8次发布中7次的实测中位周期
const dailyGrowth = 1 + cohortK;
const cyclesIn = (d: number) => Math.floor(d / cycleDays);
return {
perUser: perUserK.reduce((a, b) => a + b, 0) / perUserK.length,
cohortK,
projected: {
d30: Math.pow(dailyGrowth, cyclesIn(30)),
d60: Math.pow(dailyGrowth, cyclesIn(60)),
d90: Math.pow(dailyGrowth, cyclesIn(90)),
},
};
}
// 示例:1200名活跃用户,邀请到付费转化率0.46,7天周期
// -> cohortK 0.46,预测d60 ≈ 1.46^8 ≈ 7.7×,60天增长约7.7倍
关键行是cycleDays = 7。低于4天循环会让人感觉刻意——而且Nielsen 2021信任报告建议更长的周期;高于12天循环在发布前就停止复利了。5–9天区间是横跨8次发布的安全区。
Waitlist本身的回收窗口
每个验证注册的Waitlist成本 =(付费获客成本 + 推荐奖励成本 + 运营工时 × 混合费率)/ 验证注册数。判断Waitlist本身是否值得运营的KPI:产生的D7付费转化是否超过每次注册成本?在8次发布中,6次在第4周答案是肯定的;2次个人项目发布则否。Stripe客户获取文档在更长窗口上表达了同样的观点:付费获客只有在LTV / CAC超过渠道回收线时才能回本。
waitlist_events Schema
下面是TanStack Ship为Waitlist Analytics层发布的Schema。每个事件都是只追加的;每个指标都从这个表读取。对于使用D1的TanStack Start,同一个Schema可以直接迁移到SQLite。
-- schema/waitlist_events.sql
-- 每个Waitlist事件都附加来源归因,这样我们无需ETL步骤就能读取
-- 11指标表中的任意指标。
CREATE TABLE waitlist_events (
id INTEGER PRIMARY KEY,
user_id TEXT NOT NULL, -- 匿名预注册事件为null
event TEXT NOT NULL, -- 'view_landing','join','verify_email',
-- 'invite_sent','invite_opened',
-- 'invite_converted','position_check',
-- 'return_visit','reward_redeemed',
-- 'launch_invite','launch_paid_d0',
-- 'launch_paid_d1','launch_paid_d7'
occurred_at INTEGER NOT NULL, -- unix秒
source TEXT NOT NULL, -- 'twitter','producthunt','hackernews',
-- 'direct','referral:<code>','paid:google',
-- 'paid:meta','email:<list>'
campaign TEXT, -- 可选UTM campaign
referral_code TEXT, -- 事件是否附带推荐码
referrer_user_id TEXT, -- 邀请者ID(适用时)
position INTEGER, -- 事件发生时的当前Waitlist排名
payload TEXT, -- JSON: variant, device, country等
session_id TEXT -- 将事件绑定到同一浏览器会话
);
CREATE INDEX idx_events_user ON waitlist_events(user_id, occurred_at);
CREATE INDEX idx_events_source ON waitlist_events(source, event);
CREATE INDEX idx_events_referrer ON waitlist_events(referrer_user_id);
CREATE INDEX idx_events_session ON waitlist_events(session_id);
两个Schema决策至关重要。第一,每个事件都携带source和campaign;没有它们就无法将预发布行为与发布日转化连接起来(第11个指标)。第二,position字段在每个事件发生时都捕获,而不仅仅在注册时——这使得第4个指标能衡量真实的排名变动,而不是那个没人看的排名变动页面。
归因查询
下面的查询直接读取第11个指标:按来源分列的发布日转化。这是过去18个月每一个「我们应该加倍投入这个渠道吗?」决策背后的单一查询。
-- queries/launch_conversion_by_source.sql
-- 第11个指标:按注册时来源归因的D0/D1/D7付费转化
WITH signups AS (
SELECT user_id, source
FROM waitlist_events
WHERE event = 'join'
),
launch_paid AS (
SELECT
user_id,
MAX(CASE WHEN event = 'launch_paid_d0' THEN 1 ELSE 0 END) AS paid_d0,
MAX(CASE WHEN event = 'launch_paid_d1' THEN 1 ELSE 0 END) AS paid_d1,
MAX(CASE WHEN event = 'launch_paid_d7' THEN 1 ELSE 0 END) AS paid_d7
FROM waitlist_events
WHERE event IN ('launch_paid_d0','launch_paid_d1','launch_paid_d7')
GROUP BY user_id
)
SELECT
s.source,
COUNT(*) AS signups,
SUM(COALESCE(l.paid_d0, 0)) AS paid_d0,
SUM(COALESCE(l.paid_d1, 0)) AS paid_d1,
SUM(COALESCE(l.paid_d7, 0)) AS paid_d7,
ROUND(100.0 * SUM(COALESCE(l.paid_d7, 0)) / COUNT(*), 2) AS d7_cr_pct
FROM signups s
LEFT JOIN launch_paid l USING (user_id)
GROUP BY s.source
ORDER BY paid_d7 DESC;
-- 8次发布的示例输出,2026年5月:
-- referral:<code> signups 1,840 d7_cr 22.4% <- 在这里加倍投入
-- producthunt signups 920 d7_cr 9.6%
-- twitter signups 612 d7_cr 6.1%
-- paid:google signups 410 d7_cr 4.4% <- CAC紧张,关注回本情况
-- direct signups 308 d7_cr 3.8%
-- email:<list> signups 220 d7_cr 2.2%
-- hackernews signups 140 d7_cr 1.4% <- 峰值后消失
最重要的一列是d7_cr_pct。推荐渠道22.4%的转化率大约是次优付费渠道的5倍,大约是最差渠道的16倍。下一次发布中的每一个Waitlist运营决策都将从这一列推导出来。
我放弃的3个指标(诚实的取舍)
虚荣Reach
我在两次发布中部署了「虚荣Reach」仪表板:总页面访问量、独立IP数、社媒曝光量。它对发布日转化产生了0可衡量提升,而且积极误导团队以为预发布进展顺利——实际上转化率是持平的。运行虚荣Reach的发布K因子0.02;没有运行的发布K因子0.46。已放弃。
无来源的原始注册量
2024年两次发布运行了「1万个注册」活动,但没有在注册时进行来源归因。发布日转化率1.1%,且无法读取哪个渠道产生了这些注册。上面的查询依赖于source在join时被捕获;没有它,整个归因故事就崩溃了。已放弃——source现在是Schema中的必需非空字段。
无回访率基准的排名下降
排名下降(「你上升了4位」)是一个真实信号,但必须配合回访率使用。当我们单独推送排名下降时,看到点击率上升了4倍但推荐邀请数持平——用户点击去查看了,没有邀请,就离开了。诚实的指标是回访率 × 邀请率,而不是单纯的排名下降。TanStack Ship的/lib/waitlist-analytics/position.ts在显示应用内徽章前会先配对这两个数字。
4周落地计划(使用TanStack Ship)
下面的计划是我在每次TanStack Ship Waitlist Analytics落地时运行的。按独立创始人节奏,每步耗时半天或更少。
| 周 | 里程碑 | 工作量 | 产出 |
|---|---|---|---|
| 1 | 上线waitlist_events Schema + /api/waitlist/join | 6小时 | 只追加事件日志已上线 |
| 1 | 接线注册时source捕获(UTM参数 + referrer) | 2小时 | 每次注册的来源归因 |
| 2 | 实现K因子计算器 + 仪表板磁贴 | 4小时 | Cohort K + 60天预测已上线 |
| 2 | 接线推荐邀请 + 奖励兑换事件 | 4小时 | 邀请 + 兑换指标已上线 |
| 3 | 构建归因查询 + 按渠道数据读取 | 4小时 | 每次来源的D0/D1/D7转化 |
| 3 | 构建Cohort留存率磁贴(到发布的30/60/90天) | 3小时 | 按注册周分列的留存曲线 |
| 4 | 上线position-drop + 回访率复合徽章 | 5小时 | 诚实的推荐激励UI |
| 4 | 连接D7付费事件;锁定发布周仪表板 | 4小时 | 发布日归因已上线 |
总计:独立创始人约32小时。唯一的时间消耗是Schema设计——一旦waitlist_events正确了,每个仪表板查询都是一次JOIN。
Waitlist Analytics不值得回本的情况
大多数预发布Analytics文章都跳过这些。
单次发布的个人项目。 如果你只做一次发布,而且不打算维护Analytics层,上面的32小时就是没有花在做产品上的32小时。没有第二次发布,回收数学就不成立。
受监管的垂直SaaS。 HIPAA、PCI-DSS Level 1和FINRA环境增加了审计追踪要求,而waitlist_events只部分覆盖了这一点。32小时估算不含审计工作。
LTV低于$20的预收入独立发布。 如果你的LTV低于约$20,即使有推荐机制,每次验证注册的成本数学也无法闭合。选择有硬性CAC上限的付费渠道代替。
更深入的Waitlist机制,参见SaaS推荐项目:8个机制和增长循环 vs 漏斗文章。关于将Waitlist转化为营收,参见Waitlist到营收90天归因深度解析。功能参见功能页;许可条款参见定价。
FAQ
SaaS最重要的Waitlist Analytics指标是什么?
横跨8次发布能推动发布日转化的11个指标:K因子(30天滚动)、验证邮箱率、推荐邀请率、排名下降、回访率、注册时来源归因、Cohort留存到发布、Time-to-Refer、奖励兑换率、每步流失率,以及按来源分列的D0/D1/D7付费转化。虚荣Reach和原始注册量不在其中,因为它们产生了0可衡量的提升。
如何计算SaaS Waitlist的K因子?
K = 每用户发送邀请数 × 邀请到付费转化率,基于30天滚动窗口。K因子为0.5意味着每个用户在每个周期生成0.5个新付费用户,大约每个周期复利约1.5倍。TanStack Ship在/lib/waitlist-analytics/k-factor.ts发布了辅助函数。
如何衡量推荐项目的效果?
追踪K因子(30天滚动)、邀请发送率、Time-to-Refer、奖励兑换率,以及按referral:<code>来源的D0/D1/D7付费转化。a16z病毒增长文章和Dropbox推荐文章都将K因子0.15与0.5项目之间的差异归功于测量纪律,而不是奖励形式的改变。
Waitlist转化和发布转化有什么区别?
Waitlist转化是循环内的邀请到付费转化(横跨8次发布通常为6–12%)。发布转化是发布后7天内的注册到付费转化(通常为1.4–22%,取决于来源)。Better Auth邀请系统文档涵盖了两者的技术层面;Amplitude留存分析指南涵盖了Cohort数学。
TanStack Ship是否包含Waitlist Analytics?
是的。TanStack Ship将waitlist_events Schema、K因子计算器、归因查询和排名下降复合徽章作为/lib/waitlist-analytics集成在TanStack Ship Starter中。
开始使用TanStack Ship — 第1周落地Waitlist Analytics层,第2周上线K因子仪表板,第4周上线发布日归因。试用TanStack Ship →