计算手游不同阶段LTV的方法和模型.docx

1、计算手游不同阶段 LTV 的方法和模型一件事情是要问明白计算 LTV 的目的是什么。如果你有一款基于免费模式的手游，那么毫无疑问用户终身价值就是该款游戏的主要 KPI。以下是原因：在设计阶段，先要做 Benchmark 分析，你需要估算跟你游戏类似的 LTV 及他们的 CPI，以确保项目能有足够的投入预算。换言之，你需要先保证项目最后能赚钱。当进入试运营(soft launch)阶段，你需要测算并不断优化 LTV，以确保它能超过预期的 CPI。在市场推广阶段，你需要定位到 CPI设计阶段的“原始”LTV 计算游戏发布之前是没有真实数据的，只要一些假设数据即可。因此，你需要使用“原始”的计算方法

2、，即简单地将 ARPDAU 乘以单个用户的预期生命时间即可。举例：ARPDAU * Lifespan = 0.05 * 26 = 1.3分析：输入：ARPDAU预期的用户生命周期：用户有可能使用 APP 的时间长度。可以基于其他app 进行估算，或者追踪用户直到他不再出现在游戏里输出：预计每用户的 LTV优势：简单有利于了解用户 LTV劣势：方法太过简单，且只假设所有用户在同一时间内均留存无法提前得知用户会留存多久试运营阶段需要建造用户留存模型在试运营阶段，你需要一个不同的方式。此阶段的情况已经变了，因为你已经有了关于游戏留存率和付费情况的数据。具体需要 ARPDAU 和至少下列的留存率数据：

3、次日、7 日、14 日和 30 日。建造留存率模型是一个复杂的数学测试，它需要用到统计回归、对数函数和积分运算。计算方式假设留存函数是 y=a*xb 的幂函数，其中 x 为使用天数，a 和 b 是模型的系数。首先预估的是 180 天内的留存率。它使用了第 2 天、7 天、14 天、30 天和 180 天的加权系数，加权值为：2.5、7、12、57.5、100(顺序对应)。基于LTV 公式的加权系数比在幂函数求积分更简单，对于精确度的影响也没有那么大。当用户生命周期计算好后，用 ARPDAU 乘以生命周期即可轻松计算出 LTV 值。举例：ARPDAU * lifespan = 0.155 * 9

4、.02 = 1.40分析：输入：次日、7 天、14 天、30 天的留存ARPDAU(前 30 天)输出：用户预期的生命周期：所有用户的留存总和 (用户数 * 天数)180 天的 LTV优势：简单几乎与更复杂的模型一样准确劣势：30 天的留存率加权过重以 ARPDAU 不变为前提进行的假设市场推广阶段的细分 LTV 计算当你的游戏准备问世时，你将会对于终身价值的计算有新的需求。此阶段与广告投放和用户获取有关，目标就是让 LTV 高于 CPI。但并不是所有用户都要满足这个条件，只要找到某些指定的细分用户满足即可。当你找到这些细分，就可以“有的放矢”地加大投放力度。之前的 LTV 计算方法都是基于一

5、个全新产品的假设，历史数据是有限的。当来到市场投放的阶段，产品数据应该在其中一个细分群体积累了 6 个月(一般指自然量)。基于现有细分群体的数据，就可以预估新的细分的 LTV 值。这个对于新用户的计算方法需要对比前 7 天的新用户和现存用户基础，然后将同样的比率应用于现有的 LTV。计算方式假设 A 项与 B 项 7 天的收益比率会反映其在 LTV 的比率。举例，假如你有一个新的流量来源在前 7 天有 0.5 美元的 ARPU，正常来说你能在前 7 天看到 1美元，那么新的流量来源就是你正常 LTV 的一半。这非常直观，实际上改预测方法也被许多先进的模型支持。该计算方式有两步：算出 7 天内收

6、益数据间的比率将同样的比率用到 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 模型，然后利用相同的比率方法来计算新细

7、分的 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 天

8、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在新细

9、分的 7 天 ARPY 中输入第 N 天的新细分 ARPU总结：1.计算 LTV 的“原始”方法ARPDAU * Lifespan。2.生命周期计算模型(简化版)“原始”方法的缺点是不能算出预期的生命周期长度。计算的方法会有点复杂。你需要收集用户在 APP 的留存数据，用上面的幂函数公式求积分算出来。当然，更简单的方法是通过加权平均的方法进行估算(参考上面“试运营”的例子)，而且结果的精准度并不会相差太远。3.类推法则：用现有的细分历史数据类推新的细分用户 LTV这个是很多游戏公司采取的方法。它计算出现有 180 天的 LTV，用新细分的 7 天 ARPU 除以现有细分的 7 天 ARPU，得

10、出来的比例应用到现有细分的 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*xb)，并且 ARPDAU 是恒定的。手游开发者面临的最大难题之一就是计算 app 的 LTV。在网上搜索能查到很多答案，但大多数晦涩难懂。原因就在于建立 LTV 模型非常困难，尤其是在不了解用户行为、数据不充分的情况下。本文推荐了几种不同计算方法，开发者们可以根据自身具体情况做出合适的选择。更多游戏相关文章请关注大世界视频游戏平台。