1. Play 的底线是「分发地区当地法律」，不是一份全球模板。用户数据政策原文要求开发者「必须始终遵守其提供产品或服务所在司法辖区的隐私与数据保护法律」，其 Do/Don't 表格写得更直白：「遵守所有适用的隐私、数据安全与数据保护法律（例如 GDPR）……不遵守适用法律即构成政策违规。」同一份政策还要求：披露收集什么数据、如何使用、与谁共享；提供有效的隐私政策；在需要时取得同意；并提供账号删除途径。所以把一份「仅面向美国」的政策直接发给欧盟或巴西用户，不是文档瑕疵，而是叠加了法律风险的政策违规。（§https://support.google.com/googleplay/android-developer/answer/10144311）
2. Data safety 声明必须与 App 的真实运行行为逐地区一致。Data safety 是对真实运行时行为的申报——收集哪些数据类型、是否共享、传输是否加密、是否提供删除请求——Google 会拿它跟 App 本体与所打包的 SDK 对照核查。隐私政策写着「不与第三方共享」，而广告 SDK 正在传广告 ID，就是最典型的不一致。表单、政策、SDK 清单三者必须讲同一个故事；地区差异（例如欧盟区被同意管理门控的广告栈）属于这个故事的一部分，而不是塞进没人看的附录。（§https://support.google.com/googleplay/android-developer/answer/10787469）
3. 欧盟/英国/瑞士：能收集同意只是义务的一半，同意必须可撤回。Google 的 GDPR 指南原话是「GDPR 强制要求同意可撤回，你必须为用户提供随时撤回其同意选择的方式」，并且「为避免影响 EEA 与英国用户的变现，你必须在 2024 年 1 月 16 日前接入 Google 认证的 CMP」。UMP SDK 的做法是同意信息 + 一个「隐私选项（Privacy options）」入口，该入口在首次启动之后必须仍可从 App 内（设置或菜单）重新进入；只弹一次、之后再也打不开的插屏，无法通过「可撤回」这一关。注意适用范围：Google 的 EU User Consent Policy 覆盖 EEA、英国和瑞士，团队常只做 EEA 流程而漏掉瑞士。未成年人处理是另一条线：setTagForUnderAgeOfConsent 只是不发起同意请求，还必须同时在广告请求上设置 ageRestrictedTreatment，否则该标记在下游不起作用。（§https://developers.google.com/admob/android/privacy/gdpr / §https://support.google.com/admob/answer/10113207）
4. 加州：CPRA 的退出选择必须是一个看得见的链接，而不是藏在三层菜单里的开关。加州总检察长办公室的官方说明写明：出售个人信息的企业「须遵守 CCPA 的要求，在其网站上提供清晰醒目的『Do Not Sell or Share My Personal Information』链接，供用户提交退出请求」，「不得要求用户先注册账号才能提交请求」，也不应强制身份核验，并且必须尊重用户端开启的全球隐私控制（如 GPC）。在 App 里，等价物是：从设置与隐私政策都能到达的退出入口、同一套措辞，并把用于跨上下文行为广告的广告技术数据共享当作「sharing」处理。政策里大段复述 CCPA 义务、却不给任何行使路径，是我们在审核中最常见的一种失败。（§https://oag.ca.gov/privacy/ccpa）
5. 巴西（LGPD）：每个处理目的对应一个合法性基础、必须有 encarregado、必须有真实的跨境传输机制。LGPD 要求为每个处理目的记载合法性基础（第 7 条，同意只是十种基础之一），赋予数据主体确认、访问、更正、匿名化、可携带与删除等权利（第 18 条），要求公开数据保护官（encarregado）身份（第 41 条），跨境传输仅允许流向具备充分保护水平的国家或依 ANPD 承认的机制进行（第 33-36 条）。落地时巴西用户和 ANPD 真正会看的三件事：葡语版政策、App 内的权利请求通道、政策里写明 encarregado 的联系方式。（§https://www.gov.br/anpd/pt-br）
6. 韩国（PIPA）：同意必须逐项分离，「收集同意」不等于「第三方提供同意」。PIPA 要求对个人信息的收集与使用取得单独同意（第 15 条），对向第三方提供须再取得一份独立的同意（第 17 条）——一个「我已阅读并同意隐私政策」的复选框两者都不满足；数据主体享有访问、更正、删除等权利（第 35-37 条）；达到法定门槛的境外运营者还须指定境内代理人（第 31-2 条）。政策须逐项写明收集项目、目的与保存期限，面向韩国用户应提供韩语版本。（§https://law.go.kr/LSW/lsInfoP.do?lsiSeq=251020）
7. 跨境传输必须披露，不能靠暗示。三套制度收敛到同一组披露项：接收方（或接收方类别）、国家、传输的数据项、目的、方式与保存期限——GDPR 第五章及其充分性认定/SCC 路径、LGPD 第 33-36 条、韩国 PIPA 第 28-8 条。如果你的分析与广告 SDK 在美国，这就是跨境传输，政策必须具体到数据类型来说明；「我们可能与服务提供商共享数据」这句话在三地都不达标。
8. 运维方式：一份主政策 + 分地区附录。保留主文本，再按地区维护附录（辖区、合法性基础、用户权利、跨境传输、监管机构联系方式、语言、生效日期、版本号）。本地化的是语言，不只是日期；文档要版本化并保留变更记录，因为审核方与监管方都会问「用户在某天同意的到底是什么」。用时间戳 + CMP 同意字符串记录同意状态，以便日后举证；实质性变更要重新征询，而不是静默修改政策；并用改地区伪装的设备做验证——欧盟区构建打不开「隐私选项」、加州区构建没有退出入口，对任何审计方都是一行就能写下的缺陷。