LTV计算思路

LTV介绍

LTV最初是用来辅助投放决策的。例如 某买菜平台在应用商店获得一个转化用户需要支出100元的成本，但是可能用户只买了一份黄瓜，这看起来好像非常荒谬，但是我们把眼光拉长，实际上这些在应用商店下载的客户平均会在该买菜平台下了50单以上，如果一单平台赚3块钱，那么显然花100块钱购买一个用户是非常划算的。所以，LTV就是指拉长时间周期来衡量一个用户创造的价值。

LTV=LT*value，即用户留存生命周期时长*每单位时长内创造的业务价值

如：

业务一：某工具类APP，用户访问APP可以通过广告曝光等创造公司收益，平均下来用户每天访问的arpu值为0.5元，而一个用户从新增到彻底流失之间，平均会访问300天。那么这个APP的用户LTV计为300*0.3=90元。

业务二：某个鲜花电商平台，用户订购鲜花带来公司收益，平均用户每个月会下2笔订单，每笔订单单均GMV为100元，利润率20%。一个用户从新增到彻底流失之间，有3个月在平台订花，那么这个平台的用户LTV中

每个订花月的价值：value=2*100*20%=40元

LTV=40*3=120元

基于上述两个例子我们总结出如下LTV计算的要点

1、LT的计算单位可以是日、月、年，取决于大多数用户群体的消费频次特点

2、LT并不是用户从新增到判定流失之间的自然时间周期，而是在此期间有有价值行为的时间。例如业务二中的某个用户从新增到流失之间有12个月，但是只有2个月是有交易行为的，那么这个用户的LT是2而非12

3、一个业务的value和LT通常是相对的，如果LT非常高（也就是价值频次很高）那么他的value（价值量）一般都比较低。

4、在计算value的时候最好避免使用转化率这类的参数，这可能会使业务落入虚无指标陷阱，还是以业务二为例，我们是否可以将LT变成访问天数，value变成访问天数*平均访问转化率呢？答案是最好不要，因为平均访问转化率并不是一个直接的价值指标，如果按照这个思路，我们很自然的会想到是不是可以通过一些营销手段提升了一部分用户的访问天数进而提升LTV呢（比如签到激励）？但是实际上，如果用户的消费习惯并没有变化，那么通过一些引导提升访问频次之后，他的访问到购买转化率自然不会维持原有的水平。使用转化率指标计算value很容易造成此消彼长的情况。

5、计算LTV中的LT时，一般不会把时间无限期拉长，总不能看100年后一个用户还在不在平台下单。通常我们会根据业务需要观测一个用户在1个月LTV，半年的LTV，1年LTV、3年LTV、5年LTV等。如果是指导一些投放策略那可以看的短期一些，如果是财务数据需求那可以相对看的周期长一些，总之，还是要根据具体的业务场景而定。

LT预估思路

LTV计算的难点在于对LT的预估。我们可以实际观测1年前新增的客户在新增后1年内的LT，但是得到这个结论已经太滞后了。现如今的市场情况可能早就改变了。所以我们需要及时的预估LTV的变化来指导当前的投放决策。这里有两种LT预估思路，我们分别介绍之后再来对比两种思路的差异以及应该如何选择。

我们以业务二（鲜花订购平台LTV计算）为例，计算以月为单位的LT

思路一：根据次N月留存的cohort模型计算 LT=1+R1+R2+...+Rn

Rn代表新用户在次n月的留存，因为用户每留存1个月就贡献1个LT增量，所以

平均每个用户的生命周期长度LT可以用如下公式表示

按照这个思路，我们就可以进行LT预估

step1：求得留存率cohort数据，计算方式参考

SQL-计算留存率cohort_格勒王的博客-CSDN博客计算留存率cohort，以及不同时间维度下的留存率（日留存cohort，周留存cohort，月留存cohort)https://blog.csdn.net/weixin_47198715/article/details/130844484

with tmp as 
(select 
  date,--yyyy-mm-dd格式，如果是yyyymmdd需要转换
  substr(DATE,1,7) AS month,
  user_id
from table_name
where is_new=1#筛选新用户
)
 
 
select 
a.month,
gap,
`客户数`,
stay_num
from 
 (--计算留存率分母
    SELECT month,COUNT(DISTINCT user_id) AS `客户数`
  FROM  tmp
  GROUP BY month)a--计算每日新增客户数
LEFT JOIN 
 (--计算留存率分子
  SELECT
  begin_date,
  gap,
  count(distinct user_id) as `留存客户数`
  from 
    (SELECT
    a.user_id,
    a.month as begin_month,
    floor(months_between(b.date,a.date))as gap--计算间隔天数
    from 
      (select *
      from tmp)a
    left join 
      (select *
      from tmp)b
    on a.user_id=b.user_id)a
    where gap>=1--筛选间隔天数大于等于1的记录
  group by begin_month,gap)b
