文档介绍：羇计算手游不同阶段LTV的方法和模型蚆一件事情是要问明白计算LTV的目的是什么。如果你有一款基于免费模式的手游,那么毫无疑问用户终身价值就是该款游戏的主要KPI。以下是原因:蒄在设计阶段,先要做Benchmark分析,你需要估算跟你游戏类似的LTV及他们的CPI,以确保项目能有足够的投入预算。换言之,你需要先保证项目最后能赚钱。羈当进入试运营(softlaunch)阶段,你需要测算并不断优化LTV,以确保它能超过预期的CPI。肈在市场推广阶段,你需要定位到CPI螄设计阶段的“原始”LTV计算羃游戏发布之前是没有真实数据的,只要一些假设数据即可。因此,你需要使用“原始”的计算方法,即简单地将ARPDAU乘以单个用户的预期生命时间即可。蚈举例:ARPDAU*Lifespan=*26=:袃输入:莃ARPDAU莈预期的用户生命周期:用户有可能使用APP的时间长度。可以基于其他app进行估算,或者追踪用户直到他不再出现在游戏里羇输出:芅预计每用户的LTV螂优势:腿简单羈有利于了解用户LTV莄劣势:芁方法太过简单,且只假设所有用户在同一时间内均留存衿无法提前得知用户会留存多久螅试运营阶段需要建造用户留存模型螆在试运营阶段,你需要一个不同的方式。此阶段的情况已经变了,因为你已经有了关于游戏留存率和付费情况的数据。具体需要ARPDAU和至少下列的留存率数据:次日、7日、14日和30日。建造留存率模型是一个复杂的数学测试,它需要用到统计回归、对数函数和积分运算。蚁计算方式蚀假设留存函数是y=a*x^b的幂函数,其中x为使用天数,a和b是模型的系数。首先预估的是180天内的留存率。它使用了第2天、7天、14天、30天和180天的加权系数,加权值为:、7、12、、100(顺序对应)。基于LTV公式的加权系数比在幂函数求积分更简单,对于精确度的影响也没有那么大。当用户生命周期计算好后,用ARPDAU乘以生命周期即可轻松计算出LTV值。袇举例:ARPDAU*lifespan=*=:莄输入:莀次日、7天、14天、30天的留存袈ARPDAU(前30天)羃输出:螃用户预期的生命周期:所有用户的留存总和(用户数*天数)膀180天的LTV蚆优势:莅简单膃几乎与更复杂的模型一样准确袁劣势:螇30天的留存率加权过重蒃以ARPDAU不变为前提进行的假设蚂市场推广阶段的细分LTV计算蚁当你的游戏准备问世时,你将会对于终身价值的计算有新的需求。此阶段与广告投放和用户获取有关,目标就是让LTV高于CPI。但并不是所有用户都要满足这个条件,只要找到某些指定的细分用户满足即可。当你找到这些细分,就可以“有的放矢”地加大投放力度。之前的LTV计算方法都是基于一个全新产品的假设,历史数据是有限的。当来到市场投放的阶段,产品数据应该在其中一个细分群体积累了6个月(一般指自然量)。基于现有细分群体的数据,就可以预估新的细分的LTV值。这个对于新用户的计算方法需要对比前7天的新用户和现存用户基础,然后将同样的比率应用于现有的LTV。螈计算方式袆假设A项与B项7天的收益比率会反映其在LTV的比率。举例,,正常来说你能在前7天看到1美元,那么新的流量来源就是你正常LTV的一半。这非常直观,实际上改预测方法也被许多先进的模型支持。该计算方式有两步:肂算出7天内收益数据间的比率莂将同样的比率用到LTV中薆举例:7天内收益比率*LTV=*=:蒁输入:袈现有部分的训练数据(主要用来训练LTV计算模型)蚇现有细分用户的ARPU:第1天到第7天肃现有细分用户的LTV:180天袀新细分数据薈新细分用户的ARPU:第1天到第7天螈输出:蒅新细分用户的LTV薄优势:荿简单薆最准确的模式之一薃劣势:肃需要现有细分的180天数据聿高级LTV细分计算薇第三种计算方式假设有180天的数据,而这有时候是不可能的。这时从现有细分的90天数据来建立现有细分的180天LTV模型,然后利用相同的比率方法来计算新细分的LTV。羆这个计算方法的数据来自现有细分(如自然流量)来调整最初90天的模型,并利用模型功能来预估第90天到第180天的生命值。蒂计算方式衿该模型有2个步骤虿步骤1:估算180天的LTV肄把最初90天的已知ARPU与91-180天的预估ARPU相结合即可得到。这个估算是用90天的ARPDAU乘以90天到180天的用户预期生命时间。袂步骤2:应用比例薀当我们有预估的现有细分180天LTV数据,就可以用一个简单的比例来估算新细分的LTV:蒆用新细分的7天ARPU除以现有细分的7天ARPU莆将相同比例应用到现有细分的180天LTV芁所得结果即是新细分的180天LTV芀分析蒇输