文档介绍：计算手游不同阶段LTV的方法和模型
一件事情是要问明白计算LTV的目的是什么。如果你有一款基于免费模式的手游,那么毫无疑问用户终身价值就是该款游戏的主要KPI。以下是原因:
在设计阶段,先要做Benchmark分析,你需要估算跟你游戏类似的LTV及他们的CPI,以确保项目能有足够的投入预算。换言之,你需要先保证项目最后能赚钱。
当进入试运营(soft launch)阶段,你需要测算并不断优化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