廣告/曝光監測有兩個核心：Impression監測和Click監測。
其中Impression監測按實現方式可以分為JS監測、API監測和SDK監測三種，目前主要要是API和SDK這兩種。
Click按資料的傳輸可以分為同步載入和非同步載入。
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跟蹤，這是基礎跟蹤程式碼，然後再對需要跟蹤的位置做具體的跟蹤。
拓展閱讀AdMonitor監測程式碼指南- 可見曝光部分
API監測API監測是指媒體方以API方式向監測平臺傳遞監測平臺認可的引數，使得監測平臺可以以此進行準確的獨立曝光報表計算與排查資料差異等的監測方式；
典型的就是廣告展示後，媒體方從Client端以API方式將曝光資料上報給監測平臺。
機制如下：
圖中主要模組職能描述:
廣告 SDK:採集監測資料並通過 API 上報監測資料到監測平臺。 監測平臺:接收各個渠道的廣告 SDK 上報的監測資料，並對資料進行清洗， 分析和挖掘，生成監測結果。 監測終端:獲取監測平臺的監測結果資料，並以圖形化的方式展現。API方式靈活通用、App與移動網頁均適用。但需要媒體按照API監測標準，承擔部分開發工作。
API監測按傳遞方式分為C2S（Client to Server）API和S2S（Server to Server）API兩種。
C2SC2S即Client to Server，客戶端直接傳送給監測平臺伺服器，是指:通過使用者客戶端的監測 URL 傳送監測請求，完成監測，屬於比較常規的監測合作。
流程如下：
流程說明：
1、監測平臺生成監測程式碼2、佈署到廣告平臺去，JS和API方法最大的不同是JS是佈署到頁面上去，API是佈署到廣告投放平臺，需要注意，曝光和點選是兩段不同的監測程式碼，不要搞混。3、使用者訪問頁面，使用者在瀏覽器開啟網站4、請求頁面資源，瀏覽器向媒體主伺服器請求頁面資源5、返回頁面資源，媒體主伺服器向瀏覽器返回頁面資源6、監聽到廣告位，頁面會有廣告平臺的程式碼監聽廣告位7、請求廣告，告訴廣告平臺這裡有個廣告位，需要展示廣告8、下發廣告素材和監測程式碼，將廣告所需的素材下發給瀏覽器，監測程式碼隨著廣告素材下發9、廣告曝光展示，10、上傳曝光監測資料，觸發監測程式碼，上傳曝光監測資料到監測平臺11、監測資料處理，監測平臺對收到的監測資料做處理，形成報告這個過程裡面，監測資料是直接瀏覽器端直接上傳到監測平臺的，瀏覽器相當於是Client，是C端,所以是C2S。
按照展示機制的不同可以分為預載入廣告和實時載入廣告展示監測。下面看一下實際的資料傳遞方式。
預載入廣告展示監測廣告SDK預先載入廣告，並將廣告快取，當需要展示廣告時，廣告SDK負責將已預先載入並快取的廣告進行展示，並將展示的監測資料上傳給監測平臺。
監測流程下圖所示:
流程說明:
(1) App 在合適的場景，通過廣告 SDK 從廣告平臺獲取廣告。
(2) 廣告 SDK 快取廣告平臺所返回的廣告，並根據需要進行預載入。
(3) App 在合適的場景，通過廣告 SDK 發起廣告展示。
(4) 廣告 SDK 檢查快取，若有成功快取/預載入廣告，則將該廣告進行展示。
(5) 在廣告得到實際展示後，廣告 SDK 通過載入 tracking pixel，將廣告展 示監測資料上報到監測平臺，資料格式參考本標準第 6 節。推薦的實 現方式參考 第 12 節 [2] 和 [3]，廣告 SDK 在展示成功後觸發 pixel tracking。
(6) 監測平臺收集和處理上報的資料，詳見本標準第 7.1 節。
實時載入廣告展示監測App 通過廣告 SDK 在需要展示廣告時，即時的從廣告平臺來載入廣告，廣告加 載並展示完成後，廣告 SDK 將展示的監測資料上傳給監測平臺。
監測流程下圖所示:
流程說明:
(1) App 通過廣告 SDK，從廣告平臺獲取廣告。
(2) 廣告 SDK 實時展示廣告平臺返回的廣告創意。
(3) 廣告創意的主要元素載入完成後，廣告 SDK 通過載入 tracking pixel的方式，將展示資料提交到監測平臺，。
(4) 監測平臺收集和處理上報的資料，
S2SS2S即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 時，為達到監測目的，
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監測廣告點選監測有兩種，一種是同步跳轉（同步監測），一種是非同步跳轉（非同步監測）。
流程說明:
(3) 廣告 SDK 將計費通知給廣告平臺。
(4) 廣告平臺進行計費等事件處理。
(5) 廣告 SDK 非同步將測資料上報到第三方監測平臺。
同步載入302跳轉（監測和落地頁合為一個連結）。在使用者點選廣告後，先訪問監測連結跳轉到監測方的伺服器，然後返回一個落地頁，繼續訪問這個落地頁，適用於一般移動瀏覽器頁面的點選跳轉行為；同步監測不支援回傳IDFA等引數。
監測流程如圖所示:
流程說明:
(3)瀏覽器將監測資料上報給監測平臺。
(4)監測平臺收集和處理上報的資料
5)監測平臺計數完成後進行 302 重定向到目標站點。
備註:如果需要計費處理，則瀏覽器首先將計費通知給廣告平臺，計費處理後 302 重 定向到監測平臺，將監測資料上報給監測平臺，計數完成後再次 302 重定向到目標站點。
非同步載入在使用者點選廣告後，先訪問監測連結跳轉到監測方的伺服器，同時跳轉或開啟落地頁。適用於內部做特殊的跳轉行為處理、或內部地址有跳轉；
監測流程如圖所示
流程說明:
(3)瀏覽器跳轉到目標站點的同時將監測資料非同步上報給監測平臺。
(4)監測平臺收集和處理上報的資料
備註:如果需要計費處理，則瀏覽器將計費通知給廣告平臺，並且非同步將監測資料上報給監測平臺。