以游戏为例,LTV有几种算法,最普适的一种是该游戏所有用户的流水加总 / 游戏用户数。这个算法和另一种算法大体相似,那就是LTV=LT * ARPU。LT为单个用户平均的游戏生命周期,单位为天,LT=用户累计游戏天数 / 累计在线用户数;ARPU就是我们知道的ARPU。之前还看过另一种是通过拟合函数对未来LTV进行预估,LTV=(1 / 流失率)* (累计收入 / 游戏用户数) 或 (游戏用户数 / 流失用户)* (累计收入 / 游戏用户数),用来预判,值会偏低一些。 但是实际的LTV预估不会按照这一套来操作,因为游戏分阶段的LTV表现差异是比较大的。比如以OB后7天去做30日、180日和365日的LTV预判,显然是严重偏低的。所以一般来说,会根据游戏在测试阶段的付费表现,同品类游戏短线长线留存和流水数据,构建不同周期LTV之间的函数模型。再在这个模型上搭上用户付费模型,即以游戏当前效果来看,核心吸收了付费能力在什么区间的用户,他们的历史流水和各时期LTV如何。最终可以基本预判一个365天的LTV基础值,按经验来说,这个值大部分时候会偏高,也就是更接近理想水平一些,所以不能完全等同,作为一个上限值来参考即可。 回归到楼主这个话题,捞取一个流失用户的成本 ≤ 用户的LTV预估 - 单个用户的买量成本,这个逻辑是正确的。但是在活动运用当中,其实没有这么复杂。很多时候逻辑会简化为「如果不挽回这批用户,等同于我要再买一批同质量的新增用户,才能补上这批用户的亏空」,所以就变成流失用户的召回成本 ≤ 单个用户的买量成本。即把流失用户视为一个对平台和内容有认知、质量更优的新用户来进行成本核算。 而且说实在的,做过流失用户召回的都知道,这事儿多难啊。最大的问题哪是钱啊,是有钱没处花,流失用户我不听我不听,风雨不动安如山。预算一大笔,实销小虾米。所以我个人的处理方式上,大头会放在流失召回的玩法和链路设计,而不是复杂的成本汇报上。不一定有借鉴意义,供楼主参考。 |