AdMob 的同意（Consent）配置不是隐私政策页脚里的一句法律声明，在 2026 年它是一项变现设置。你的应用能否向欧洲经济区（EEA）、英国和瑞士的用户投放广告、投放什么样的广告，取决于你在 AdMob 后台创建的一条消息，以及一个把用户选择读回广告请求链路的 SDK——也就是 Google User Messaging Platform（UMP）SDK。它驱动的状态决定了每一次广告请求究竟是个性化展示、受限展示，还是根本不发出去。

麻烦的地方在于：同意配置出问题时，表面几乎看不出来。应用照常安装、广告照常渲染、后台照常有展示量，只是单用户收入在那些单价最高的地区悄悄变低了。本文按实际配置顺序给出一份完整清单：账号权限前置条件、消息类型与投放地区、Android 与 iOS 的 UMP SDK 接入、canRequestAds() 这道闸门、隐私选项入口、用调试地区与测试设备做验证、美国各州信号，以及同意模式（Consent Mode）。每一步都对应 Google 官方 AdMob 帮助与移动广告 SDK 文档里写明行为。

一、三层配置，别混为一谈

绝大多数配置错误，源于把其中一层当成了另一层。请把下面三件事分开放：

如果德国用户从来没看到表单，问题在消息配置或投放地区，而不在你的广告代码；如果用户看到了表单，但你的应用在 SDK 还没拿到答案时就发了广告请求，问题在你的请求流程。层次不同，修法不同。

二、第 1 步：确认你有权限配置

三、第 2 步：创建欧洲法规消息

  1. 在 AdMob 打开 Privacy & messaging，创建新消息（该应用是第一条消息则按钮为 Create，否则为 Manage）。
  2. 选择这条消息要在哪些应用中展示。UMP SDK 是依据你项目里配置的 AdMob Application ID 去解析消息的，所以没被选中的应用，等于没有表单可展示。
  3. 选择语言。当设备语言无法判断时会回落到默认语言，因此每一种加入的语言都要在发布前逐条读一遍。
  4. 在 Targeting 里选择 Countries subject to GDPR (EEA, UK, and Switzerland) 或 Everywhere。多数应用应选前者：让表单只覆盖政策适用的用户。
  5. 填写 隐私政策 URL（这是消息的必填部分），复核后发布。保存草稿不等于发布，而未发布的消息永远不会出现。

Google 在 AdMob 后台还提供了针对同意实现的 Error reports，表单行为异常时，这是第一顺位的排查入口。

四、第 3 步：Android 接入

UMP SDK 与广告 SDK 是两个独立库，要求 Android API level 21 及以上。

// app/build.gradle
dependencies {
    implementation("com.google.android.ump:user-messaging-platform:4.0.0")
}
<!-- AndroidManifest.xml -->
<meta-data
    android:name="com.google.android.gms.ads.APPLICATION_ID"
    android:value="ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy"/>

五、第 4 步：iOS 接入

# Podfile
pod 'GoogleUserMessagingPlatform'
<!-- Info.plist -->
<key>GADApplicationIdentifier</key>
<string>ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy</string>

六、第 5 步：每次启动都请求同意信息

这一步的典型问题是「只实现了第一次」。

七、第 6 步：用 canRequestAds() 卡住广告请求

八、第 7 步：隐私选项入口

九、第 8 步：用调试地区与测试设备验证

  1. 构造 ConsentDebugSettings，用 addTestDeviceHashedId("…") 注册测试设备。该哈希 ID 会打印在首次 requestConsentInfoUpdate() 的日志里，复制即可。
  2. 用 setDebugGeography(DebugGeography.DEBUG_GEOGRAPHY_EEA) 强制地区，不必出国就能走一遍 EEA 表单；英国与瑞士同样适用。
  3. 从 UMP SDK 2.2.0 起，模拟器默认即被视为测试设备，无需再登记设备 ID。
  4. 用 consentInformation.reset() 模拟全新安装、重看首次体验。它是测试工具，不要在生产代码中调用。
  5. 发布前务必移除调试设备 ID 与强制地区设置。强制地区等于对用户真实所在地硬编码一句假话，它只属于开发构建。

十、第 9 步：美国各州——RDP 或 IAB GPP，二选一

十一、第 10 步：同意模式（Consent Mode）映射

十二、用户拒绝之后会发生什么

十三、故障清单：八种静默失效

  1. 消息只保存了草稿，从未发布。
  2. 消息里没有勾选该应用，对应 Application ID 自然没有表单可展示。
  3. 清单或 Info.plist 里填了错误的 AdMob 应用 ID。
  4. 投放地区误设为 Everywhere（或反之），与真实受众不符。
  5. 缺隐私政策 URL，导致消息无法发布。
  6. 冷启动即在 requestConsentInfoUpdate() 之前发广告请求，canRequestAds() 根本不可能为 true。
  7. 应用自行缓存同意结论，不再每次启动询问 SDK。
  8. 把调试设备 ID、强制地区或 reset() 带进了正式包。

上面每一条都能在发布前查清，且都属于构建与配置缺陷，不需要任何政策辩论。

十四、KappS 的协助范围

同意配置与开发者账号、付款资料、税务信息位于同一条链上：任何一环悄悄卡住，都会在不停机的情况下拖住收入。KappS 帮开发者在这条链上准备并提交合规材料，其中就包括 AdMob 这一侧——消息是否已发布、应用 ID 是否登记正确、广告请求是否真的被同意状态卡住，这些差别最终都体现在 EEA 地区的收入上。

我们不做的事，是制造同意。一个从不展示的表单，或一个声称用户从未给出答案的信号，都属于违反政策，会把账号与收款一起置于风险之中，也不是我们提供的服务。上面的配置就是全部诀窍：展示真实的表单、保留真实的答案，并在广告请求处尊重它。

资料来源（Google 官方文档）：AdMob Help — European regulations message（support.google.com/admob/answer/10113207）；Mobile Ads SDK — Set up UMP SDK（Android / iOS，developers.google.com/admob）；US states privacy laws（RDP 与 IAB GPP）；Interpret consent mode values；Google《欧盟用户同意政策》。