Ads.txt
植入 ads.txt 文件并非一项严格的要求,广告将在没有 ads.txt 文件的情况下继续投放。但值得注意的是,许多广告客户选择仅对已通过 ads.txt 验证的广告请求出价 - 详细了解 ads.txt。
ads.txt 文件包含可在您的网域中请求广告的所有发布商 ID,位于网域的根目录下(例如 example.com/ads.txt)。典型的 ads.txt 文件条目如下所示:
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
通常,ads.txt 文件中使用的发布商 ID 取决于广告代码中 data-ad-client
的值。不过,由于大多数 AFP 平台客户都有数千个子帐号,管理此文件乃至 Google 和其他出价方都难以处理,因此很难做到这一点。平台客户可通过两种方式解决此问题,并在其平台网域上扩大 ads.txt 的使用范围。平台可以根据需要选择以下任一选项,或结合使用二者:
- 平台可以在公共后缀列表中注册域名
- 平台可以在 ads.txt 文件中使用基于
data-ad-host
的父级发布商 ID
方法 1:在公共后缀列表中注册
在公共后缀列表中注册某个域名后,浏览器会将该域名视为 TLD(顶级域名)。我们的 ads.txt 验证系统将执行相同的操作。在进行此项更改之前,平台应先调查此操作对其网域的完整影响。
如果某个网域存在于公共后缀列表中,则必须更改 ads.txt 文件的位置。您必须在每个子网域 (subdomain.example.com/ads.txt) 上发布 ads.txt 文件,而不是在网域的根目录 (example.com/ads.txt) 上发布 ads.txt 文件。除非另外使用了选项 2,否则 ads.txt 文件必须包含子帐号的发布商 ID,也就是以 data-ad-client
参数的值为基础。
例如,如果子帐号媒体资源代码 (data-ad-client
) 为 ca-pub-123456789012345
,ads.txt 文件将如下所示:
google.com, pub-123456789012345, DIRECT, f08c47fec0942fa0
其中,字符串的 ca-
部分已移除。
方案 2:针对平台网域的 ads.txt 特殊处理方式
通过 AFP,您可以根据 data-ad-client
或 data-ad-host
的值验证所有子帐号流量的广告请求。这意味着,如果其中任一 ID 位于 ads.txt 文件中,系统会将广告请求作为已验证进行处理。即使相应网域列在公共后缀列表中,这种处理方式也有效,唯一的区别在于 ads.txt 文件的位置。
对于大多数 AFP 平台客户,我们建议确保所有广告代码均已设置 data-ad-host
参数(或者,您也可以使用“平台帐号”元标记来确保这是这样做)。随后,ads.txt 文件将只需一个基于托管媒体资源 ID (data-ad-host
) 的条目。
例如,如果您的托管 ID (data-ad-host
) 为 ca-host-pub-1234567890123456
,ads.txt 文件将如下所示:
google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0
其中,字符串的 ca-host-
部分已移除。