2024 年，国内游戏用户 6.74 亿人，同比只增长了 0.94%；游戏市场实际销售收入 3257.83 亿元，同比却增长了 7.53%。人几乎没多，钱多了。

这篇想回答的就是这件事背后的问题：一个玩家到底值多少钱？ 这个数决定了游戏公司愿意花多少钱把他拉进来，也决定了运营每天在忙什么。我们跟着一批买量拉来的新玩家走一遍：拉他们花了多少，有多少人留下来，谁付了钱，一笔充值怎么到账，游戏里的奖励怎么不被刷爆。

先花钱：一个新玩家要 20 元

一款手游上线，发行团队在广告平台投放下载广告。假设花了 10 万元，带来 5,000 个新玩家，平均拉一个新玩家的成本（CPI）就是 20 元。站在广告平台那边，这 20 元就是广告主的「激活成本」：广告行业那篇讲的出价、竞价和扣费，算的就是它。

这 10 万元能不能赚回来，要看这 5,000 人后面的路怎么走：

买量是一笔跨时间的账：钱今天就花出去了，收入要在接下来几十天、几个月里慢慢回来。所以游戏公司最关心的问题，是一个玩家在整个游戏生涯里能带来多少收入（LTV），它要高于把他拉来的成本（CPI）。

留不留得住：留存决定一个玩家值多少钱

5,000 个新玩家，第二天就会走掉一大半：

留存是后面一切的基础：人走了，就不会再付钱。每天登录的去重玩家数（DAU）由一批批新玩家的留存叠起来，老玩家留得越久，同样的新增能撑起越大的 DAU。这也是开头那组数字的解释：收入 = 用户数 × 每个用户带来的收入，用户数只涨了 0.94%，收入涨了 7.53%，涨的主要是每个用户带来的收入，也就是玩家留得更久、更愿意付费（2024 年也有现象级产品的拉动）。

所以研发阶段的测试，看的首先也是留存。上线前一般会经过几轮测试，先看服务器扛不扛得住、玩法好不好玩、玩家留不留得住，再决定能不能大规模买量。

钱从哪来：流水 = 活跃玩家 × 付费率 × ARPPU

国内手游的主流是「免费 + 内购」：游戏免费玩，卖道具、外观、抽卡、月卡、通行证。它的收入可以拆成三个因子：

三个因子各对应运营要做的一件事：让玩家常来、让更多人愿意付第一笔钱、让付费的人买得更多。回到我们这批玩家，假设 30 天里：

30 天过去，每个玩家只带来 15 元，还没赚回 20 元的 CPI。而且这 75,000 元是流水，不是开发商的收入：玩家付的钱先要被应用商店或渠道分走一部分。以苹果 App Store 为例，内购的标准抽成是 30%，上一年收入不超过 100 万美元的开发者可以申请降到 15%。按 30% 算，到手只剩 52,500 元，剩下的还要在研发商和发行商之间分账。

这批玩家能不能回本，就看剩下那 500 个还在玩的人还能付多久。这也解释了为什么长线运营的游戏要靠持续的版本、活动和赛季维持热度：每多留住一个玩家一个月，LTV 就往上涨一点。

我做的「支付转化」分析，盯的就是付费这一环。最开始是从日志系统把数据拉到本地，用 Python 分析；后来接上公司的大数据平台，用 SQL 做了点数仓建设。这件事最大的收获在数据挖掘：找到了计费、用户体验等部门之前都没注意到的数据。

一笔充值：扣了钱就要到账，没付钱就不能到账

250 个付费玩家里的一个，在商城点了「购买」。一笔充值要走过下面这几步：

1. 服务器生成订单（订单号、玩家、商品、金额），状态是「待支付」；

2. 客户端拉起渠道支付，比如 App Store、各个安卓渠道或第三方支付；

3. 支付完成后，渠道把结果通知服务器，或者客户端把支付凭证交给服务器；

4. 服务器向渠道校验凭证的真伪和金额，防止伪造的「支付成功」；

