可见性与广告验证：MRC、OMID与品牌安全

在程序化交易模式中，那张「可见 × 非 IVT × 品牌安全」的折损表，将名义 CPM 拆解成了真实的合格曝光成本。如果说反作弊与 IVT 解决的是「流量背后是不是真人」的问题，那么本篇要探讨的，则是剩下的两道关卡——广告是否真正被用户看见，以及广告出现的上下文环境是否会损害品牌形象。在业内，这些工作通常被统称为 Ad Verification（广告验证），涵盖了可见性（Viewability）、品牌安全（Brand Safety）、品牌适宜性（Brand Suitability），有时还会附带流量质量的标签。

正因如此，在公开的程序化交易市场中，即便 Impression 像素成功触发，也并不意味着用户真正看到了广告。进一步来说，即便用户看到了广告，广告旁边也可能充斥着仇恨言论或成人内容。一旦品牌广告主（Advertiser）决定按照可见 CPM（viewable CPM）进行结算，并依据验证厂商的标签来拒付违规流量，需求方平台（DSP）与 Trading Desk 的底层账本就必须与供给方（SSP）的承诺保持绝对一致。否则，一旦发生争议，需求方与供给方只会陷入各说各话的泥潭。

本文是归因与度量系列的第 3 篇（可见性与验证）。 全系列 3 篇：

归因与结算：MMP、SKAN 与 SSOT

反作弊与 IVT

可见性与广告验证

一句话定位：买方工程视角的可见性与验证：MRC/OMID、品牌安全、IAS/DV；Pre-bid 降权与 post-bid 算账、Join 键与标签窗口、合同对账口径。

TL;DR

像素送达 ≠ 用户看见 ≠ 环境安全 ≠ 真人合格：如果将这些概念笼统地揉成「流量质量」，最终会导致报表口径无法对齐。
MRC 标准：展示广告需满足面积 ≥ 50% 且持续 ≥ 1 秒；视频广告需满足面积 ≥ 50% 且持续 ≥ 2 秒。Impression 像素的触发绝不等于 viewable（可见）。
OMID 机制：它是一个测量会话（session），验证厂商的脚本挂载其上。在 Pre-bid 阶段利用历史评分进行降权，而在最终结算时，则严格认准时间窗口内的厂商标签。
合同约束：必须在合同中写死可见率的分母（是 measurable 还是 served）以及标签回传的时间窗口。需要强调的是，流量不可测（unmeasurable）往往比可见率偏低更能破坏品牌 Deal。

Open Table of contents

1. 问题：后台曝光很好看，品牌却说没看见或不安全
2. 别和 IVT、供应链混在一起
3. MRC：面积够不够，停够不够久
4. OMID：测量会话，不是另一枚像素
5. 品牌安全与适宜性：旁边放了什么
6. IAS / DoubleVerify：在链路上干什么
7. 怎么进账：Pre-bid、标签、Join、合同
8. 渠道不一样，难点也不一样
9. 上线后看什么
延伸阅读

1. 问题：后台曝光很好看，品牌却说没看见或不安全

在买方（Buy Side）的认知里，广告曝光（Impression）是一个极其明确的动作。但一旦落到合同条款和实际争议中，它往往会演变成截然不同的概念：

预期购买的资产	产生争议时的真实场景
一次计费 Impression	广告在折叠下方一闪而过，面积不够 50% 或没停满 1 秒。虽然像素照打、钱照扣，但 MRC 却不认 viewable。
「可见率很高」的版位	厂商标记了大量 unmeasurable。可能是因为容器锁死、跨域 iframe 或 OMID 启动失败，导致会话建不起来。
干净内容旁的展示	邻接是敏感新闻、仇恨言论或成人内容；或者是同页别的广告位把环境带脏了。
视频完播	后台 tab 或静音自动播。播放头在空转且四分位很好看，但人根本没在看。
完播率异常地高	设备农场自动「看完」领激励。需要强调的是，这是 IVT，不是可见性问题（详见反作弊）。

