GOOGLE PLAY REVIEW NOTES

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

很多團隊技術上其實已經改完，還是被打回，問題通常不在程式，而在備註寫法：審核員看不出你改了哪裡、怎麼復現、為什麼現在合規。這版給你一線可落地模板，拿去就能改。

拿可複製模板先看拒審整改流程

備註寫作順序（建議固定）

按「問題 -> 修改 -> 驗證 -> 復現路徑」寫。你按這順序，審核員通常一次就看懂；順序亂了，很容易進入來回問答。

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 行，結構完整即可，重點是可復現。

每次重提都要重寫嗎？+

建議保留模板並按拒審點迭代，確保每輪都對應當前改動。

沒有測試帳號也能過嗎？+

若涉及登入或權限流程，不建議省略，容易影響審核效率。

備註真的能降低二次拒審嗎？+

能，前提是內容真實對應改動且可復現，不是空泛模板語。