悄悄扼杀你广告收入的同意字符串错误

无声的收入泄漏

当你的 eCPM 每月下滑几个百分点时,原因很少是库存或底价。更常见的是一个损坏的 TC string—即随每个广告请求传递的 IAB Transparency & Consent Framework (TCF) 信号。格式错误或缺失的字符串不会抛出任何响亮的错误。相反,广告服务器会悄悄回退到非个性化广告,需求方合作伙伴退出,收入在没有一条警报的情况下流失。对于在 EEA & UK 进行变现的应用和游戏发布商而言,这是最被忽视的收入损失原因。

TC string 实际承载什么

TC string 是由你的同意管理平台 (CMP) 创建的 base64 编码块。它编码用户的选择:已同意的目的、允许的供应商、你的 CMP ID、政策版本和时间戳。买方在毫秒内将其解码,以决定是否能以个性化定向出价。有两个信号同样重要:

如果其中任何一个出错,需求就会蒸发—即便用户实际上已经同意。

悄悄让你损失金钱的五个错误

1. 字符串缺失或过期。 如果 CMP 从未写入字符串,或缓存的同意超过了你的重新征询窗口而过时,请求就会在没有信号的情况下发出。买方将「无字符串」视为「无同意」,只用低 eCPM 的情境化需求出价,或干脆跳过竞价。

2. 错误的 CMP ID。 每个经认证的 CMP 都有一个注册 ID 烙印在字符串中。如果写入了一个无法识别的 ID,Google 和 IAB 供应商会拒绝它—这在迁移后旧 SDK 仍被打包时很常见。

3. 供应商未声明。 一个需求方合作伙伴可能拥有完整同意,但如果其供应商 ID 不在允许供应商列表中,它就无法进行个性化出价。发布商常常在添加合作伙伴后忘记更新该列表。

4. 格式错误的 gdprApplies 传递字符串 "1" 而非整数,或对明显处于 EEA 的用户将其留为 undefined,都会令买方困惑。一个错误的 gdprApplies=0 还可能在看起来正常的同时让你面临合规风险。

5. Consent Mode 信号未触发。 TCF 字符串可能完美无缺,而 Consent Mode 却停留在其默认的拒绝状态—例如,当 SDK 在同意完成解析之前就加载了广告。此时无论 TC string 如何,Google 都会投放非个性化广告。

循序渐进的调试工作流

从设备向外逐步推进到广告服务器,并在干净的状态下复现—清除应用数据或使用全新的浏览器配置文件,以免陈旧的同意误导你。

修复根本原因

修补一个坏请求很容易;防止下一个才是真正的工作。让广告在初始化前等待同意,使你的供应商列表与需求堆栈保持同步,并跟踪个性化与非个性化展示的比率—那里的变化是你最早的警告。

这正是 Google 认证 CMP 体现价值之处。FlexyConsent 发出带有正确 CMP ID 和供应商声明的有效 IAB TCF 2.3 字符串,触发 Consent Mode v2 信号,使 ad_user_dataad_personalization 跟随用户的选择,并在网页、Android 和 iOS 上呈现同意率分析—这样,损坏的字符串会显现在仪表盘上,而不是出现在你的结算中。

关键要点

← 博客 阅读全部 →