程序化交易模式 §8 曾用简化的数字算过一笔账：PG（程序化保量）和实时竞价（RTB）的名义 CPM 相差 7.5 倍。然而，如果按照「可见 × 非 IVT × 品牌安全」的漏斗折算完，两者在合格单位成本上的差距会大幅缩小。因此，在漏斗分析和最终结算时，必须使用「合格曝光」作为分母。否则，系统的优化逻辑只会错误地奖励那些「狂打像素、却极少被真实用户看见」的劣质库存。

2. 别和 IVT、供应链混在一起

在销售话术中，几个截然不同的概念经常被笼统地揉进「verification」里。但在工程实现上，必须将它们严格区分开来：

维度	核心关注点	典型输出结果
可见性（Viewability）	广告算不算被看见	viewable / non-viewable / unmeasurable
品牌安全（Brand Safety）	环境会不会硬伤品牌	风险分级、拦截或放行
适宜性（Brand Suitability）	品类是否适合该内容环境	情绪分析 / 垂直领域分段
IVT（无效流量）	流量背后的「人」真不真、行为合不合格	GIVT / SIVT（详见反作弊）
供应链（Supply Chain）	交易路径真不真、谁获得了授权	ads.txt / schain（详见供应链透明度与优化）

当然，概念之间的重叠在所难免。例如，像素填充（pixel stuffing）既导致广告看不见，也常被判定为 SIVT（复杂无效流量）；而 MFA（Made For Advertising）站点的 viewable 可能极高，但其品牌适宜性却极差。因此，在排查故障时，首先要搞清楚——你当前正在核对的，究竟是「看见」、是「环境」，还是「人」。

3. MRC：面积够不够，停够不够久

目前，品牌广告主和验证厂商大多遵循 MRC（Media Rating Council）的可见性指南（具体执行以当期文本和合同约定为准）：

MRC 可见性：左侧展示广告像素≥50%且连续可见≥1秒；右侧视频像素≥50%且播放头推进、连续可见≥2秒 需要注意的是，如果广告中途滚出视口，计时一般要重置。部分 Agency 甚至会提出 100% 面积 × 1 秒的严苛要求，这比 MRC 的标准更狠。

维度	展示广告	视频广告
面积要求	广告与视口相交 ≥ 50%	同样要求 ≥ 50%，且播放动作必须真实有效
时长要求	连续可见 ≥ 1 秒	连续可见 ≥ 2 秒
常见踩坑点	首屏硬堆、狂刷新、1px 钻空子	后台 tab 播放、画中画、SSAI 信标与实际几何尺寸对不上

在数据看板中，至少需要将曝光拆分为三列，切忌混用一个笼统的「曝光」指标：

Served / rendered：创意成功送达或渲染完成（常见于 VAST Impression、展示像素触发）。
Viewable：成功通过了 MRC（或合同约定）的「面积 × 时长」双重校验。
Measurable：验证脚本成功启动了会话，且能够测量到几何数据。当流量测不到时，有的报表会直接将这部分样本踢出 viewable 的分母，有的则会单独标记为 unmeasurable。

在这里，viewable rate 的计算公式究竟是 viewable / measurable 还是 viewable / served，必须在合同中写死。一旦分母发生替换，所有的渠道对比数据都将作废。关于媒体（Publisher）如何利用懒加载、自动刷新等手段抬高可见率，详见 Web 变现 §5–6。而站在买方（Buy Side）的立场，你必须明确：你付出的预算，究竟认的是哪一列数据。

4. OMID：测量会话，不是另一枚像素

IAB Open Measurement（OMID / OM SDK）的诞生，旨在解决一个极其具体的痛点：在 Web、App 以及视频容器中，提供一套统一的会话机制来采集几何数据和播放状态，随后再将其分发给各家验证厂商。这样一来，就避免了每家厂商各自塞入一套脚本、导致互相冲突的乱象。

对于买方而言，记住以下几条核心原则即可：

