基于同期群的收入建模:为什么混合式 SaaS 预测会掩盖真实故事

董事会问，为什么本季度净收入留存率下降了三个百分点。诚实的答案需要知道哪些客户流失了，哪些客户缩减了合约，哪些客户扩大了合约，以及每一位客户是何时开始订阅的。一个混合式的收入数字回答不了这个问题，它只能报告这个数字变动了。

这正是大多数 SaaS 预测方法的核心局限:它把整个客户群当作一个池子来处理。总新增 MRR 进入，总流失 MRR 离开，报告净变动值。基于同期群的收入建模则把这个池子按注册月份(或季度)拆分开，分别追踪每个同期群各自的留存与扩展曲线。这并不是一个新指标，而是一种不同的分析单位，它改变了一份预测能够解释什么。

混合式预测究竟掩盖了什么

单一的净 MRR 变动数字，是若干相互抵消的效应之和。假设上月净新增 MRR 增长了 4%,这可能意味着健康客户群中的温和扩展，也可能意味着 18 个月前注册的某个同期群正在剧烈流失，而这一点被一个仍处于蜜月期、续约风险尚未显现的大型新同期群所掩盖。两种情形会产生完全相同的总体数字，却指向截然相反的行动。

这一点对董事会真正关心的指标影响最大:净收入留存率。NRR 本身就是一个同期群概念，它问的是期初已存在的客户(不含新客户)的收入发生了什么。要正确计算它，本身就需要按同期群拆分。报告它却不展示背后的同期群曲线，等于丢掉了具有解释力的部分，只保留了头条数字。

实际的失败模式出现在预测中，而不只是报告中。一个用混合历史流失率训练出来的模型，会向前统一套用一个混合流失率，不区分客户在库时长。但流失率很少按在库时长均匀分布，第一年的流失和第三年的流失通常属于不同的机制，由不同的原因驱动(入职失败，还是真正触及了产品市场契合度的天花板)。看不到这种差异的预测，系统性地会算错一个大型新同期群加入客户群所带来的影响。

基于同期群的建模如何运作

一旦数据结构搭建正确，机制其实很直接。按注册周期对客户分组，大多数 B2B SaaS 以月度同期群为标准，但交易量密集的业务模式有时会用周度同期群。对每个同期群，追踪其在后续每个周期相对于初始值的 MRR(或 ARR),从而形成一条留存曲线:第 0 月为 100%,此后每个月净流失与扩展相抵后的存续比例。

同期群	第 0 月	第 6 月	第 12 月	第 18 月
1 月同期群	$50,000	$47,500(95%)	$44,000(88%)	$46,500(93%)
4 月同期群	$62,000	$59,800(96%)	$57,000(92%)	无数据
7 月同期群	$71,000	$68,300(96%)	无数据	无数据

真正重要的是每条曲线的形状，而不是曲线上的某一个点。一个先跌破 100% 再回升的同期群(经过早期调整期后，扩展速度超过了流失速度),讲述的故事与一个持续下滑的同期群完全不同。把足够多的同期群叠加在一起，就能看出这家企业的留存状况是随着一批批新客户逐月改善(较新的同期群曲线比较早的同期群更平缓),还是在恶化，而后者是混合式 NRR 数字只会在事情已经发生之后才反映出来的。

从这种结构出发进行预测，意味着以更成熟、更早期同期群观察到的曲线形状作为先验，把每个同期群的曲线向前推演，再把所有同期群加总(包括尚未注册、由销售管道或订单假设驱动的未来同期群),得到总预测收入。这与对上一期总数套用一个混合增长率相比，是一种在实质上不同、也更站得住脚的方法。

这套方法在实践中会在哪里失效

同期群建模是一项已经广为人知的技术。大多数尝试过它的 FP&A 团队，也都撞上了同一堵墙:同期群数据存在于账务台账之外的某个地方。

它通常始于一个 BI 工具或手工搭建的电子表格，数据来自定期从账务系统导出的客户级 MRR 快照。这份导出即是一次分叉。它一旦存在，就开始产生偏差:一次套餐变更在导出运行之后才在账务系统中处理完成，一位客户从一个细分类别被重新归类到另一个，一次退款追溯调整了某个月份的数据。电子表格里的同期群曲线和台账中的实际收入会悄悄开始不一致，直到某位审计员或新入职的 FP&A 员工试图对二者进行核对，却对不上账为止，这才有人注意到。

这与任何一个衍生分析层与系统记录来源分开维护的地方所出现的失败模式如出一辙:单独看时一切正常，一旦有人要求它对得上账，就会失效。同期群收入建模尤其容易受此影响，因为这项技术的全部价值就在于精确性，即准确知道某次流失事件属于哪个同期群。一份存在两周滞后或需要人工重新分类步骤的分析导出，恰恰会破坏同期群分析本应交付的那一件事。

让同期群与已对账的台账相绑定

解决方案不是一份更好的电子表格模板，甚至也不是把同期群模型继续单独维护下去。流失事件、扩展事件和新客户事件，需要被打上标签，并与生成其余财务模型的同一份已对账订阅台账(即已经与账务系统和总账对齐的那一份)进行关联追踪。当某位客户的 MRR 发生变化时，这个变化是一个事实，只记录一次，而计算损益表总收入的环节和计算董事会材料所需同期群曲线的环节，使用的都是同一个事实。不存在会产生偏差的第二份副本。

具体来说，这意味着:

• 同期群归属(注册周期)是已对账模型中客户记录本身的一个属性，而不是后期在电子表格里添加的一列。
• 流失事件和扩展事件在数据源头只分类一次，混合式 NRR 数字和同期群拆分结果都由同一个事件流计算得出。
• 第 12 月的同期群曲线加总起来，应始终等于损益表对该期间报告的同一个 MRR 总数，如果对不上，那是需要修复的对账断点，而不是可以忽略的舍入误差。

这也正是 AI 真正能提供帮助、同时也需要与模型其他环节相同护栏的地方:它可以检索出正确的同期群切片，并叙述曲线为何呈现出那样的走势(定价调整、支持事件、竞争对手发布新品),但它不应该自己去计算留存百分比。这些数字来自对台账的确定性计算。AI 的职责是解释一个本已正确的数字，而不是生产这个数字。

结论

一个混合式的 SaaS 收入数字告诉你发生了什么。一个建立在与其余一切共用同一份台账数据基础之上的同期群模型，则告诉你为什么，并让你能够基于一条真实观察到的曲线向前预测，而不是基于一个被平均到失去意义的比率。这项技术本身并不新。真正让它失效的，几乎总是与破坏其他任何 FP&A 工作流程相同的那件事:一份未经对账、悄悄与第一份数据不再一致的第二份副本。

如果你的同期群曲线和你报告的 NRR 维护在不同的地方，那道缺口值得在董事会下一次问起留存问题之前补上。预约演示,了解 Rexfin 如何把同期群、NRR 和 ARR 报告统一维护在同一份已对账订阅台账之上。

关于此类模型需要可靠计算的更广泛一组 SaaS 指标，参见 AI 能可靠计算的 SaaS 指标。关于底层 ARR 数字如何生成与报告，参见 SaaS ARR 报告。关于 NRR 的精确定义，参见净收入留存率术语表条目。关于这如何融入常规的 FP&A 节奏,季末快报介绍了同一时间表下需要审阅的内容。