在广告效果评估体系中，曝光监测（Impression Tracking）与点击监测（Click Tracking）是最核心的两个环节。曝光反映广告是否真正被用户看到，而点击则直接体现用户的主动行为。两者共同构成广告归因、投放优化、媒体评估的重要基础。
本文将系统介绍各类监测方式的原理、流程、优缺点与使用场景。
Impression 监测（曝光监测）
Web页面通过浏览器在需要展示广告时，需要从广告平台来加载广告，广告加载并展示完成后，浏览器将展示的监测数据上传给监测平台。
我们现在看一下广告请求曝光过程，广告请求可以从媒体客户端直接发出，也可以从媒体主服务端发出，媒体客户端是指浏览器或APP。
加上曝光监测后的过程：
有多种方式可以添加监测代码，现代广告曝光监测主要依赖用户浏览器或APP在广告实际渲染后向监测平台上报曝光事件。根据实现方式不同，可分为JS、API、SDK三类。
JS监测
JS（JavaScript）监测主要应用于Web场景，通过在页面中嵌入监测代码监听广告位，当广告被加载并可见后向监测平台上报曝光。
JS 监测的代码一般包含两部分：
- 一部分是基础库代码，负责初始化与监测环境加载；
- 一部分是监测代码，如曝光监测或点击监测，布署在需要跟踪的地方即可，每一个监测点都有对应的监测代码，监测代码依赖于基础库代码，如果没有基础库代码，监测代码如法正常监测发送数据。
我们来看一下数据的监测过程：
数据流转过程说明：
- 1、监测平台生成监测代码
- 2、布署到页面上去，这里的媒体主表示媒体主服务器
- 3、用户访问页面，用户在浏览器打开网站
- 4、请求页面资源，浏览器向媒体主服务器请求页面资源
- 5、返回页面资源，媒体主服务器向浏览器返回页面资源，监测代码随着下发
- 6、监听到广告位，页面会有广告平台的代码监听广告位
- 7、请求广告，告诉广告平台这里有个广告位，需要展示广告
- 8、下发广告素材，将广告所需的素材下发给浏览器
- 9、广告曝光展示
- 10、上传曝光监测数据，触发监测代码，然后上传曝光监测数据到监测平台
- 11、监测数据处理，监测平台对收到的监测数据做处理，形成报告
| 优点（Advantages） | 缺点（Disadvantages） |
|---|---|
| ✔ 不依赖 app 或广告平台合作 ✔ 开发成本低 |
✘ 无法覆盖 APP 内广告 ✘ 容易被拦截，数据可缺失 ✘ 不适合可见曝光（viewability）精确追踪 |
API监测（Client-to-Server / Server-to-Server）
API监测是指媒体方以API方式向监测平台传递监测平台认可的参数，使得监测平台可以以此进行准确的独立曝光报表计算与排查数据差异等的监测方式；
典型的就是广告展示后，媒体方从Client端以API方式将曝光数据上报给监测平台。
机制如下：
图中主要模块职能描述:
- 广告 SDK:采集监测数据并通过 API 上报监测数据到监测平台。
- 监测平台:接收各个渠道的广告 SDK 上报的监测数据，并对数据进行清洗， 分析和挖掘，生成监测结果。
- 监测终端:获取监测平台的监测结果数据，并以图形化的方式展现。
API方式灵活通用、App与移动网页均适用。但需要媒体按照API监测标准，承担部分开发工作。
API监测按传递方式分为C2S（Client to Server）API和S2S（Server to Server）API两种。
C2S：Client to Server
广告SDK或浏览器直接将曝光数据发送到监测平台，浏览器相当于是Client，是C端，所以叫C2S。这是目前最主流的模式，
应用场景包括：App 内广告、、WebView 内广告、实时加载或预加载广告
C2S主流程如下：
流程说明：
- 1、监测平台生成监测代码
- 2、布署到广告平台去，JS和API方法最大的不同是JS是布署到页面上去，API是布署到广告投放平台，需要注意，曝光和点击是两段不同的监测代码，不要搞混。
- 3、用户访问页面，用户在浏览器打开网站
- 4、请求页面资源，浏览器向媒体主服务器请求页面资源
- 5、返回页面资源，媒体主服务器向浏览器返回页面资源
- 6、监听到广告位，页面会有广告平台的代码监听广告位
- 7、请求广告，告诉广告平台这里有个广告位，需要展示广告
- 8、下发广告素材和监测代码，将广告所需的素材下发给浏览器，监测代码随着广告素材下发
- 9、广告曝光展示，
- 10、上传曝光监测数据，触发监测代码，上传曝光监测数据到监测平台
- 11、监测数据处理，监测平台对收到的监测数据做处理，形成报告
C2S按展示方式细分
- 预加载展示监测：广告提前缓存，展示时再上传曝光
- 实时加载展示监测：广告加载后即时展示并上传
下面看一下实际的数据传递方式。
预加载广告展示监测
广告SDK预先加载广告，并将广告缓存，当需要展示广告时，广告SDK负责将已预先加载并缓存的广告进行展示，并将展示的监测数据上传给监测平台。
监测流程下图所示:
流程说明:
- App在合适的场景，通过广告SDK从广告平台获取广告。
- 广告SDK 缓存广告平台所返回的广告，并根据需要进行预加载。
- App在合适的场景，通过广告SDK发起广告展示。
- 广告SDK检查缓存，若有成功缓存/预加载广告，则将该广告进行展示。
- 在广告得到实际展示后，广告SDK通过加载 tracking pixel，将广告展 示监测数据上报到监测平台，广告 SDK 在展示成功后触发 pixel tracking。
- 监测平台收集和处理上报的数据。
实时加载广告展示监测
App 通过广告 SDK 在需要展示广告时，即时的从广告平台来加载广告，广告加 载并展示完成后，广告 SDK 将展示的监测数据上传给监测平台。
监测流程下图所示:
流程说明:
- App通过广告SDK，从广告平台获取广告。
- 广告SDK实时展示广告平台返回的广告创意。
- 广告创意的主要元素加载完成后，广告SDK通过加载tracking pixel的方式，将展示数据提交到监测平台，。
- 监测平台收集和处理上报的数据，
S2S：Server to Server
曝光数据先由广告平台接收，再由广告平台服务器上传给监测平台。是服务器到服务器之间，所以叫Server to Server，简称S2S。
流程说明：
- 1、生成监测代码：监测平台生成监测代码
- 2、布署监测代码：将监测代码布署到广告平台去，需要注意，JS和API方法最大的不同是JS是布署到页面上去，API是布署到广告投放平台， 曝光和点击是两段不同的监测代码，不要搞混。
- 3、访问页面：用户在浏览器打开网站访问页面
- 4、请求页面：浏览器向媒体主服务器请求页面资源
- 5、返回页面：媒体主服务器向浏览器返回页面资源
- 6、监听到广告位：页面会有广告平台的代码监听广告位
- 7、请求广告：告诉广告平台这里有个广告位，需要展示广告
- 8、下发广告素材和监测代码：将广告所需的素材下发给浏览器，监测代码随着广告素材下发
- 9、曝光：广告曝光展示
- 10、上传曝光监测数据：触发监测代码，上传曝光监测数据到广告平台
- 11、上传到监测服务器：监测数据从广告平台上传到监测服务器
- 12、监测数据处理：监测平台对收到的监测数据做处理，形成报告
| 优点（Advantages） | 缺点（Disadvantages） |
|---|---|
| ✔不依赖客户端能力 | ✘ 无法用于可见性曝光监测（viewability）：因为可见性曝光监测的技术要求客户端发出。 ✘ 容易被媒体方“造假”曝光：从服务端发过去，容易造价，所以没有称为主流方式 ✘ 数据可信度低 |
SDK监测（主流App媒体采用）
SDK监测是媒体方在其APP内集成第三方监测平台的SDK，SDK通过内部逻辑自动监听广告展示并上传监测数据。
SDK监测的过程如下：
流程说明：
- 1、集成统一SDK：SDK监测是需要在媒体主APP集成一个SDK，建议采用行业统一SDK。
- 2、监测参数配置：广告平台上需要配置监测参数XML文档，要定制维护好这个文档。
- 3、动态加载监测参数配置：统一SDK远程动态加载存档在广告平台的监测参数XML文档，解析并保存响应的配置规则，这个是需要定制操作的，相关规则可以看 SDK配置文件更新这部分。
- 4、生成监测代码：监测平台生成监测代码
- 5、布署监测代码：将监测代码布署到广告平台去，需要注意， 曝光和点击是两段不同的监测代码，不要搞混。
- 6、打开APP：用户打开APP使用（向媒体主请求这个过程在这里省略了，直接请求广告部分）
- 7、请求广告：告诉广告平台这里有个广告位，需要展示广告
- 8、下发广告素材和监测代码：将广告所需的素材下发给浏览器，监测代码随着广告素材下发
- 9、曝光：广告曝光展示
- 10、上传到广告平台：统一SDK触发调用“提交监测”，统一SDK会按一定的规则，如根据投放管理模块传递的参数，按照监测参数配置文档， 在提供的监测 URL 后拼接 SDK 额外获取的参数(如OpenUDID，机型和操作系统、屏幕分辨率、加密的 MAC 地址等参数)，向第三方监测系统服务器提交监测请求，上传监测数据
- 11、监测数据处理：监测平台对收到的监测数据做处理，形成报告
| 优点（Advantages） | 缺点（Disadvantages） |
|---|---|
| ✔ 覆盖面最全：Web + App + 视频 + 原生广告 ✔ 能实现可见性曝光监测（MRC Viewability） ✔ 可靠性最高 ✔ 能远程动态加载监测参数（XML 配置） |
✘ 媒体需要接入额外 SDK，对性能有影响 ✘ 对媒体方的安全影响较大 ✘ 对开发工作量要求高 |
MMA规范：为了避免媒体接多个SDK（如汇量、热云、TalkingData、AdMaster 等），MMA 推出统一SDK规范，使得一个SDK可对接各家监测平台。
Click 监测（点击监测）
点击监测一般分为：
- 同步监测（302 跳转）
- 异步监测（异步上报）
监测流程下图所示:
流程说明:
- (1) 用户点击广告。
- (2) 广告SDK处理点击事件。
- (3) 广告SDK将计费通知给广告平台。
- (4) 广告平台进行计费等事件处理。
- (5) 广告SDK异步将测数据上报到第三方监测平台。
同步监测（302重定向）
当用户点击广告时，点击行为首先访问监测方提供的监测链接。该链接会将请求发送至监测平台服务器，监测平台记录相关曝光与点击数据后，通过302重定向将用户引导至最终落地页。接着，用户继续加载真实落地页内容。这种机制适用于大多数移动浏览器场景中的点击监测。
需要注意的是，同步跳转监测不支持回传IDFA等设备级参数，因此在精细归因或深度追踪上存在一定限制。
用户点击广告后，跳转流程如下:
流程说明:
- 1)用户点击广告
- 2)浏览器处理点击事件
- 3)浏览器将监测数据上报给监测平台。
- 4)监测平台收集和处理上报的数据
- 5)监测平台计数完成后进行 302 重定向到目标站点。
备注：如果需要计费处理，则浏览器首先将计费通知给广告平台，计费处理后302重定向到监测平台，将监测数据上报给监测平台，计数完成后再次 302 重定向到目标站点。
| 优点（Advantages） | 缺点（Disadvantages） |
|---|---|
| ✔ 结构简单 ✔ 数据准确 |
✘ 跳转慢，可能影响用户体验 ✘ 不支持回传设备 ID |
异步监测（异步上报）
当用户点击广告时，浏览器首先触发点击事件处理流程。在跳转至目标落地页的同时，浏览器会以异步方式将点击数据上报至监测平台。
这种方式非常适用于广告平台或媒体内部存在特殊跳转逻辑、或目标URL本身需要进行内部多级跳转的场景。
用户点击广告后，跳转流程如下：
流程说明:
- (1)用户点击广告
- (2)浏览器处理点击事件
- (3)浏览器跳转到目标站点的同时将监测数据异步上报给监测平台。
- (4)监测平台收集和处理上报的数据
备注:如果需要计费处理，则浏览器将计费通知给广告平台，并且异步将监测数据上报给监测平台。
| 优点（Advantages） | 缺点（Disadvantages） |
|---|---|
| ✔ 体验最佳，不影响跳转速度 ✔ 可上报更多参数（如IDFA、GAID） ✔ 适用于 App 场景、复杂跳转场景 |
✘ 数据可能丢失（请求未发送成功） ✘ 需要广告平台配合 |
总结：各种监测方式的对比
Impression监测方式对比
| 方式 | 精准度 | 场景 | 开发成本 | 可见性曝光 | 数据造假风险 |
|---|---|---|---|---|---|
| JS 监测 | 中 | Web | 低 | 弱 | 中等 |
| C2S API | 高 | Web / App | 中 | 中 | 中低 |
| S2S API | 低 | 特殊场景 | 低 | ✘ | 高 |
| SDK 监测 | 最高 | App、视频、直播 | 高 | ✔ | 最低 |
Click 监测方式对比
| 方式 | 跳转体验 | 支持参数（IDFA） | 数据丢失风险 | 推荐场景 |
|---|---|---|---|---|
| 同步（302） | 较慢 | ✘ 不支持 | 低 | Web 普通广告 |
| 异步 | 最好 | ✔ 支持 | 中 | App 内广告、复杂跳转 |