容器负责启动 OM session；而验证脚本仅仅是订阅方。需要强调的是，它绝对无法替代 Impression 像素的作用。
在 OpenRTB 协议中，只有当 imp.*.api[] 字段带上了 7（代表 OMID）时，品牌 Deal 才敢于在谈判桌上讨论「可测性」。
对于视频广告，必须将 playhead（播放头进度）和暂停状态实时喂进会话中，否则「正在播放」与「实际可见」的数据将永远对不齐。

至于渲染引擎如何挂载、以及为什么 VPAID 的 AdLoaded 事件不能作为测量信号，详见 VAST / MRAID 渲染。在验收阶段，务必多盯紧两列数据：OMID start 的成功率与延迟（一旦会话没起来，该次曝光就是 unmeasurable）；以及厂商标签与内部 served 数据的对齐率（如果延迟正常，但对齐率突然暴跌，多半是因为容器嵌套或 Wrapper 层级太深）。

5. 品牌安全与适宜性：旁边放了什么

如果说可见性关注的是物理几何，那么品牌安全关注的则是邻接内容是否会砸了品牌的招牌。在销售话术中，这两者统称为 verification，但在工程落地时，最好将它们分列处理。

品牌安全（Brand Safety） 关注的是是否存在硬伤——例如仇恨言论、色情内容、极端暴力等。针对这类风险，常规动作是硬拦截（Pre-bid no-bid），或者在事后坚决拒付。其判定信号主要来自页面或 App 的分类、关键词提取，以及邻接创意的上下文。

品牌适宜性（Brand Suitability） 则更为细腻：它评估的是这段内容是否适合你的特定品类。例如，一篇中性的突发新闻对于奢侈品而言是「安全」的，但未必「合适」。针对适宜性，常规动作多半是分段出价、设置白黑名单、或者由广告主自定义受众段，而不是简单粗暴的一刀切。

在实务操作中，有几个极易踩坑的点：

静态的域名黑白名单虽然成本低廉，但往往存在严重的滞后性。对比前一种方案，上下文分类虽然更准，却往往需要等待渲染完成或依赖近线标签的回传。
新闻大站的敏感报道极易被系统误判为高风险。当品牌追求「绝对安全」时，其 fill rate（填充率）和 CPM 必然会随之波动。
需要强调的是，安全环境里的刷量行为，依然属于 IVT（无效流量）的管辖范畴；只有脏内容旁的真人可见曝光，才是品牌安全需要解决的问题。切忌将这两本账混为一谈。

6. IAS / DoubleVerify：在链路上干什么

对于买方工程而言，IAS、DoubleVerify 以及同类验证厂商的核心价值大致分为三块：测量可见性（支撑合同中的 viewable CPM 结算、评估渠道质量）、监控品牌安全与适宜性（执行拦截、分段出价、提供争议证据）。部分厂商还会兼做 IVT 的抽检，以此增强对外说服力（至于如何与自建规则拆分，详见 IVT §7）。

它们与自建系统的分工，与反作弊篇的逻辑高度一致：

维度	自建系统	验证厂商
适合干什么	Pre-bid 降权 / 黑名单拦截、与席位评分及 SPO 深度绑定	提供 MRC 认证口径、支撑合同认账、跨买方样本比对
短板	缺乏对外争议的权威证据、跨库内容分类能力较弱	标签存在延迟、依赖采样、热路径调用成本过高
常见用法	核算内部合格成本、计算席位质量分	作为结算条件、出具品牌报告、提供争议证据包

在工程落地时，遵守几条纪律便足够应对：在热路径（Hot Path）上，绝对不要同步调用厂商的 API，这会直接吃满 tmax（超时阈值）。正确的做法是使用预计算的分数或近线回灌的查表。在结算扣量时，必须严格以合同中写明的厂商和口径为准；内部风控可以判得更严，但对外拒付时必须能对上合同里的名字。此外，两家厂商的 viewable% 相差几个百分点是常态，切忌拿来互撕；内部依然要算清自己的可结算合格曝光。