5. 校验通过后发货：道具进背包，记一条充值流水，订单改为「已发货」，同一订单只能发一次货；

6. 每天和渠道对账，补发「扣了钱没到账」的掉单，处理退款和重复发货。

这条链路上任何一步出问题，都会变成玩家投诉，或者公司白白损失。「同一订单只发一次」和「每天对账」这两个做法，在金融系统里有更严格的版本，见金融行业。

游戏里的钱也会通胀：奖励是产出，消耗是回收

很多游戏内部有一套自己的经济系统：任务、活动、掉落给玩家产出金币和道具，商城、强化、合成再把它们消耗掉。产出多于消耗，货币和道具就会贬值，就像通货膨胀；奖励配错了，或者被人用漏洞刷，等于凭空多印了钱。玩家手里的东西不值钱了，也就不想再充值，前面那条流水公式里的付费率和 ARPPU 都会跟着掉。

我做的奖励监控，监控的就是产出这一端。第一版对比了业界很多异常检测方法，照着美团外卖订单量预测异常报警的做法，调用 Prophet 跑通了一个简单流程，但老板们对进度不太满意，没有继续研究下去。后来才知道，做算法最关键的是做好特征工程，而当时的我忽略了这一点。

后来部门成立了中台，我开始学 Java、用 Flink 做实时开发，奖励监控也换了做法：用 Flink 开发了一个动态规则引擎，业务人员可以自由配置告警规则、实时生效（见 Flink 规则引擎）。

奖励监控必须是实时的：奖励发错了，晚一个小时发现，道具可能已经被刷了一轮、在玩家之间交易开了。

别相信客户端：反外挂

外挂也是在破坏这套经济：加速、透视、自动脚本、修改内存数值，最后都会变成不该有的产出。防守的思路大致有三层：

• 服务端权威：伤害、掉落、货币变化这类关键数值，由服务器计算和校验，客户端只负责表现；

• 客户端检测与加固：检测调试器、模拟器和已知外挂特征，提高破解难度；

• 行为分析：从数据里找异常，比如操作频率超出人手的极限、收益曲线明显偏离同类玩家。

第三层是数据能发挥作用的地方，安全中台做的正是这类事：用 Flink SQL 解决数据倾斜，用 PyFlink 部署算法策略，用 Flink AI Flow 解决 AI 工程化（见我所了解的 Flink）。

数据在哪里：从拉到本地分析，到实时盯住每一笔产出

上面这些数，都要有人算出来。部门之前没做过数据，最开始是从日志系统把数据拉到本地分析，后来才接入公司的大数据平台，先把日志采集进数据仓库，再用 SQL 做离线数仓分层开发，搭起一个麻雀虽小、五脏俱全的数据中台（见工作的这五年）：

离线 SQL 写了几个月，刚好项目里有了更多实时场景，我就转向了 Flink 实时开发。游戏里很多关键问题确实是实时的：奖励发错了、外挂开始刷了，都要在损失扩大之前发现。

一个玩家值多少钱

回到开头的问题。一个玩家值多少钱，等于他留下来的时间乘上这段时间里付的钱：30 天时，我们这批玩家每人值 15 元，还没赚回 20 元的买量成本；能不能回本，看剩下的人还能留多久、付多少。用户几乎不涨、收入还在涨，涨的就是这个数。

我在那里最大的体会写在我的职业生涯里：做奖励监控时照着业界的方法跑通了流程，后来才知道关键在特征工程。放到业务上也是一样，方法不难找，难的是知道该看哪些数据。下一篇广告行业从买量的另一头看：广告平台怎么把这 20 元算出来。

参考资料

• 中国音像与数字出版协会游戏工委，《2024 中国游戏产业报告》，数据见澎湃新闻的报道：市场收入、用户数，以及小程序游戏的内购与广告变现占比。

• Apple，App Store Small Business Program：15% 与 30% 抽成的规则。

• 美团技术团队，外卖订单量预测异常报警模型实践：奖励监控第一版参照的做法。

• 我的经历：我的职业生涯、工作的这五年。