教程2026年11月6日 | FlexyConsent

在浏览器控制台中调试 IAB GPP 字符串：分步教程

为什么 GPP 问题难以发现

当美国访客选择退出其数据的出售或共享时，这一选择必须到达页面上的每个广告伙伴。在 IAB 全球隐私平台（GPP）中，它以一个紧凑的字符串和一组部分 ID 的形式传递。如果其中任何一个出错 — 缺失、过时或携带了错误的部分 — 表面上不会有任何故障。广告照常加载，横幅看起来也正常，问题只会在之后显现出来：伙伴忽略退出选择，或者对你的库存出价降低。

好消息是，几乎所有内容都可以在浏览器控制台中检查。本教程按照我们在线上页面运行检查的顺序，逐步讲解这些检查。

步骤 1：确认 API 存在且已就绪

兼容 GPP 的 CMP 会暴露一个全局的 __gpp 函数。在你的页面上打开 DevTools，运行 ping 命令：

__gpp('ping', function (data) { console.log(data); });

返回的对象一眼就能告诉你很多信息：

如果 __gpp 未定义，说明 CMP 的 stub 缺失或加载过晚。stub 必须先于任何依赖它的广告脚本就位，否则这些脚本会看不到 CMP，要么等待，要么在没有信号的情况下继续。

步骤 2：检查适用的部分

GPP 中的每个隐私框架都有一个数字形式的部分 ID。发布商最常遇到的是 2（欧盟 TCF v2）、5（加拿大 TCF）、7（US National，“usnat”），以及从 8 开始的各州独立部分，例如加利福尼亚、弗吉尼亚、科罗拉多、犹他和康涅狄格。来自美国某州的访客，其 applicableSections 通常应显示全国部分或相应的州部分，而不是欧盟部分。

请从多个地点测试。一个常见的缺陷是：CMP 为横幅正确检测了地理位置，却无论如何都向字符串写入默认部分，或者相反。使用 VPN 或 CMP 的预览工具，对比横幅所显示的内容与 applicableSections 所报告的内容。

步骤 3：读取部分数据

与其手动解码字符串，不如向 CMP 请求已解析的部分：

__gpp('getSection', function (data, success) { console.log(data, success); }, 'usnat');

在 US National 部分中，退出字段使用一个简单的约定：0 表示不适用，1 表示用户已退出，2 表示用户未退出。请先关注这些字段：

现在在页面上执行退出 — 点击你的“Do Not Sell or Share”链接，或在偏好中心切换该设置 — 然后再次运行 getSection。退出字段应从 2 变为 1。如果没有，说明界面与信号不同步。

步骤 4：测试 Global Privacy Control 路径

多部州法律要求企业将 Global Privacy Control 信号视为退出。在支持 GPC 的浏览器或扩展中启用它，在控制台确认 navigator.globalPrivacyControl 返回 true，然后在全新会话中加载页面。即使访客没有触碰横幅，相关的退出字段也应该已经读取为 1。某些部分还包含一个字段，表明该选择来自 GPC 信号。

步骤 5：关注事件，而不只是快照

广告脚本不应只在页面加载时读取一次字符串就不再理会。注册一个监听器，看看伙伴所看到的内容：

__gpp('addEventListener', function (evt) { console.log(evt.eventName, evt.pingData); });

你应该会观察到 listenerRegistered、signalStatus 和 sectionChange 等事件。当访客更改选择时，随后应出现一个带有更新后字符串的 sectionChange 事件。如果你的 header bidding wrapper 或广告服务器集成只在 signalStatus 变为“ready”之前读取字符串，它可能会发送空值或过时的值。

步骤 6：沿着字符串追踪到广告请求

最后，打开 Network 面板并筛选你的广告请求。许多广告端点接受 gpp 和 gpp_sid 参数（字符串和适用的部分 ID）。请检查：

  1. 来自美国访客的请求中是否同时存在这两个参数；
  2. 字符串是否与请求发出时 ping 返回的字符串一致；
  3. 退出之后，后续请求携带的是新字符串，而不是缓存的旧字符串。

如果你使用 Prebid.js，请确认其同意管理模块已针对 GPP 配置，并检查从 wrapper 发出的竞价请求以及最终的广告服务器调用。

常见故障模式

核心要点

← 博客 阅读全部 →