数据有限时如何计算LTV
想算出有用的LTV，并不需要多年的客户历史数据。下面介绍不同阶段适用的公式，以及你需要明确说明的假设。
早期团队跳过LTV计算，最常见的原因是觉得手头数据不够。这几乎总是错误的判断。基于十二个月客户数据和明确假设得出的LTV估算，远比完全没有估算有用——因为它会迫使你认真思考留存，让你的假设摆在明面上、可以被质疑，同时也给你一个随着数据增多不断修正的数字。
早期阶段的目标不是精确的LTV，而是方向正确、假设有据可查的LTV。精度会随时间逐步提高，而计算LTV的习惯，从第一天就应该建立。
两个公式
平均生命周期 = 1 ÷ 0.03 = 33个月。
LTV = $60 × 0.75 × 33 = $1,485
LTV = $45 × (0.82 + 0.71 + 0.64 + 0.59 + 0.55…) 加总到你的预期范围。
在24个月处：LTV ≈ $45 × 17.4个月有效 ≈ $783
基于明确假设的LTV估算，远比没有LTV更有用。改变团队决策方式的，是计算LTV这一习惯本身，而不是结果有多精确。
左右结果的三个假设
客户流失率。 这是任何LTV计算中最敏感的输入。月流失率从3%升到5%，平均客户生命周期就从33个月缩短到20个月——LTV下降40%。数据有限时，按乐观、中性、悲观三种流失率假设分别建模，呈现一个区间，而不是单一数字。这样可以避免一个常见错误：被一个只基于两个月数据推算出来的数字牵着走。
毛利率。 对于交付成本不低的企业来说，用营收而不是毛利来算，会明显高估LTV。毛利率80%的SaaS企业和毛利率40%的服务型企业，即使营收完全相同，经济模型也大不一样。如果你的毛利率低于50%，你的LTV会比按营收算出的结果低得多——你能承受的CAC也相应更低。
时间范围。 严格来说，LTV是一位客户未来所有毛利折现后的总和。实际中，大多数团队会把LTV的计算期限定在三到五年以内，因为更远的预测带来的不确定性多于洞察。请明确说明你采用的时间范围。同一位客户，按24个月算出的LTV和按60个月算出的LTV可能相差三到五倍——而两者在技术上都是“正确”的。
在以下情形使用简易LTV：客户历史不足十八个月、只需快速得出一个方向性的数字，或者受众（投资人、管理层）需要一个能快速验算的数字。在以下情形使用预测型LTV：你已有足够的同期群数据，能看出留存曲线究竟何时趋于平缓（通常需要十八个月之后），并且要就CAC上限或回收期目标做精确决策。如果留存曲线并不会趋于平缓（也就是说，客户会一直以恒定速率流失，而不是稳定下来），简易公式会高估LTV。
真正用于决策的数字
LTV本身并不能直接指导行动。真正用于决策的，是LTV:CAC比值和回收期。如果你的简易LTV是$1,485，CAC是$400，那么LTV:CAC就是3.7:1——很健康。回收期等于CAC除以每位客户的月毛利：$400÷($60×0.75)=$400÷$45≈9个月——非常出色。
随着ARPU、流失率和CAC的变化，这两个数字应当每季度重新计算一次。趋势与当前数值同样重要：六个月内从2:1提升到3:1的比值，和从5:1下滑到3:1的比值，讲述的是截然不同的故事。
如果你的客户会随时间升级——从低档套餐升到高档、增加席位、购买附加功能——那么简易LTV公式会低估客户的真实价值，因为获客时的ARPU低于第18个月的ARPU。可以用整个客户生命周期内的平均ARPU代替获客时的ARPU来调整，或者单独增加一个“扩展收入”项。净收入留存率很高（超过110%）的企业，如果使用固定的ARPU假设，会大幅低估LTV。
LTV的计算需要来自业务多个环节的输入——财务提供的营收数据、产品或客户成功团队提供的流失数据、运营提供的毛利数据。在FabricLoop中，每季度复盘LTV的团队，常常会用一篇共享的群组笔记，把输入数据、计算过程、假设，以及得出的LTV:CAC比值，连同上一季度的数字一并记录下来。当假设和结果记录在同一个地方，“我们当时用的是哪个流失率？”这种三个月后的争论就不会发生。计算过程变得可审计、可改进，而不是每次有人重算就结果不同的黑箱。