Waitlist Analytics: 11个推动预发布注册的指标

跨越8次发布的11个SaaS Waitlist Analytics指标。K因子计算、仪表板搭建、诚实取舍——尽在TanStack Ship →

Huifer
Huifer
May 3, 202612 min read
其他语言:Deutsch · English

本文由 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个指标,按产生的提升排序

下表是每个指标在它作为主动优化变量时产生的提升中位数。「提升」是指归因于该指标优化的发布周转化的乘法变化。「窗口」是我读取它的滚动窗口。

#指标提升(中位数)窗口真实数据来源
1K因子(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×Cohortsession events
6注册时来源归因1.8×每次注册UTM join to conversion
7Cohort留存到发布1.7×30/60/90天cohort tables
8Time-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/D7paid 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中发布的版本。

typescript
// 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。

sql
-- 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个月每一个「我们应该加倍投入这个渠道吗?」决策背后的单一查询。

sql
-- 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/join6小时只追加事件日志已上线
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 →