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

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