Google Play 審核備註（Review Notes）高通過模板

關鍵點

Review Notes 不是「解釋給人看」的文案，而是「讓審核員照步驟做就能驗證」的操作說明。只要你把測試條件、審核路徑、改動對照寫到可錄屏、可截圖的程度，通過率通常就會回到正常水位。

寫作順序（6 行就夠）

1. Policy：上輪命中條款 + 觸發點。
2. Fixes：你改了什麼（具體到頁面/按鈕/權限）。
3. Version：哪個版本生效。
4. Reviewer Path：一步一步怎麼驗證。
5. Test Account：必要時提供測試帳號與條件。
6. Expected Result：每一步看到什麼才算通過。

常見問題

• 為什麼我「改完」還是被判定無法驗證？
• 一定要提供測試帳號嗎？
• 要不要附錄屏或截圖連結？
• 英文一定比中文更好嗎？
• 重提多次時，哪幾行必須更新？
• 哪些寫法最容易被當成空泛模板？

可直接套用的 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 分鐘內看到「問題已修復」，通過率會明顯提高。