为什么移动游戏需要同意 SDK

如果你的游戏向欧洲经济区或英国的玩家展示来自 AdMob、Ad Manager 或中介 waterfall 的广告，那么在使用任何个性化广告或跟踪标识符之前，你在法律上必须获得有效同意。网页 Cookie 横幅无法解决这个问题 — 原生移动应用没有 Cookie，而同意必须送达在你的 build 内运行的 ad SDK。

Google 的答案是 User Messaging Platform (UMP) SDK，即随 Google Mobile Ads SDK 一同提供的同意层。它展示符合 IAB TCF 的同意表单，存储玩家的选择，并暴露一个 AdMob 和中介合作伙伴会自动读取的同意信号。对于一家 Unity 工作室而言，正确实现这一流程是健康 eCPM 与一波政策处罚之间的区别。

同意流程，从头到尾

正确的操作顺序比任何单个 API 调用都更重要。每次应用启动时你都应当：

• 请求一次同意信息更新。 这会告诉 UMP 去检查玩家所在地区以及是否需要表单。
• 如有需要则加载并显示表单。 UMP 根据地理位置和先前的选择来决定是否显示 — 你绝不应硬编码"该用户是否在欧盟"。
• 等待表单关闭后再初始化 Mobile Ads SDK。
• 仅在收集到同意后才初始化广告，使第一次广告请求就已携带正确的信号。

在同意表单返回之前初始化 ad SDK 是我们见到的最常见错误。它会产生一次非个性化或不合规的首次展示，并可能触发自动化政策审查。

一个最小的 Unity 实现

在 C# 中，骨架如下所示：

var request = new ConsentRequestParameters();
ConsentInformation.Update(request, (FormError error) => {
  ConsentForm.LoadAndShowConsentFormIfRequired((FormError err) => {
    if (ConsentInformation.CanRequestAds()) InitializeAds();
  });
});

CanRequestAds() 检查是你的关卡。只要它返回 true — 无论是因为玩家已同意，还是因为他们处于受监管地区之外 — 你就可以初始化并请求广告。不要自己缓存任何关于地区的信息；让 UMP 成为唯一的真实来源。

无需上架商店即可测试

除非你模拟一台 EEA 设备，否则无法从你的办公室（比如在伊斯坦布尔）验证同意流程。UMP 支持调试地理设置和测试设备哈希 ID 列表：

• 在请求参数中注册你的测试设备的哈希 ID。
• 将调试地理强制为 EEA 以使表单出现。
• 在两次运行之间使用 SDK 的重置方法，这样你每次都能看到首次启动体验。

在生产 build 之前务必移除调试设置。向每位玩家发布一个强制 EEA 的调试标志是一个真实而尴尬的事故。

同意、中介与你的收入

当同意正确传播时，你中介堆栈中的每一个网络 — AdMob、Meta Audience Network、Unity Ads、AppLovin — 都会收到 TCF 字符串，并可在允许的地方对个性化库存出价。当它出问题时，这些网络会以 eCPM 的零头回退到非个性化广告，你的 waterfall 会悄悄地流失收入。把同意层当作你变现堆栈的一部分，而不是事后才想起的合规事项。

FlexyConsent 的定位

UMP 涵盖了 Google 自己的范围，但大多数认真的发布商会同时在网页资产、多个应用和服务器端打标上运行同意。FlexyConsent 为你提供单一的同意记录、TCF 和 Google Consent Mode v2 信号，以及跨每个平台的同意率分析 — 这样玩家在你的 Unity 游戏中所做的选择和访客在你的营销网站上所做的选择都存在于一个可审计的地方。合规变成了一块仪表板，而不是一场救火演习。

关键要点

• 在初始化 Mobile Ads SDK 之前，通过 UMP SDK 收集同意。
• 切勿硬编码地区逻辑 — 让 UMP 来决定何时需要表单。
• 使用调试地理和哈希测试 ID 进行测试，然后在发布前将其移除。
• 正确的同意传播能在整个中介堆栈中保护你的个性化广告 eCPM。