广告平台的无效流量过滤：哪些可以由你的团队自建，什么时候该购买验证服务商

一般无效流量的过滤自己做，复杂无效流量的检测向验证服务商购买，除非你负担得起自己的反欺诈团队。一般无效流量，例如已知的数据中心地址、已声明的机器人和不可见的 1x1 广告，用名单和规则就能拦下。你自己的工程师可以在请求到达时执行这些规则，并在日志里再执行一次。复杂无效流量，例如被劫持的设备和冒充的应用，需要远超单个平台所能看到的流量数据，还需要专门研究它的分析师。像 TAG 这样的认证计划也期望由合格的第三方进行过滤。

什么算无效流量？

Media Rating Council（MRC）是美国负责认证广告测量的机构。它的 Invalid Traffic Detection and Filtration Standards Addendum（2020年6月更新版，与此处其他资料一样，于2026年10月27日查阅）把无效流量分为两类。一般无效流量，即 GIVT，是“通过常规过滤手段识别的流量，这些手段通过应用名单或其他标准化参数检查来执行”。MRC 举的例子包括：

• 来自数据中心的已知无效流量
• 机器人、蜘蛛和其他爬虫
• 来自非浏览器 user agent 或未知浏览器的请求
• 预取或预渲染、但没有真实用户随后查看的页面
• 不可见的展示位，例如 0x0 或 1x1 像素的广告

复杂无效流量，即 SIVT，涵盖“更难检测的情况，需要高级分析、多点佐证或协同、大量人工介入等才能分析和识别”。MRC 举的例子包括：

• 自动化软件和模拟器
• 被感染和被劫持的设备
• 有组织的付费人工活动，例如点击农场
• 强制点击和强制跳转
• 伪造的测量事件
• 冒充的域名和应用

我们自己的工程师能自建哪些过滤？

一般类型的过滤本来就是为共享而设计的。MRC 指出，GIVT 过滤“旨在在各服务商之间保持一致”，因此它依赖通用名单。内部团队使用其中两份：

• IAB/ABC International Spiders & Bots List，由 Alliance for Audited Media 代表 IAB Tech Lab 维护
• Data Center IP List，由 Trustworthy Accountability Group（TAG）每月发布

在名单之外，团队还要为 user agent、广告尺寸和预取请求编写规则，在请求到达时执行，并在记录事件时再执行一次。团队还要记录每一个被过滤的请求及其原因，以便向合作伙伴解释数字。

对于它所审计的测量公司，MRC 为数据中心流量设定了一个起点。这些公司必须过滤来自“三家已知最大的托管机构：Amazon AWS、Google 和 Microsoft”IP 地址的无效流量。同时设有例外，以免误过滤通过这些网络上网的真实用户。

过滤可以发生在两个时间点。事前，平台拦截广告请求，或者不对它出价。事后，平台从日志和统计中删除无效事件。MRC 写道：“每种技术都有一定的优点和缺点，两者在执行良好的流量保护策略中都有一席之地。”尽早拦截还能省下处理那些之后反正会被丢弃的请求的成本。

随着浏览器和应用共享的数据越来越少，名单的作用在减弱。在2024年的更新中，MRC 是这样说的：“IP 地址受限或缺失，以及 User Agent（UA）字符串的粒度降低，可能会削弱基于名单的方法。”

什么时候值得付费请验证服务商？

复杂流量的检测依赖于在众多发布商、应用和设备之间发现规律，也依赖于随新手法出现而持续跟踪的分析师。一个平台只能看到自己的流量，所以会漏掉那些只有放在众多平台中才能显现的规律。能把这件事做好的团队，相当于你公司内部的一家反欺诈公司。

认证可能直接决定答案。TAG 的 Certified Against Fraud 计划把下面这一条列为关键要求之一：“其 100% 的可变现交易由合格的第三方进行 IVT 检测和清除过滤”。TAG 允许发布商通过持有有效认证标识的供应方平台来满足这项要求。如果你的买方或合作伙伴要求 TAG 认证，仅靠你自建的过滤器无法满足这项要求。

MRC 公布了它所认证的服务名单。其数字领域名单包括 DoubleVerify、HUMAN、Integral Ad Science、Pixalate 和 Protected Media 等验证公司。认证覆盖的是具体的服务和指标，所以要问服务商它的哪些服务获得了认证，其中是否包括复杂无效流量。

自建、购买还是两者结合：每条路线覆盖什么？

• 只靠自建：你用工程师的时间和必要的名单订阅费用拦下一般无效流量，规则和数据归你所有。复杂的手法会漏过去，由第三方过滤的要求也无法满足。
• 只靠服务商：两类流量都能检测出来，但每一个决定都依赖服务商的系统和收费，而且放在竞价链路里的服务商检查会给每个请求增加时间。
• 两者结合：你自己的过滤器尽早、低成本地剔除明显的无效流量，服务商只看到通过这些过滤器的流量。

无论走哪条路线，平台都需要记录什么？

负责检测的一方需要每笔广告交易的细节。MRC 列出了测量公司在可能情况下必须采集的字段，其中包括：

• 事件类型、交易 ID 和时间戳
• IP 地址，包括流量经过代理时的 X-Forwarded-For 请求头
• 完整的 user agent 字符串和设备类型
• 应用标识，或展示广告的页面的完整 URL
• 发布商、网站和展示位的 ID，以及发布商的 ads.txt 或 app-ads.txt 信息
• 竞价请求中的 OpenRTB 属性

报表应把原始数字和过滤后的数字分开。对于营销活动报表，MRC 的标准列出了“Gross Metrics (Completely Unfiltered)”和“Net Metrics (Filtered for GIVT Requirements)”。在适用的情况下，经复杂无效流量过滤后的数字作为单独一步列出。如果你的事件管道本来就会丢失事件或重复计数，先修好这个问题：过滤无法修复在它运行之前就已经错了的数字。

该问把过滤功能接入我们平台的公司哪些问题？

• 每个过滤器在竞价链路的哪个位置运行？会给一个请求增加多少时间？
• 如果服务商的检查没有及时响应，请求是放行还是丢弃？
• 名单如何更新？谁来核查真实用户没有被误过滤？
• 原始数字和过滤后的数字会如何出现在我们的报表以及合作伙伴的报表里？
• 每个请求的哪些字段会被存储？存多久？遵循哪些隐私规则？

最后一个问题对 MRC 也很重要。它在2024年的更新中写道：“隐私法规不是需要用工程手段绕过的障碍，而是必须遵守的硬性要求”。

amBrain 在其中处于什么位置？

发布本博客的 amBrain 构建的是过滤功能所接入的那些系统。它的一句话是：“amBrain 构建广告服务器：定向、频次控制和报表。”另一句是：“amBrain 为广告技术构建事件分析管道：展示和点击事件的采集、处理与报表。”它在 AdTech 领域的工作包括为一家客户开发的需求方平台 RTBBidder。

amBrain 自 2019 年起开发软件，有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。它关于所有权的说法是：“客户拥有产品与代码的全部所有权，我们的可复用组件除外。”

本文不是案例研究。本文并未声称 amBrain 为任何客户构建过欺诈检测，也未声称它提供验证服务。如果 amBrain 在你的候选名单上，就给它和其他任何公司同样的问题。