Google Play三消游戏审核案例：首次拒审整改复盘
三消游戏并不是功能越简单，上架审核就越容易。本案例记录一款面向日本及东南亚市场的休闲游戏首次提交 Google Play 后的整改过程……
一、项目概况
这是一个休闲三消游戏，主要面向日本和东南亚市场。
游戏本身不复杂，用户安装后直接玩，不需要注册，也没有登录流程。整个游戏有120个关卡，主要通过激励广告做变现，同时接入了 Google Mobile Ads 和 Firebase Analytics。
第一次提交 Google Play 后没有通过审核。
拿到审核反馈后，我们没有马上去改某一个页面，而是先把提交的 AAB 重新装了一遍，从头到尾按正常用户的方式玩了一遍。这样查下来，发现有几个问题其实平时开发测试很容易漏掉。
| 项目 | 情况 |
|---|---|
| App类型 | 休闲三消游戏 |
| 目标市场 | 日本、东南亚 |
| 游戏内容 | 120个关卡 |
| 商业模式 | 免费游玩 + 激励广告 |
| 用户体系 | 无注册、无登录 |
| 主要SDK | Google Mobile Ads、Firebase Analytics |
| 本次排查重点 | 广告、网络状态、版本升级、正式包 |
二、第一次提交后，我们先查了这几个地方
第一次完整跑下来，问题主要集中在广告流程和一些特殊场景。
| 发现的问题 | 当时的表现 | 后续处理 |
|---|---|---|
| 断网状态 | 没网络时仍出现“观看广告继续” | 增加网络状态判断 |
| 广告触发 | 新手阶段出现广告入口较早 | 调整广告出现节点 |
| 奖励文案 | 免费奖励和广告奖励不够容易区分 | 重新调整按钮文案 |
| 版本升级 | 之前测试以新装为主 | 增加旧版本升级测试 |
| 测试逻辑 | 正式 AAB 中还有隐藏测试入口 | 清理测试入口和相关代码 |
1. 最先发现的是断网问题
这个问题其实挺容易碰到。
游戏支持部分离线玩法，所以我们特意把手机断网，再继续玩。游戏本身还能正常进行，直到某一关失败。失败以后，页面上还是出现了“观看广告继续”的入口。问题就来了——现在根本没有网络，广告当然加载不出来。
之前正常测试的时候一直是联网环境，所以这个情况没有暴露出来。重新测试后，我们把网络断开、游戏失败、点击广告、恢复网络几个状态分别跑了一遍。
最后的处理方式也比较直接：没有网络时，不再进入激励广告流程；网络恢复后，再按照正常逻辑处理广告。
这类问题从功能角度看不算大，但如果审核人员刚好在不同网络环境下测试，就很容易遇到。Google Play 对广告体验有专门的要求，具体可以参考 Google Play广告政策。
2. 广告入口出现得有点早
第二个问题是广告出现的位置。
第一次版本里，新手流程结束得比较快，用户刚开始玩没多久，就会看到广告相关入口。开发的时候可能觉得“这个功能正常就可以”，但重新从普通用户的角度走一遍，会发现这个节点确实有点突兀。
所以这次没有把广告功能删掉，而是重新调整了触发条件。正常玩游戏的时候尽量不打断用户，真正需要通过激励广告获得额外奖励的时候，再让用户主动选择。
3. 奖励文案也重新改了一遍
还有一个细节，是奖励按钮的文字。
游戏里面同时有免费奖励和看广告获得奖励，但原来的英文文案区分得不够明显。站在开发者角度，可能一眼就知道两个按钮分别是什么意思。但第一次玩这个游戏的人未必知道。
所以我们重新看了一遍所有奖励相关页面，把“直接领取”和“观看广告后领取”明确区分开。这种地方没有什么复杂技术问题，主要还是看产品细节够不够清楚。
三、后来又发现一个之前没认真测过的场景：升级
这次整改过程中，我们专门做了一次旧版本升级测试。以前测试新版本，基本都是卸载旧 App，然后重新安装，再从第一关开始玩。这种测试没有问题，但它只能证明“新用户能不能正常使用”。
如果一个已经玩过几十关的用户升级到新版本，他原来的进度还在不在？金币和道具有没有变化？页面显示是否正常？
这些都需要另外测试。
所以我们保留旧版本数据，再升级到整改后的版本，重新检查关卡进度、金币、道具和相关数据。
测试过程中确实发现了一处数据展示不一致的问题，随后一起处理掉了。
这也是这次比较有价值的一点：新装测试通过，不代表升级测试也没问题。
四、最后又翻了一遍正式 AAB
代码改完以后，我们没有直接重新提交。因为之前为了方便测试，游戏里曾经留过一个隐藏入口，可以直接跳到后面的测试关卡。
开发环境里这样做很方便，但正式版本肯定不能继续留着。所以最后又从提交用的 AAB 入手检查了一遍，把测试入口、测试逻辑和相关调试内容清掉。这一步看起来比较琐碎，但我们现在做上架前检查时，会比较重视。
开发版本没问题，不等于上传到 Google Play 的版本就一定没问题。
真正需要检查的是最后准备提交的那个包。
五、Data Safety也重新核了一遍
这个游戏没有注册和登录，所以一开始很容易产生一个误区：没有账号，是不是 Data Safety 就比较简单？
其实不一定。
因为项目接入了 Google Mobile Ads 和 Firebase Analytics，所以我们还是重新核对了 SDK 实际涉及的数据处理情况，再检查 Play Console 里的 Data Safety 填写内容和隐私政策是否对应。
具体填写时，还是以 App 实际使用的数据和 SDK 行为为准，不能因为“没有登录功能”就直接默认不涉及数据处理。
Google 官方可以参考 Data Safety说明 和 用户数据政策。
六、重新提交前，我们又完整跑了一遍
前面的地方处理完后，最后没有只点几个按钮确认功能，而是从安装开始重新走。
安装 → 新手引导 → 正常游戏 → 断网 → 游戏失败 → 激励广告 → 领取奖励 → 升级版本 → 查看商店页面
这一遍主要看的是前后有没有互相影响。
| 最后确认的内容 | 主要检查什么 |
|---|---|
| AAB | 正式包、测试入口、调试逻辑 |
| 游戏流程 | 关卡、进度、奖励 |
| 网络状态 | 在线、断网、恢复网络 |
| 激励广告 | 触发、加载、关闭、奖励 |
| 升级 | 旧版本数据是否正常 |
| SDK | Google Mobile Ads、Firebase Analytics |
| Data Safety | Play Console填写是否与实际情况一致 |
| 商店资料 | 截图、描述、版本信息 |
| 隐私政策 | 页面能否正常访问、内容是否匹配 |
如果你的 App 也准备第一次提交，建议不要只看功能有没有跑通，可以结合我们的 Google Play审核检查清单，从正式包、广告、权限、数据安全和商店资料几个方面一起检查。
七、这次案例最值得注意的，其实不是“改了什么”
回头看，这个项目没有特别复杂的整改。
真正花时间的是把一些平时不太容易注意到的场景重新跑了一遍。
比如：
- 没网络的时候，广告按钮还在不在？
- 老用户升级以后，之前的进度还在不在？
- 开发时留下的测试入口，有没有跟着 AAB 一起带进去？
- Play Console 里的 Data Safety，和实际接入的 SDK 是不是一致？
这些问题平时开发测试不一定会全部遇到，但到了正式提交阶段，最好提前自己找一遍。
对于游戏、工具类 App 或 AI App 来说，审核前真正需要看的，往往不只是“能不能用”，还包括用户怎么用、特殊情况下会发生什么，以及最终提交的版本到底是什么状态。
如果你正在准备 Google Play 首次上架，也可以从 Google Play上架服务了解完整的上架和审核支持流程。