第一件事情是要问明白计算LTV的目的是什么。如果你有一款基于免费模式的手游，那么毫无疑问用户终身价值就是该款游戏的主要KPI。以下是原因：
• 在设计阶段，先要做Benchmark分析，你需要估算跟你游戏类似的LTV及他们的CPI，以确保项目能有足够的投入预算。换言之，你需要先保证项目最后能赚钱。
• 当进入试运营（soft launch)阶段，你需要测算并不断优化LTV，以确保它能超过预期的CPI。
• 在市场推广阶段，你需要定位到CPI＜LTV的目标用户群体，只要这个条件一直满足，就应该不断往里面增加投入。
设计阶段的“原始”LTV计算
游戏发布之前是没有真实数据的，只要一些假设数据即可。因此，你需要使用“原始”的计算方法，即简单地将ARPDAU乘以单个用户的预期生命时间即可。
举例：ARPDAU * Lifespan = 0.05 * 26 = 1.3
分析
输入：
• ARPDAU
• 预期的用户生命周期：用户有可能使用APP的时间长度。可以基于其他app进行估算，或者追踪用户直到他不再出现在游戏里
输出：
预计每用户的LTV
优势：
• 简单
• 有利于了解用户LTV
劣势：
• 方法太过简单，且只假设所有用户在同一时间内均留存
• 无法提前得知用户会留存多久
试运营阶段需要建造用户留存模型
在试运营阶段，你需要一个不同的方式。此阶段的情况已经变了，因为你已经有了关于游戏留存率和付费情况的数据。具体需要ARPDAU和至少下列的留存率数据：次日、7日、14日和30日。建造留存率模型是一个复杂的数学测试，它需要用到统计回归、对数函数和积分运算。
计算方式
假设留存函数是 y=a*x^b的幂函数，其中x为使用天数，a和b是模型的系数。首先预估的是180天内的留存率。它使用了第2天、7天、14天、30天和180天的加权系数，加权值为：2.5、7、12、57.5、100（顺序对应）。基于LTV公式的加权系数比在幂函数求积分更简单，对于精确度的影响也没有那么大。当用户生命周期计算好后，用ARPDAU乘以生命周期即可轻松计算出LTV值。
举例：ARPDAU * lifespan = 0.155 * 9.02 = 1.40
分析
输入：
• 次日、7天、14天、30天的留存
• ARPDAU（前30天）
输出：
• 用户预期的生命周期：所有用户的留存总和 （用户数 * 天数）
• 180天的LTV
优势：
• 简单
• 几乎与更复杂的模型一样准确
劣势：
• 30天的留存率加权过重
• 以ARPDAU不变为前提进行的假设
市场推广阶段的细分LTV计算
当你的游戏准备问世时，你将会对于终身价值的计算有新的需求。此阶段与广告投放和用户获取有关，目标就是让LTV高于CPI。但并不是所有用户都要满足这个条件，只要找到某些指定的细分用户满足即可。当你找到这些细分，就可以“有的放矢”地加大投放力度。之前的LTV计算方法都是基于一个全新产品的假设，历史数据是有限的。当来到市场投放的阶段，产品数据应该在其中一个细分群体积累了6个月（一般指自然量）。基于现有细分群体的数据，就可以预估新的细分的LTV值。这个对于新用户的计算方法需要对比前7天的新用户和现存用户基础，然后将同样的比率应用于现有的LTV。
计算方式
假设A项与B项7天的收益比率会反映其在LTV的比率。举例，假如你有一个新的流量来源在前7天有0.5美元的ARPU，正常来说你能在前7天看到1美元，那么新的流量来源就是你正常LTV的一半。这非常直观，实际上改预测方法也被许多先进的模型支持。该计算方式有两步：
算出7天内收益数据间的比率
将同样的比率用到LTV中
举例：7天内收益比率 * LTV = 0.95 * 2.5 = 2.38
分析
输入：
现有部分的训练数据 （主要用来训练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
分析
输入：
现有细分的训练数据
现有细分的用户ARPU：第1天至第7天
现有细分的用户ARPU：第1天至第90天
现有细分的7天留存率
现有细分的90天留存率
现有细分的ARPDAU：第75天到90天
细分数据
新细分用户的ARPU：第1天至第7天
输出：
LTV
优势：
更新的游戏app也可以使用该计算方法
非常精确
劣势：
有点复杂
如果你有新细分超过7天的数据，那你实际上可以使用任何日期的数据，只要你能将其应用到7天的现有细分和新细分数据里。
在现有细分的7天ARPU中输入第N天的现有细分ARPU
在新细分的7天ARPY中输入第N天的新细分ARPU
总结：
1.计算LTV的“原始”方法
ARPDAU * Lifespan。
2.生命周期计算模型（简化版）
“原始”方法的缺点是不能算出预期的生命周期长度。计算的方法会有点复杂。你需要收集用户在APP的留存数据，用上面的幂函数公式求积分算出来。当然，更简单的方法是通过加权平均的方法进行估算（参考上面“试运营”的例子），而且结果的精准度并不会相差太远。
3.类推法则：用现有的细分历史数据类推新的细分用户LTV
这个是很多游戏公司采取的方法。它计算出现有180天的LTV，用新细分的7天ARPU除以现有细分的7天ARPU，得出来的比例应用到现有细分的180天LTV中，结果即是新细分的180天LTV。这样，即使没有180天的数据，也能通过现有细分的数据计算LTV。
这个计算方式融合了前两种的技巧。即使没有180天的数据，也可以利用现有细分的数据。这个计算方式使用了现有细分的部分数据来计算新细分的LTV。
等待至少90天的ARPDAU数据
使用该数据建立每日每平均用户财务积累Master Chart图表
计算90天内的流失率，将该比率应用到90日天之后的数据，得到180天的LTV，以此推算90天之后的Master Chart图表走向
用现有LTV来估算新细分：用前7日新细分收益与Master Chart内的数据作对比
4.用数据表计算留存率模型、收益函数模型
此方法假设留存率是一个幂函数（y=a*x^b)，并且ARPDAU是恒定的。以下是关于该数据表的更多细节。
它假设收益函数是对数函数。表格示例图如下：
手游开发者面临的最大难题之一就是计算app的LTV。在网上搜索能查到很多答案，但大多数晦涩难懂。原因就在于建立LTV模型非常困难，尤其是在不了解用户行为、数据不充分的情况下。本文推荐了几种不同计算方法，开发者们可以根据自身具体情况做出合适的选择。