GOOGLE PLAY REVIEW NOTES

Google Play 审核备注（Review Notes）高通过模板

很多团队技术上已经改完，结果还是被打回，问题通常不在代码，而在备注写法：审核员看不出你改了哪里、怎么复现、为什么现在合规。这版给你的是一线实操模板，拿去就能改。

拿可复制模板先看拒审整改流程

备注写作顺序（建议固定）

按“问题 -> 修改 -> 验证 -> 复现路径”写。你按这个顺序，审核员通常 1 次就能看懂；顺序乱了，很容易进入反复问答。

01 问题对应条款

先写被拒条款和触发点，例如“Data Safety mismatch on account deletion path”。先让审核员确认你知道上轮到底错在哪。

02 已完成修改

具体到页面、按钮、权限、版本号。不要写“已优化”，要写“改了什么、在哪改、哪版生效”。

03 复现与验证

给测试账号、设备、步骤、预期结果。核心目标是让审核员不问你第二次也能跑通。

可直接套用的 Review Notes 模板

Policy: [条款编号] was triggered on [页面/路径] in previous submission.
Fixes: [改动1], [改动2], [改动3] have been completed in version [x.x.x].
Validation: Tested on [机型/系统版本], all critical flows passed.
Reviewer Path: Login [测试账号] -> Go to [入口] -> Click [按钮] -> Expected [结果].
Additional Note: If reviewer cannot access [路径], use [备用入口] and check [关键标识].
给你一句实操建议：每一行都要能被“截图或录屏”验证，不能靠解释补齐。

差评版 vs 通过版（实战对照）

差评版：We fixed the issue. Please review again.
通过版：Removed READ_CONTACTS in v2.3.1; updated Data Safety and privacy policy; reviewer can verify via Login demo@test.com -> Profile -> Delete Account.
差评版的问题：没有条款映射、没有版本、没有路径、不可验证。
通过版的关键：有改动事实、有验证路径、有预期结果。

场景示例（可直接替换字段）

权限类拒审：明确“删除了哪些权限 + 哪些功能不再调用”，并写入对应页面入口。
Data Safety 不一致：逐条列出“采集项 -> 用途 -> 是否共享 -> 页面出处”，保证四处一致。
登录路径不可测：提供可复现测试账号（含地区、角色、验证码方案），避免“无法验证”。
元数据误导：写明已同步更新商店文案、截图与应用内提示，并给审核路径。

提交前审核员视角自检

可访问性：测试账号是否可登录、是否有必要权限。
一致性：备注、包版本、商店文案、隐私政策是否一一对应。
可复现性：步骤是否可在 1 次会话内走通，不依赖“口头解释”。
可验证性：每一步都有可观察结果（按钮、页面、提示文本）。
效率线：你让审核员 3 分钟内看到“问题已修复”，通过率会明显提高。

FAQ

备注写中文还是英文？+

建议英文优先，尤其涉及具体操作步骤和测试账号时，表达更直接。

备注写多长合适？+

建议 6-12 行，结构完整即可，重点是可复现，而不是字数多。

每次重提都要重写吗？+

建议保留模板并按拒审点迭代，确保每一轮备注都对应当前改动。

没有测试账号也能过吗？+

涉及登录或权限流程时不建议。缺账号通常会直接影响审核效率。

备注能降低二次拒审吗？+

能。前提是备注真实对应改动并可复现，不是模板化空话。