惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

量子位
Stack Overflow Blog
Stack Overflow Blog
人人都是产品经理
人人都是产品经理
The GitHub Blog
The GitHub Blog
Engineering at Meta
Engineering at Meta
Vercel News
Vercel News
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Y
Y Combinator Blog
The Cloudflare Blog
Last Week in AI
Last Week in AI
B
Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
T
Tailwind CSS Blog
V
Visual Studio Blog
博客园 - 三生石上(FineUI控件)
小众软件
小众软件
Google DeepMind News
Google DeepMind News
D
DataBreaches.Net
博客园 - 司徒正美
B
Blog RSS Feed
Microsoft Azure Blog
Microsoft Azure Blog
罗磊的独立博客
Hugging Face - Blog
Hugging Face - Blog
L
LangChain Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
以SAAS产品为切入点,对LTV统计若干问题的总结
郑春雨 · 2025-06-05 · via 人人都是产品经理

客户生命周期价值(LTV)是衡量SaaS产品商业模式健康和可持续性的核心指标。本文以订阅制SaaS产品为切入点,详细探讨了LTV的统计方法、实践要点以及多维度分析的重要性。

文章背景为,假定某订阅制SAAS产品,付费模式为月、季度、年三档。项目已经历市场相对空白到竞品围剿的多重阶段。

针对客户生命周期价值(LTV)问题做了讨论,经整理成文,文章是一个思考的过程,对大家可能无法形成理论性指导,但作为开拓思路之用还算尚可。

订阅制的SAAS类产品LTV的统计方式

首先来说,客户生命周期价值(LTV)对SAAS类产品而言,是其商业模式健康和可持续的核心指标,但LTV的统计,是一个复杂的、需要多部门深度协同的工程。

一、基于SAAS产品的LTV计算方法

统计LTV的核心目的是预测客户在整个生命周期内,为公司带来的净收入。比较常用的方法是基于现金流的预测,这似乎更贴近SAAS产品的特点。

核心计算公式是:LTV=(平均每月经常性收入)*毛利率%*平均客户生命周期(月)

其中对平均每月经常性收入的计算,比较推荐的是按按客户群/层级计算(例如按获客月份、按套餐等级、按客户规模分组),分组计算LTV会更有意义。

毛利率方面,一般来说毛利率=(收入-直接服务该客户的可变成本)/收入*100%。不过对于软件类产品来说,会存在一些可变成本,比如服务器等基础设施,可以按照用户使用量分摊。比较麻烦的是客户的支持成本,这大部分是人的成本,很难准确分隔,只能按照可归属部分做大致分摊。

这里面是不包括研发成本、一般管理成本(比如非一线岗位人员的成本等)等这些固定成本的,这里的LTV更看重客户带来的毛利润贡献。

比较难预测的部分是平均客户生命周期,通常的做法是:平均客户生命周期(月)≈1/月客户流失率。其中月客户流失率=该月内流失的客户总数/月初客户总数*100%。当然,流失率还是应该尽量按照客户群来计算,因为新老客户、不同套餐的客户流失率差异可能非常大,不做分组的计算,会导致数据异常高或异常低,干扰最后的判断。

二、LTV的统计实践

统计的实践主要涉及两个问题,一个是数据的梳理整合,一个是统计的要点。

2.1、数据的来源和梳理整合

CRM(如Salesforce):客户基本信息、合同价值、订阅开始/结束日期、增购/降级/流失记录。

订阅/计费系统:精确的MRR、ARR、交易流水、续约状态、退款记录。这是收入数据的核心来源。

产品分析工具:用户行为数据(活跃度、功能使用深度),这些是预测流失和增购潜力的重要指标。

财务系统:成本数据(服务器费用、支付手续费、客户成功/支持成本分摊)。

客户支持系统:支持工单量/类型/解决时间、客户健康度评分。

2.2、统计的要点

客户分组:按获客时间、获客渠道、初始套餐、客户规模、行业等进行分组统计。过于追求平均的LTV数据价值并不大。

区分毛流失与净扩张:计算流失率时,区分客户数量流失和收入流失,并明确NRR的计算。

处理可变合同:对于用量计费或合同价值波动大的客户,MRR的计算需要更精细(如滚动平均)。

成本分摊:建立清晰、一致、可审计的规则来分摊可变成本到客户或客户群。避免过度复杂化,但也要保证合理性。

1、LTV是一个需要多部门高度协同的战略动作

其实统计LTV也好,统计其他维度的数据也好,很多人都有这个观念,但最后的实施之路往往一波三折,导致最后无疾而终。这是一个需要从上至下的、多部门高度协同调配的工作。其关键点在于:

统一数据口径:所有部门对“客户”、“MRR”、“流失”、“增购”、“成本分摊”等关键概念的定义达成一致,如果一个数据存在多种解释方法,那最后的结果必然失真。

绝对的单一事实来源:源数据一定确保一致,保证各部门看到的是基于同一套源数据得出的计算结果。

清晰的流程与责任:明确各部门在数据录入、清洗、计算、报告和应用各环节的责任和流程。

定期沟通:建立跨部门例会,共享结论和猜想,讨论数据异常,共同制定优化策略。

将LTV融入决策:单纯停留在数据层面的统计毫无意义,要么放弃LTV统计,要么融入并干预决策。

领导层支持:很简单,皇上不急太监急的事普遍干不成。

LTV统计的维度问题

问题背景是探讨LTV应该是针对某一个具体客户,还是某一个渠道客户,还是针对某一个时间段内的客户来进行。综合来看,LTV的统计意义并不是非此即彼,它可以并且应该在不同的维度上计算和分析,每个维度都服务于不同的业务目的。

不过不管基于什么业务目的,最核心的基础都是客户的分组。

直接计算单个客户的精准的LTV在大多数场景下既不现实也没有很大的必要。除非是极少数超高客单价、高度定制化的企业客户。

客户分组的意义在于,同一个组内的客户有极大的相似性特征,比如获客时间、渠道、规模等等,这决定了他们的留存率、购买力、产生的收入模式也比较相似。计算他们的平均LTV对业务的指导意义更大些。

另外就是,基于相似群体的历史行为分析,得到的结果对未来的预测更准确,是远高于基于个体客户行为做的预测的,毕竟个体客户的行为是有极大偶然性的。

2、不同维度的LTV计算及意义

比较推荐的还是按时间段/客户群的LTV统计,在特定时间段内,获得的所有客户作为一个群体的平均LTV。通过对比不同时期的LTV,可以评估市场策略、产品迭代、竞争环境变化对客户的长期价值影响。

同时,通过连续观察LTV的变化趋势,可以判断项目整体健康状况和增长质量。

按获客渠道维度统计LTV的最大作用就是优化营销预算的分配。结合渠道的获客成本,计算LTV/CAC比率。比率高的渠道表明投资回报率高,应加大投入;比率低甚至小于1的渠道则需要优化或削减预算。

当然,这也有助于更好的理解渠道的价值。不同渠道吸引的客户可能在产品使用、留存率、增购能力上有显著差异。LTV可以告诉你哪个渠道带来了真正高质量的、能带来长期利润的客户,而不仅仅是注册量或首单。

三、LTV统计单一归因到渠道导致的数据失真问题

这也是一个很常见的问题,当按照渠道做用户分组,进行LTV统计的时候,如果遇到行业市场环境的变化或者其他外部因素的强烈影响时,就会导致LTV数据严重失真,导致对渠道价值的误判。

简单点说,就是因为归因偏差导致渠道背锅。

比如某公司通过A渠道进行获客,竞对发起全面的免费补贴政策,导致A渠道获客流失率飙升。如果这时候只是单纯的仅看A渠道的LTV,结论可能是A渠道质量下降,但真实原因是全部渠道的流失率无差别上升。极有可能会因此制定错误的战略,如盲目降低A渠道的预算,而忽略了真实的威胁:竞对的经营战略变动。

3.1、解决方案:从单一渠道归因到混合归因

首先,应该区分流失的类型。比如如果是客户意向度匹配差,那渠道的因素就大一些。如果是产品体验导致的流失,那要做的就是优化产品,而不是在终端渠道上费力气。如果是因为竞对经营战略导致的行业市场格局变化,那要做的就是及时调整经营战略,决定是跟进还是转向反击。

其次,可以增加时间维度的对比,排除外部环境噪音。比如可以计算渠道历史平均流失率,监测当前流失率相对历史水平的偏移程度。

一般来说,流失率偏移度= (当前流失率 – 历史平均流失率) / 历史平均流失率 ,在此计算公式下,如果所有渠道的偏移同步扩大,基本可以判定是外部环境因素导致的。如果只是单一渠道偏移度增大,则可以初步判定是渠道问题。

四、用户的现金留存和行为留存问题

假定某订阅制产品的续费周期为月、季度、年三个时间档位。那对于首次就选择季度付费的用户,应该看看做是用户预付了3个月的服务费用,其续费行为需要分层定义,而非简单等同于连续3次月付货等待二次续费。

所谓的现金留存,是看用户是否在当前服务周期结束时再次付款,主要是用来预测收入、财务做核算。而行为留存,是看用户是否持续使用产品直至下一个周期,这对产品健康度判定尤其重要。