on a.month=b.begin_month
————————————————
版权声明：本文为CSDN博主「格勒王」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_47198715/article/details/130844484

step2：根据历史次N月留存cohort和当前次月留存，进行当前月的cohort预估

因为通常来说距离当前时间越近，次N月留存率数据越少，所以我们需要对次n月留存率进行预估

这里有一个基本假设：

一个新增用户本身的消费特点会在首转和次留上体现出来。

用户次N月的留存只和次月留存有关，是在次月留存的基础上衰减得到

 如果我们选定距离新增的第n月，不管次n月留存率如何变化，那么第n月留存率Rn / 次月留存率 这个比值保持稳定，即Rn = R1*f( n )，其中f( n )是一个只与n有关的函数，这里称f( n )为留存衰减系数。

1. 实际计算f( n )时我们可以选取产品留存历史数据，得到前n月留存率均值
2. 根据均值计算Rn/R1实际值，
3. 根据Rn/R1实际值拟合一个f(n)函数
4. 得的f(n)之后，再将最新的次月留存带入函数得到预估的Rn值

第三步拟合函数的时候，可以选择幂函数或者对数函数，二者的差异在于：

• 幂函数永远大于0，但是对数函数结果会小于0，显然留存率不可能小于0
• 拉长周期，幂函数的衰减速度比对数函数慢，如图

在拟合过程中，选择幂函数或者对数函数也是可以灵活调整的，通常情况下幂函数更合理，但是如果你希望结果保守一些，宁肯稍微低估不要被过于高估 ，那也可以选择对数函数，但是注意处理的时候要把小于0的结果默认为0

思路二：LT=1/流失率

原理：几何概率

几何概率：如果每次实验有P的概率成功，那么实验n次能获得1次成功

n的期望值E(N)=1/P

例如：投硬币有50%的概率投出正面，所以投几次能得到正面的期望值是1/0.5=2次

套用到LT计算的应用中，用户每个月下过单之后的流失率为p，用户下几个月的订单之后会彻底流失，这里的下几个月的订单就是LT了

如果要使用几何概率的数据，那么首先要保证的是得到一个稳定的流失率，但是每月支付之后的流失概率不同（通常是流失率快速下降，最后才会稳定在一定的水平），所以，需要分两段计算：

总LT=稳定前的实际LT+稳定之后的预估LT

举例说明：

用户在第5个月之后，流失率稳定在30%左右，也就是说，用户累计支付月份大于5个月（不一定连续），之后的每增加一个支付月，都有30%的用户会流失掉，不再下单。

从第6个月开始的累计留存月，可以用几何概率期望值计算

用户在第6+N个月流失的概率=（1-0.3）^(n-1)*0.3

N的期望值=1/0.3=3.33，也就是说，用户从第6个月开始，会再平均留存3.33个月，所以，能够6个月都有支付订单的用户，生命周期总计会有9.33个月有支付订单

计算流失率

流失率=1-漏斗留存率

漏斗留存率的计算是【产生第N+1个支付月的用户】/【产生第N个支付月的用户数】，所以每个月的新增用户的转化窗口期不一致，例如202105月新增的用户，只有1个月的时间来产生2单支付，但202005月的新增用户，有12个月的时间可以产生2单用户，所以距离现在时间越近的月份，因为没有足够长的复购周期，所以漏斗留存率越低估。

因为计算LTV是考虑拉长时间周期到无限长，所以这里取留存漏斗的最大值

SQL

select 
mon,
num,
count(distinct a.cuser_id),
count(distinct b.订单ID),
sum( b.订单金额)
from 
  (SELECT 
  distinct user_id,mon
  FROM 
  (select 
  user_id,
  substr(date,1,6) mon,
  dense_rank()over(partition by cuser_id order by substr(date,1,6)) num --按月排序，并列的月算同一个月：1、2、2、3、4
  FROM table_name)
  WHERE num=1)a--记录首单月份和城市

left join 
 
  ( select 
  user_id,
  订单ID,
  订单金额,
  substr(date,1,6) mon,
  dense_rank()over(partition by cuser_id order by substr(date,1,6)) num 
  FROM table_name)b--记录第N单的订单，价格
on a.user_id=b.user_id
group by
mon,
num

*得到数据之后需要用Excel透视表进行处理，得到如下图表：

思路一&思路二对比

计算差异，虽然都是计算留存cohort，但是：

• 思路一：取的是次N月留存cohort，次3月留存并不意味着次2月也留存
• 思路二：取的是次N个支付月的留存cohort，有第3个支付月的用户必然有第2个支付月

二者的优劣对比

• 思路一：需要拟合次n留存/次1留存的数值，拟合方式和拟合的效果不能保证
• 思路二：需要更长期稳定的历史数据，不适用于新业务LTV的计算，如果业务累计的数据很短暂，那么流失率虽然看起来稳定在某个数值，但是拉更长的时间周期可能流失率还会继续下降