验证链路四段：①渲染挂载（容器/OM SDK/验证脚本）→②测量会话（几何/播放态/上下文）→③厂商标签（viewable/品牌安全/适宜性）→④买方落地（看板争议/席位评分/结算条件） 挂载和会话发生在客户端；而标签的回传经常会晚几个小时。因此，竞价时使用的是昨天的历史分，结算时则必须等标签到齐后再进行校正。

7. 怎么进账：Pre-bid、标签、Join、合同

验证工作绝不是「渲染完打个脚本」就宣告结束。在资金流转的链路上，至少存在两个关键截点：在竞价前（Pre-bid），利用历史分挡掉劣质流量；在竞价后（Post-bid），拿到厂商标签进行最终的算账。

7.1 Pre-bid 与 post-bid 各干什么

维度	Pre-bid（请求级）	Post-bid（曝光后）
输入信号	席位 / 域名的历史 viewable 评分、品牌安全分段、预审名单；偶见 OpenRTB 的 `bcat` / `battr` 与上下文段	OMID 会话 + 厂商测量脚本 → 生成曝光级标签
执行动作	no-bid（不竞价）、降权、切换 Deal、硬拦截高风险品类	看板数据校正、席位评分回灌、按合同剔除无效量 / 发起争议
延迟要求	必须控制在亚毫秒级；仅允许查询本地表	标签通常会晚几小时甚至一天到达
禁忌操作	同步调用厂商实时 API，导致吃满 `tmax`	使用尚未到齐的标签进行当日的最终结算

Pre-bid 拦截的逻辑是：「这类库存过去就不干净或看不见，所以这次也不投」。但真正决定某次曝光算不算 viewable、安不安全的，依然必须以 post-bid 回传的标签（以及合同指定的厂商）为准。历史分仅仅是一个代理指标，其回灌窗口详见 §7.3。

7.2 曝光后闭环

渲染成功后，系统会启动 OMID session 和厂商测量脚本。会话事件（涵盖几何数据、播放态、上下文）经过厂商的后处理，转化为曝光级或聚合标签。随后，买方再按日 join（关联）竞价日志：在看板上核对 viewable、measurable 与 unsafe 数据，并将 seatScore 回灌供次日 Pre-bid 使用。在最终结算时，则严格按照合同剔除 non-viewable / unsafe 的流量，或将其打入争议池。

在结算环节，必须按合同依次核对：GIVT 是否必须剔除；是否严格按照 viewable 付费（unmeasurable 和 non-viewable 的流量究竟是拒付、按 served 付费，还是进入争议池）；品牌安全是否执行硬拦截。此外，席位评分可以将可见性、安全分和历史 IVT 综合在一起，喂给 SPO（供应链优化）和出价模型进行降权——在此过程中，厂商的 viewable% 仅仅是输入特征之一。

7.3 Join 键与标签延迟

如果标签回传了，却无法对上竞价日志，那就等于没回传。因此，在落地前必须先约定好以下细节：

关键点	实务操作指南
Join 键	优先使用稳定的 `bidid` / `auction_id`（或双方约定的 impression id）；厂商标识必须在创意宏或 VAST 中带出去，同时竞价日志必须同步落库。
键丢了	Wrapper 层级过深、宏替换失败、S2S 传输丢字段，会导致对齐率暴跌；这绝不是「可见率真掉了」。
延迟处理	常见延迟为 T+数小时到 T+1；部分合同甚至给到 T+7 才正式关窗。
重跑机制	标签晚到后，必须按窗口重跑结算批次；当天的看板数据仅用作代理指标，切忌将 T+0 视为最终账单。
双厂商并存	并存时必须在合同中写明「结算认谁、抽检认谁」；绝对不要将两家的百分比加权平均出一个所谓的「真理」。

对齐率（成功 join 的标签数 / 应测曝光数）必须与 viewable rate 分列展示。一旦对齐率骤降，首先排查 Join 键和宏替换是否正常，其次再查几何数据的采集。

7.4 合同里先写死的几行

一旦争议爆发，工程做得再准，也救不了「合同没写」的尴尬。因此，至少需要提前对齐以下条款：

