数据有限时如何计算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计算中最敏感的输入。从3%到5%月流失率的转变将平均客户生命周期从33个月减少到20个月——LTV减少40%。当你有有限的数据时，在三个流失假设（乐观、中心、悲观）上建模LTV，并呈现范围而不是单一数字。这防止基于两个月数据推导出的数字的常见错误。
总利润率。 使用收入而不是总利润对拥有有意义交付成本的业务显著高估LTV。一个80%总利润率的SaaS业务和一个40%总利润率但收入相同的服务业务有非常不同的经济学。如果你的总利润率低于50%，你的LTV比基于收入的计算表示的要低得多——你的CAC容忍相应地更低。
时间范围。 LTV技术上是来自一个客户的所有未来总利润的总和，折扣到现在值。实际上，大多数团队将他们的LTV上限设在三到五年范围，因为超过那个的投影引入比洞察力更多的不确定性。明确你的范围。在24个月内计算的LTV和在60个月内计算的同一个客户的LTV可以相差三到五倍——两者在技术上都是"正确的。"
当你有少于18个月的客户历史、当你做一个快速方向计算或当你的受众（投资者、领导力）需要一个他们可以快速理性检查的数字时，使用简单LTV。当你有足够的群组数据来看你的保留曲线实际上如何变平——通常在18个月后——以及当你做关于CAC上限或回收期目标的精确决定时，使用预测LTV。简单公式将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的3:1比率非常不同的故事。
如果你的客户随时间升级——从较低到较高的层级移动、添加席位、购买附加功能——你的简单LTV公式低估了客户的真正价值，因为获取时的ARPU低于第18个月的ARPU。通过在客户生命周期中使用平均ARPU而不是获取ARPU进行调整，或添加单独的"扩展收入"项。拥有强大净收入保留（110%以上）的业务如果他们使用静态ARPU假设，将显著低估LTV。
LTV计算需要来自业务多个部分的输入——来自财务的收入数据、来自产品或CS的流失数据、来自运营的总利润数据。在FabricLoop中，做季度LTV审查的团队经常使用一个共享组笔记，捕获输入、计算、假设和结果LTV:CAC比，旁边的上一季度数据。当假设在与输出相同的地方被记录时，"我们使用了哪个流失率？"对话不会在三个月后发生。计算变成可审计和可改进的，而不是每次有人重新计算时改变的黑箱。