4.1、对用户留存的两种分析视角

假定A用户在1月1日支付了Q1费用,那应该如何评估其留存与否?

如果从财务连续视角,只要等到季度结时候观察是否二次续费即可。好处是符合收入确认逻辑,避免虚假留存。缺点是滞后性比较严重,需要Q2才能判断Q1用户的留存,延误决策。比如用户很可能在Q1中就已经停止使用,但等到Q2才被发现。

那如果从用户活跃度角度看,就要监控每个月用户是否有持续的使用行为(假定把持续使用定义为每月使用>5天)。好处当然是可以实时发现用户的流失风险,可以和产品价值交付做深入的绑定,缺点是不能直接反映财务结果,因为用户即使每个月都很活跃,但依然有拒绝二次付费的可能。

4.2、解决思路:双轨制分层评估

首先要明确两个概念:现金留存率和行为留存率。

现金留存率是季度付费用户在服务结束后支付下一周期费用的比例,按季度统计。行为留存率是季度付费用户每月活跃度天数达标比例,按月统计。

其次是对用户行为的动态监控,比如当用户连续两个月不活跃的时候,运营部门就要及时介入。如果单月活跃度下降超过50%,要开启用户满意度相关调研工作。

最后就是季度末验证现金续费,对行为模型进行校准。如果发现行为留存但现金未续费,就要判断是否是竞品异常动作或产品本身功能出现问题。

五、对非订阅制产品(即一次性购买性质),如何看待渠道及LTV价值

现在我们可以跳出订阅制SAAS产品,去看一下那些几乎不存在复购的行业(如婚庆服务、房产中介、留学咨询、B2B大型设备销售等),其商业逻辑与订阅制SAAS有本质区别。这类业务的优化核心在于:最大化单次交易价值与获客成本的差值,同时通过客户价值延伸(要区分用户绝无复购可能,零售行业的复购不在此范围之内)弥补复购缺失。

5.1、关注的重点从LTV到单次交易价值(STV)

对这类行业,我们关注的重点,就要从LTV过度到STV。通常情况下,STV=(客单价×毛利率)+衍生价值。

对于客单价的优化,普遍的做法是针对渠道来源和客户属性分型来动态定价(仅从运营技术角度考量问题,排除相关法规等外部干扰因素),比如同样的产品或服务,对高端渠道的客户溢价15%。

当然也可以捆绑销售,通过增加高毛利的附加服务,提升客单价,比如房产中介+装修套餐设计。

至于衍生价值,则需看重量化。比如客户推荐(转介绍)推荐带来的新客户数×平均STV×转化率婚庆客户推荐1单=额外创造¥20,000的价值。

5.2、对渠道的评估要看重边际贡献率而非留存率

通常来说,边际贡献率(MCR)=(STV-CAC)/STV,当MCR>40%的时候,应该马上扩大预算,拉升效果。当MCR在20%-40%之间时,要着重优化渠道转化链路,拉升转化率。当MCR不足20的时候,就要重新考量渠道价值,减少投入或者重新尝试其他定位看是否有转机。

比如某留学机构发现小红书渠道的MCR是35%,其他信息流广告MCR只有12%,那肯定是要把预算朝小红书倾斜的。

5.3、基于STV的运营优化思路

对于这种商业模式,运营商可以尝试从两个层面去优化。

交易层的优化要关注一次性价值的榨取,在规则允许的条件下最大程度榨取单次成交价值。可以尝试通过各种推荐加购、捆绑策略等实现。比如婚庆客户签单后,自动推送蜜月旅行套餐。

衍生价值层面,主要是客户转介绍和客户案例的资产化。同样的获客成本之下,转介绍每多一次,平均投入成本都是呈指数下降,对项目整体影响非常大,尤其是对某些工业、重定制的超高客单价行业。

最后就是关于MCR的统计周期问题,重点要解决的就是统计周期内数据的可靠性和决策时效性之间,如何取得一个平衡点。

当样本过小的时候,会造成数据扭曲,严重影响对渠道的判断。比如某些成交比较稀疏的行业,如果仅成交2-3单就进行判断,会造成MCR过度虚高。

当然,也有另一种情况,比如房产类行业,遇到政策波动时导致MCR下跌,如果没有合理的判断体系,会误杀潜力渠道。再比如留学客户签约后的2-3个月才可能会推荐新客,当月的MCR并没有体现,这可能会低估渠道的长尾价值。

诸如此类的问题还有很多,各位可以自己思考看有什么解决思路。

本文由 @郑春雨 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务