广告/曝光监测有两个核心：Impression监测和Click监测。
其中Impression监测按实现方式可以分为JS监测、API监测和SDK监测三种，目前主要要是API和SDK这两种。
Impression监测
Web 页面通过浏览器在需要展示广告时，需要从广告平台来加载广告，广告加载并展示完成后，浏览器将展示的监测数据上传给监测平台。
我们现在看一下广告请求曝光过程，广告请求可以从媒体客户端直接发出，也可以从媒体主服务端发出，媒体客户端是指浏览器或APP。
加上曝光监测后的过程：
有多种方式可以添加监测代码， 而且如何发给监测平台也可以分成不同的类型，一般根据实现方式可以分为JS、API和SDK，下面看这种三种方式是如何实现和如何进一步细分：
JS监测
JS监测就是在页面布署代码JS代码主动监听，然后想监测平台发送数据。
在HTML页面中使用JavaScript检测代码时，建议将代码放置到页面底部位置，若代码是异步加载技术而执行进程不影响网页正常展示，也可以放置到靠前位置。
JS代码分为两部分，一部分是基础库代码，所有的页面都需要布署，布署在页面源代码的 <head> 和 </head> 之间，基础库代码是异步加载，所以不会影响页面本身的加载速度；另一部分是监测代码，如曝光监测或点击监测，布署在需要跟踪的地方即可，每一个监测点都有对应的监测代码，监测代码依赖于基础库代码，如果没有基础库代码，监测代码如法正常监测发送数据。
可以结合Google Analytics去理解，上述的基础库是Tracking Code，而监测代码就是事件跟踪代码，曝光监测就是元素可见性，GTM的元素可见形可以实现类似的曝光跟踪，详细的可以看： 元素可见性触发器
我们来看一下数据的监测过程：
流程说明：
- 1、监测平台生成监测代码
- 2、布署到页面上去，这里的媒体主表示媒体主服务器
- 3、用户访问页面，用户在浏览器打开网站
- 4、请求页面资源，浏览器向媒体主服务器请求页面资源
- 5、返回页面资源，媒体主服务器向浏览器返回页面资源，监测代码随着下发
- 6、监听到广告位，页面会有广告平台的代码监听广告位
- 7、请求广告，告诉广告平台这里有个广告位，需要展示广告
- 8、下发广告素材，将广告所需的素材下发给浏览器
- 9、广告曝光展示
- 10、上传曝光监测数据，触发监测代码，然后上传曝光监测数据到监测平台
- 11、监测数据处理，监测平台对收到的监测数据做处理，形成报告
这种方式先需要在页面布署一段JS跟踪，这是基础跟踪代码，然后再对需要跟踪的位置做具体的跟踪。
API监测
API监测是指媒体方以API方式向监测平台传递监测平台认可的参数，使得监测平台可以以此进行准确的独立曝光报表计算与排查数据差异等的监测方式；
典型的就是广告展示后，媒体方从Client端以API方式将曝光数据上报给监测平台。
机制如下：
图中主要模块职能描述:
- 广告 SDK:采集监测数据并通过 API 上报监测数据到监测平台。
- 监测平台:接收各个渠道的广告 SDK 上报的监测数据，并对数据进行清洗， 分析和挖掘，生成监测结果。
- 监测终端:获取监测平台的监测结果数据，并以图形化的方式展现。
API方式灵活通用、App与移动网页均适用。但需要媒体按照API监测标准，承担部分开发工作。
API监测按传递方式分为C2S（Client to Server）API和S2S（Server to Server）API两种。
C2S
C2S即Client to Server，客户端直接发送给监测平台服务器，是指:通过用户客户端的监测 URL 发送监测请求，完成监测，属于比较常规的监测合作。
流程如下：
流程说明：
- 1、监测平台生成监测代码
- 2、布署到广告平台去，JS和API方法最大的不同是JS是布署到页面上去，API是布署到广告投放平台，需要注意，曝光和点击是两段不同的监测代码，不要搞混。
- 3、用户访问页面，用户在浏览器打开网站
- 4、请求页面资源，浏览器向媒体主服务器请求页面资源
- 5、返回页面资源，媒体主服务器向浏览器返回页面资源
- 6、监听到广告位，页面会有广告平台的代码监听广告位
- 7、请求广告，告诉广告平台这里有个广告位，需要展示广告
- 8、下发广告素材和监测代码，将广告所需的素材下发给浏览器，监测代码随着广告素材下发
- 9、广告曝光展示，
- 10、上传曝光监测数据，触发监测代码，上传曝光监测数据到监测平台
- 11、监测数据处理，监测平台对收到的监测数据做处理，形成报告
这个过程里面，监测数据是直接浏览器端直接上传到监测平台的，浏览器相当于是Client，是C端,所以是C2S。
按照展示机制的不同可以分为预加载广告和实时加载广告展示监测。下面看一下实际的数据传递方式。
预加载广告展示监测
广告SDK预先加载广告，并将广告缓存，当需要展示广告时，广告SDK负责将已预先加载并缓存的广告进行展示，并将展示的监测数据上传给监测平台。
监测流程下图所示:
流程说明:
- App 在合适的场景，通过广告 SDK 从广告平台获取广告。
- 广告 SDK 缓存广告平台所返回的广告，并根据需要进行预加载。
- App 在合适的场景，通过广告 SDK 发起广告展示。
- 广告 SDK 检查缓存，若有成功缓存/预加载广告，则将该广告进行展示。
- 在广告得到实际展示后，广告 SDK 通过加载 tracking pixel，将广告展 示监测数据上报到监测平台，数据格式参考本标准第 6 节。推荐的实 现方式参考 第 12 节 [2] 和 [3]，广告 SDK 在展示成功后触发 pixel tracking。
- 监测平台收集和处理上报的数据，详见本标准第 7.1 节。
实时加载广告展示监测
App 通过广告 SDK 在需要展示广告时，即时的从广告平台来加载广告，广告加 载并展示完成后，广告 SDK 将展示的监测数据上传给监测平台。
监测流程下图所示:
流程说明:
- App 通过广告 SDK，从广告平台获取广告。
- 广告 SDK 实时展示广告平台返回的广告创意。
- 广告创意的主要元素加载完成后，广告 SDK 通过加载 tracking pixel的方式，将展示数据提交到监测平台，。
- 监测平台收集和处理上报的数据，
S2S
S2S即Server to Server，媒体方回传给媒体方务器，媒方服务器再将数据发送给监测平台服务器。
S2S不能作为可见性曝光的监测，因为可见性曝光监测的技术要求是计数请求信号应从客户端而非服务器端发出。
流程说明：
- 1、生成监测代码：监测平台生成监测代码
- 2、布署监测代码：将监测代码布署到广告平台去，需要注意，JS和API方法最大的不同是JS是布署到页面上去，API是布署到广告投放平台， 曝光和点击是两段不同的监测代码，不要搞混。
- 3、访问页面：用户在浏览器打开网站访问页面
- 4、请求页面：浏览器向媒体主服务器请求页面资源
- 5、返回页面：媒体主服务器向浏览器返回页面资源
- 6、监听到广告位：页面会有广告平台的代码监听广告位
- 7、请求广告：告诉广告平台这里有个广告位，需要展示广告
- 8、下发广告素材和监测代码：将广告所需的素材下发给浏览器，监测代码随着广告素材下发
- 9、曝光：广告曝光展示
- 10、上传曝光监测数据：触发监测代码，上传曝光监测数据到广告平台
- 11、上传到监测服务器：监测数据从广告平台上传到监测服务器
- 12、监测数据处理：监测平台对收到的监测数据做处理，形成报告
这个过程里面，监测数据是先从浏览器端直接上传到广告平台，然后才广告平台上传到监测平台，广告平台是服务器，是Server，是S端,所以是S2S,
Server to Server 是指:服务器端对服务器端传输监测数据的监测方式。
服务器对服务器传输监测数据的监测方法，只在某些特殊情况下使用。如当无法在用户客户端执行监测代码，并且曝光、点击不是判断标准或者结算的 KPI 时，为达到监测目的，
目前C2S是主流，S2S的也还存在，由于S2S是通过媒体方服务器发，所以造假是很方便的，一般非大型的平台的，说采用这个方式是不可信的。也有些大型平台提供S2S，如头条平台对于第三方点击监测的数据是server to server的发送方式。
SDK 和 C2S(Client-to-Server)API 比 S2S (Server- to-Server)API 更为安全、也更容易监测流量异常情况。
SDK监测
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、监测数据处理：监测平台对收到的监测数据做处理，形成报告
集成的监测 SDK 需要通过媒体及第三方监测的认证，因为实现广告数据监测认证的第三方监测平台提供的监测 SDK，集成在广告媒体应用内，可以远程动态加载广告内容和监测参数，并向第三方监测服务器发送监测数据。
不同的第三方检测服务平台有各自不同的SDK，如果媒体主需要对接多家的监测服务器需要集成多个SDK，显然这样的效率是很低的，所以MMA(中国无线营销联盟)制定了一下规范，各家监测平台需要遵循这个规范，各家媒体主只需要布署一个符合MMA规范的SDK就可以对接市面上绝大部分的第三方检测服务器平台，如果媒体主的提供的监测SDK还不放提，也可以直接使用MMA官方提供的监测SDK，MMA体用的这个叫通用SDK，各家监测服务平台的SDK都应该具有通用SDK的功能。
我们来看一下广告监测的过程：广告开始投放前, 由监测平台为广告主需要监测的广告分配对应的曝光监测代码. 媒体需要将监测代码录入到其投放系统中并与广告保持一一对应的关系. 投放系统在响应媒体发送的投放请求时,同时返回与广告对应的曝光监测代码. 媒体从中解析出广告以及对应监测代码, 并在后续相应广告曝光行为产生时调用相应的接口, 将监测代码当作参数传给该接口，从而实现数据的监测，如果由于网络问题，发送失败，还是需要通过APP主动去调用
SDK最大的缺点就是要加一个监测DSK进去，由于需要在媒体方嵌入SDK，开发量大，对媒体方的数据有风险，一般大型平台的APP会采用这种形式，如视频播放平台，直播平台。
SDK方式简单易用、功能强大。媒体在App中集成SDK后，只需要进行少量的开发工作，就能满足第三方与广告主的绝大部分需求；
SDK配置文件更新要求
统一SDK需要动态从广告平台加载监测参数XML文档，更新配置规则，根据MMA中国制定的规则，不同的终端动态加载规则不一样，具体规则如下：
- APP上：SDK优先使用本地的配置文件，同时会定期下载远程的配置文件覆盖本地的配置。Wifi环境下每天更新一次，2G/3G环境下3天更新一次, 更新后的配置文件存储到本地cache。
- OTT上：SDK优先使用本W地的配置文件，同时会定期下载远程的配置文件覆盖本地的配置。Wi-Fi及有线连接环境下每天更新一次, 更新后的配置文件存储到本地cache。
Click监测
广告点击监测有两种，一种是同步跳转（同步监测），一种是异步跳转（异步监测）。
用户点击广告，广告 SDK 接收到用户点击事件，广告 SDK 处理点击事件，发送
计费通知给广告平台，同时广告 SDK 将点击监测数据异步上传给监测平台。 监测流程下图所示:
流程说明:
- (1) 用户点击广告。
- (2) 广告 SDK 处理点击事件。
- (3) 广告 SDK 将计费通知给广告平台。
- (4) 广告平台进行计费等事件处理。
- (5) 广告 SDK 异步将测数据上报到第三方监测平台。
同步加载
302跳转（监测和落地页合为一个链接）。在用户点击广告后，先访问监测链接跳转到监测方的服务器，然后返回一个落地页，继续访问这个落地页，适用于一般移动浏览器页面的点击跳转行为；同步监测不支持回传IDFA等参数。
用户点击广告，浏览器接收到用户点击事件并处理，将监测数据上传给监测平台，监测 平台计数完成后进行 302 重定向到目标站点。
监测流程如图所示:
流程说明:
- (1)用户点击广告
- (2)浏览器处理点击事件
- (3)浏览器将监测数据上报给监测平台。
- (4)监测平台收集和处理上报的数据
- 5)监测平台计数完成后进行 302 重定向到目标站点。
备注:如果需要计费处理，则浏览器首先将计费通知给广告平台，计费处理后 302 重 定向到监测平台，将监测数据上报给监测平台，计数完成后再次 302 重定向到目标站点。
异步加载
在用户点击广告后，先访问监测链接跳转到监测方的服务器，同时跳转或打开落地页。适用于内部做特殊的跳转行为处理、或内部地址有跳转；
用户点击广告，浏览器接收到用户点击事件并处理，在跳转到目标站点的同时将监测数 据异步上报给监测平台。
监测流程如图所示
流程说明:
- (1)用户点击广告
- (2)浏览器处理点击事件
- (3)浏览器跳转到目标站点的同时将监测数据异步上报给监测平台。
- (4)监测平台收集和处理上报的数据
备注:如果需要计费处理，则浏览器将计费通知给广告平台，并且异步将监测数据上报给监测平台。