合同条款	为什么要命
指定验证商	结算 / 拒付究竟认哪一家（需明确到版本和产品线）。
付费口径	是 served CPM、viewable CPM，还是「达标才付」。
viewable 分母	是 measurable 还是 served；unmeasurable 究竟算拒付、按 served 付费，还是直接进争议池。
可见门槛	是采用 MRC 默认标准，还是 Agency 提出的加严标准（如 100%×1s）；视频是否需要另议音量或大屏口径。
标签窗口	几天内到齐的标签算数；逾期未到的标签如何处理。
采样机制	是全量覆盖还是抽样检测；抽样结果如何外推至整体账单。
品牌安全动作	是预审拦截、事后拒付，还是要求 make-good（补量）；适宜性是执行硬拦截还是仅仅分段出价。
证据包要求	发起争议时需要提供哪些字段（如会话 id、时间戳、URL/App、标签原文等）。

内部的优化策略可以比合同更为严苛；但对外的扣款动作，必须能够精准指回合同里约定的厂商名和口径名。

8. 渠道不一样，难点也不一样

渠道类型	可见性容易栽在哪	验证侧需要多盯什么
Web 展示	折叠下方、自动刷新、跨域 iframe 嵌套	SafeFrame / OMID 的挂载情况、懒加载触发后是否还能测得到
App 环境	WebView 几何尺寸获取困难、多 SDK 抢夺容器控制权	OM SDK 的版本兼容性、MRAID 容器是否具备可测性
视频广告	播放头进度与几何可见性脱节	VAST 状态与 OMID 的同步；四分位数据 ≠ viewable；音量要求是否进合同需另议
CTV / SSAI	「正在播放」绝不等于「有人在看」	信标与服务端的缝合准确性；大屏几何 / MRC 标准通常需合同另议，切忌拿手机展示口径硬套

在视频广告中，start / 四分位 / complete 仅仅代表播放进度，而 viewable 依然要求「面积 × 时长（以及播放态）」同时成立。关于大屏环境的特殊性，详见 CTV / OTT 与 SSAI；端上环境详见 App 广告 SDK。此外，激励视频还需要严防奖励回调造假——那是 IVT 和端上安全需要解决的问题，千万别指望一张 viewable 标签就能单独搞定。

9. 上线后看什么

内部的监控看板和厂商提供的仪表盘，最好拆分开来独立查看：

监控指标	大致含义	实务怎么用
`measurable_rate`	可测曝光 / served 曝光	骤降时，首先排查容器嵌套、OMID 启动状态、脚本挂载是否正常
`viewable_rate`	viewable / measurable（必须写清分母）	评估渠道和版位质量；支撑合同对账
`unmeasurable_share`	测不到的流量占比	评估品牌 Deal 是否还敢继续买入
标签对齐率	成功 join 的标签数 / 应测曝光数	骤降时，首先查 bidid / 宏替换 / Wrapper 层，其次再查几何数据
品牌安全拦截 / 风险分布	预审拦截量 + 事后标签判定量	必须分清是误杀还是漏放
争议金额 / make-good	结算扯皮涉及的金额	评估合同口径和证据包是否足够硬核
合格 CPM	名义支出 ÷ 合格（viewable ∧ safe ∧ non-IVT）曝光	比单独看一个 viewable% 更贴近真实的业务成本
标签延迟与窗口覆盖	关窗前标签到齐的比例	评估回灌机制和重跑结算的窗口是否够用

排障与调优口诀： 务必将分母和 Join 键写进合同与创意宏中；不可测往往比可见率低更能破坏品牌 Deal；Agency 门槛可能比 MRC 更严苛；标签晚到必须等关窗后重跑结算；面对新闻库存切忌一刀切黑名单拦截；遇像素填充先看可见性会话，遇域名伪装先查 ads.txt；两家厂商数据不要互撕，争议只认合同指定那一家。

下一篇，我们将探讨当广告成功展示且被看见后，如何将转化归因到具体的渠道。