付海軍，現就職于時趣互動，任技術總監(jiān)，負責移動原生廣告平臺引擎開發(fā)和數據挖掘工作，06年畢業(yè)于蘭州大學，曾就職于阿里巴巴集團萬網從事主機面板和云計算底層開發(fā)；之后加入億瑪在線從事互聯網廣告程序化購買相關的工作，負責RTB競價投放系統和大數據平臺。對于系統架構設計和技術團隊建設感興趣，關注高并發(fā)實時系統，海量數據處理。

前言

大家好，感謝主持人，今天我講的內容是DSP廣告系統架構及關鍵技術，分享一下我過去幾年在做DSP廣告系統過程中的一些體會和經歷，涉及到的內容如果后續(xù)想做廣告系統的人員應該是可以做一些參考的，后續(xù)如果有疑問在分享結束后也可以跟大家私下交流，下面我就開始今天的分享了。

廣告和網絡游戲是互聯網企業(yè)主要的盈利模式

廣告是廣告主通過媒體以盡可能低成本的方式與用戶達成接觸的商業(yè)行為。也就是說按照某種市場意圖接觸相應人群，影響其中潛在用戶，使其選擇廣告主產品的幾率增加，或對廣告主品牌產生認同，通過長期的影響逐步形成用戶對品牌的轉化。

一個好的DSP系統需要滿足：

1. 擁有強大的RTB(Real-Time Bidding)的基礎設施和能力。

2. 擁有先進的用戶定向(Audience Targeting)技術。

首先，DSP對其數據運算技術和速度要求非常之高。從普通用戶在瀏覽器中地址欄輸入網站的網址，到用戶看到頁面上的內容和廣告這短短幾百毫秒之內，就需要發(fā)生了好幾個網絡往返(Round Trip)的信息交換。

Ad Exchange首先要向DSP發(fā)競價(bidding)請求，告知DSP這次曝光的屬性，如物料的尺寸、廣告位出現的URL和類別、以及用戶的Cookie ID等；DSP接到競價請求后，也必須在幾十毫秒之內決定是否競價這次曝光, 如果決定競價，出什么樣的價格，然后把競價的響應發(fā)回到Ad Exchange。

如果Ad Exchange判定該DSP贏得了該次競價，要在極短時間內把DSP所代表的廣告主的廣告迅速送到用戶的瀏覽器上。整個過程如果速度稍慢，Ad Exchange就會認為DSP超時而不接受DSP的競價響應，廣告主的廣告投放就無法實現。

其次，基于數據的用戶定向(Audience Targeting)技術，則是DSP另一個重要的核心特征。從網絡廣告的實質上來說，廣告主最終不是為了購買媒體，而是希望通過媒體與他們的潛在客戶即目標人群進行廣告溝通和投放。

服務于廣告主或者廣告主代理的DSP，則需要對Ad Exchange每一次傳過來的曝光機會，根據關于這次曝光的相關數據來決定競價策略。這些數據包括本次曝光所在網站、頁面的信息，以及更為關鍵本次曝光的受眾人群屬性，人群定向的分析直接決定DSP的競價策略。DSP在整個過程中，通過運用自己人群定向技術來分析，所得出的分析結果將直接影響廣告主的廣告投放效果。

此次分享主要針對以下幾個方面，描述DSP廣告系統架構及關鍵技術：

1. 廣告系統概念介紹

2. 廣告系統業(yè)務流程

3. DSP系統架構

4. RTB競價引擎結構

5. 點擊率預測

6. DMP數據處理架構

7. 受眾定向劃分

8. 用戶畫像與廣告系統反作弊

程序化購買的特點

下圖是在DSP產生之前和產生之后廣告行業(yè)的兩種最常見產業(yè)鏈

傳統的廣告投放模式的產業(yè)鏈是廣告主通過廣告代理，以廣告網絡/聯盟為渠道在媒體網站展示廣告，達到接觸受眾的目的的過程。

這種模式的好處是媒體網站可以通過通過包段或CPS的模式可以售出自己的廣告位，但是這類售出是偏粗放型的，長期同類型的廣告投放，受眾會視覺疲勞，點擊率會下降，轉化也會隨之下降。為了能夠獲得更多的收益，媒體必須通過差異化銷售細分自己的廣告位和受眾。而事實上顯示廣告領域最初的定向投放的最初動機是供給方拆分流量以獲得更高的營收。好的位置，通過包段通常會供不應求，但是對于長尾流量通常是會無人問津，即便是對于廣告主來說同一個潛在客戶在大媒體出現會有廣告主包段進行購買，但是在小網站出現就會沒人買。事實上潛在客戶在哪里出現對于廣告主都是同一個人，如果能顯示與客戶需求相吻合或接近的廣告就有可能產生轉化。在將優(yōu)質廣告位包段售出后，如果對用戶有足夠的認識，有足夠多不同類型的廣告主，在流量可以拆分到單次展現的購買粒度，就有可能依據不同的受眾定向為每個廣告主找到合適的人群和流量。

程序化購買顛覆了原有廣告產業(yè)鏈，形成了全新的產業(yè)鏈。

鑒于群里有很多人不是做廣告系統的，為了能夠在后續(xù)的介紹過程中更容易理解介紹的內容，這里先介紹一些廣告行業(yè)中常見的一些概念。

DSP（Demand Side Platform），是廣告需求方平臺，DSP為廣告主提供跨媒介、跨平臺、跨終端的的廣告投放平臺，通過數據整合、分析實現基于受眾的精準投放，并且實時監(jiān)控不斷優(yōu)化。

RTB（Real Time Bidding）實時競價是DSP、廣告交易平臺等在網絡廣告投放中采用的主要售賣形式，會在極端的時間內（通常是50~100毫秒以內）通過對目標受眾競價的方式獲得該次廣告的展現，RTB的購買方式無論在PC端或是移動端均可以實現。

程序化購買（Programmatic Buying）根據廣告主定義的期望受眾，系統幫助其找出優(yōu)選的媒體來購買受眾，為廣告主提出最優(yōu)媒介采買計劃，通過程序化購買的方式執(zhí)行，并按照期望的周期反饋監(jiān)測結果，并對后續(xù)投放進行優(yōu)化。包括但不僅限于RTB購買。

最常見的DSP行業(yè)中的供需業(yè)務流，廣告主作為需求方，潛在客戶是最終的受眾，中間穿插著代理機構，DSP，AdNetwork，AdExchange,SSP和供應方也就是媒體。

下圖是DSP平臺的廣告投放流程，投放過程中涉及到廣告受眾，媒體網站，adx和dsp，分別標注了廣告投放各階段伴隨發(fā)生的事件。從1~7步之間只允許100ms之內的延時，否則廣告受眾就會覺得網頁加載速度太慢而選擇離開。

在線廣告的核心問題

需要在特定用戶，在指定上下文的環(huán)境下，找到最合適的廣告，進行投放，并盡可能產生轉化。

在線廣告的挑戰(zhàn)

大規(guī)模

百萬量級頁面，十億量級用戶，需要被分析處理

高并發(fā)在線投放（每天處理百億次廣告交易請求）

時延要求嚴格（adx通常要求競價響應時間在100ms完成）

用戶定向動態(tài)變化

用戶的關注點和購物興趣變化會比較頻繁，需要能夠及時更新用戶畫像

上下文條件變化頻繁

用戶和上下文多樣化的環(huán)境一起用于廣告候選檢索

DSP系統架構

上圖是主要模塊的流程圖涉及到的角色包括廣告主網站，媒體網站，廣告網絡和DSP，以及DSP內部的相關模塊，如：RTB引擎，業(yè)務平臺，日志收集系統，DMP，CM和反作弊系統。

1. 投放前DSP會要求在廣告主網站布碼，同時在DSP的業(yè)務平臺中錄入廣告投放的需求，如投放金額，投放排期，投放定向（如地域，興趣，年齡等），最高限價。

2. 當訪客（即潛在的消費者）從左上角訪問廣告主網站開始，訪客在廣告主網站上的行為會被收集，同時DSP會與ADX和SSP進行Cookie Mapping，形成日志進行處理，形成回頭客相關的行為數據標簽。

3. 當訪客完成對廣告主網站的訪問，去其他媒體網站進行訪問時，相應的媒體廣告位根據事先嵌入的廣告代碼向廣告網絡發(fā)起廣告請求，廣告網絡會將廣告請求封裝成http頭+pb體的格式向多個DSP發(fā)起競價請求。

4. 當DSP接到競價請求時會根據與廣告網絡約定的pb格式進行解包，拆解出相關的字段進行匹配，根據之前相關媒體積累的點擊率結合點擊率預測模型對出價進行預測，找出平臺內在此次競價請求能讓平臺利益最大化的廣告主的創(chuàng)意進行投放，返回給廣告網絡出價與廣告代碼

5. 廣告網絡會在特定時間內（通常是50~100毫秒）根據多個DSP的出價高低，以第二名價格多一分的價格讓出價最高的dsp勝出，并將廣告代碼中的展現宏和點擊宏進行替換（替換過程中會根據事先與dsp約定好的公鑰對價格進行加密，以防止第三方篡改和竊聽）

6. 廣告網絡將廣告代碼返回給媒體，媒體會將廣告代碼放置在js對應的位置進行展現，展現和點擊的過程中會先后觸發(fā)廣告網絡和勝出DSP的展現代碼，廣告網絡和DSP分別接收到展現請求會對相應的展現進行計費操作（月底會相互進行對賬）

7. DSP內部會根據收集到的展現和點擊進行計費操作，形成相應的報表；而瀏覽、展現、點擊的記錄會分別進行收集形成日志，經過ETL由DMP進行抽取和分析，形成媒體數據，用戶標簽，CookieMatch數據以及回頭客用戶標簽數據，這些數據會在投放過程中作為RTB競價的參考依據。

整個投放過程中其實還有一些其他的模塊出現如CookieMapping、反作弊，動態(tài)創(chuàng)意、網站分析系統。只不過這些系統不是在主干流程上，后續(xù)單獨進行描述和分析。

為了保證投放，DSP系統實現了多機房部署的結構，南北方機房分別在杭州和北京部署RTB引擎、點擊率預測與相關的展現點擊收集節(jié)點。投放活動相關數據通過Redis進行緩存，多機房進行準實時同步，媒體展現點擊數據通過kafka隊列進行推送，通過Consumer進行消費統計，最后通過媒體數據分發(fā)集群分發(fā)到多個機房進行使用。

RTB投放引擎的架構

RTB引擎是DSP系統的核心，是實現高并發(fā)實時反饋的關鍵，RTB對外以HTTP服務形式暴露接口，當媒體上的js被觸發(fā)，adx/ssp收到js請求后會將請求封裝成http頭+pb體(protocol buffer,谷歌定義的序列化數據交換格式)的方式作為客戶端連接RTB，RTB對http消息按照事先約定解包在內部依靠相關數據進行計算，最終返回pb或json格式的出價和廣告代碼給廣告交易平臺。RTB 需要支持高并發(fā)（每天百億級別請求）和低延時（50ms之內需要反饋）。

當時我們的RTB采用Linux C++開發(fā)，通過Adapter適配器層解耦適應不同的SSP/adx，算法池內部拆分成五層，五層之間相互正交，算法模塊允許熱插拔，編譯完成的動態(tài)鏈接庫可根據配置文件的變化實時進行加載和卸載，允許多算法鏈并行拆分流量進行A/B測試，流量處理過程中會對流經不同算法鏈的流量打上不同的算法標簽，并在后續(xù)展現，點擊過程中持續(xù)帶上此標簽用于后續(xù)效果的跟蹤和分析。

下面說一下在針對RTB進行架構設計過程中涉及到的一些技巧：

由于一個dsp要接觸到盡可能多的流量和用戶才有可能找到符合廣告主定向的目標受眾，那dsp一定要對接很多的adx和ssp，來接受盡可能多的流量。設計適配器層的目的就是將不同adx之間的流量格式差異消滅在適配器這一層，對于進入系統內部的流量都一視同仁，簡化了rtb系統的復雜性。RTB系統在設計之初就考慮了AB測試的環(huán)節(jié)，讓算法的效果能夠進行橫向比較，方便算法進行優(yōu)化。RTB本身是不帶狀態(tài)的，也就是說，它只能依靠外部的輔助系統提供的信息，如點擊率預測，人群定向和反作弊這類模塊提供的數據才能實現快速反饋的同事能正確反饋。

DMP

對于RTB的設計在后續(xù)提問和討論的環(huán)節(jié)我們再做進一步分析，下面講一下DSP系統中除了RTB之外的另外一個核心：DMP

首先需要定義一下廣告投放過程中關鍵的一些數據：

廣告系統DMP數據處理的架構

跟大多數的大數據相關的系統很相似，基本上逃不開那幾樣東西Hadoop，storm，redis等等:

數據處理部分結合了Hadoop的離線計算、Spark的批處理和Storm的流式計算。

HBase和MySQL用于最終結果落地用于前端查詢。

ElasticSearch 有準實時索引，用于明細數據實時查詢和時間序列歷史回溯統計。

Spark內置的機器學習算法庫MLLib主要使用分類，聚類KMeans，協同過濾，決策樹，邏輯回歸。

由于之前在群里的分享中,王新春@大眾點評 ，王勁@酷狗音樂 講了很多storm實時處理和大數據架構的內容，他們二位都是大數據領域的大佬了，我在這里就不班門弄斧了，簡單提一下廣告行業(yè)里是怎么做的，基本上大同小異，大家用的東西都差不多。

對于廣告投放要投放的目標，落實在dmp中就是需要找出相應的受眾定向，下面簡單分析一下幾類受眾定向：

上圖是廣告有效性模型根據受眾定向的定性評估表，水平方向是定向技術在廣告信息接受過程中所起作用的階段，垂直方向是大致的效果評價（從下往上效果依次升高）。

按照計算框架不同這些受眾定向可以分為三類：

1. 用戶標簽t(u)，即在時間序列上用戶歷史行為為依據，為用戶打上的標簽。

2. 上下文標簽t(c)，即當前用戶聯系上下文在當前的訪問行為達到的即時標簽。

3. 廣告主定制化標簽t(a,u)，是根據特定廣告主提供的特定用戶群在其網站上的訪問行為數據加工所得。

其中：地域定向、頻道定向和上下文定向屬于t(c)的定向方式；人口屬性定向、行為定向屬于t(u)的定向方式；
而重定向和Look-alike則是t(a, u)的定向方式。
地域定向主要用于商家銷售目標局限于特定區(qū)域的情況下；

人口屬性主要包括年齡，性別，收入，學歷等；頻道定向主要是針對媒體側特點，對相應受眾進行劃分；上下文定向主要是根據當前網頁的內容上下文推送相關廣告；行為定向是根據用戶歷史訪問行為，了解用戶喜好，進而推送相關廣告；精確位置定向是在移動設備上根據精確的地理位置投放廣告，更聚向與地域性非常強的的本地生活類廣告主；

重定向是對特定廣告主一定時間段內訪客投放廣告以提升效果的廣告投放方式，人群規(guī)模由廣告主固有用戶量和媒體重合量共同決定；新客推薦是在重定向規(guī)模太小，無法滿足廣告主接觸用戶需求的情況下，以重定向用戶為種子，根據廣告平臺數據積累，為廣告主找出行為相似用戶的定向條件。

用戶畫像的方法

接下來基于上面提到的積累受眾定向介紹一下用戶畫像的方法

我們能夠看到用戶畫像其實也就是對于用戶特征的提取，涉及到人口，設備，運營商，位置以及用戶的瀏覽，點擊購買等行為數據。用戶畫像是通過對用戶特征的提取對用戶行為進行定性和定量的描述，形成：【用戶ID:用戶標簽：標簽權重】形式的用戶畫像標簽，在廣告投放過程中，根據提取流量對應用戶權重較高的若干個標簽反向對廣告主進行篩選，找出適合流量特點的廣告素材。 用戶標簽用于廣告主對于受眾的選擇，而權重用于在海量用戶標簽里選取重點的標簽進行投放。

同時要注意用戶的畫像隨時間的推移會有衰減，需要在用戶畫像的過程中考慮時間衰減的因素，因為用戶的愛好和習慣會隨著時間變長而有變化，同時數據的時效性也決定了用戶畫像的準確程度，進而影響廣告的投放。

事實上在廣告平臺中收集到的最多的數據是用戶的瀏覽數據，在拿到這么多的瀏覽數據的情況下，想要分析出用戶的愛好和興趣以及需求，那就需要對網頁的內容進行分析和抽取，下面介紹一下用戶畫像中非常重要的行為標注部分的架構：

用戶在瀏覽一系列網站的過程中是多少會帶著一些目的性進行瀏覽的，即便是沒有明確目的，也會帶有一些個人喜好，有了這些目的和喜好，就會進一步縮短我們在推送廣告過程中對于用戶定向的選擇難度。上圖就是在上下文定向中對網頁關鍵字提取的子系統的架構。【上下文定向】可以通過網頁關鍵字提取，建立一個cache，根據URL建立對應標簽，當廣告請求到來時，命中相應URL則返回cache的命中內容，如果URL未緩存則返回空集合，同時將URL添加到后臺抓取隊列，在URL被抓取，并打上標簽存入cache，為cache設置TTL，當長期不訪問則將該URL的記錄清楚，而熱點內容URL的關鍵詞是始終被緩存的，運行較長的時間則大多數熱點URL大多會被緩存。在抓取到內容之后，需要對網頁內容進行內容挖掘，在挖掘的過程中有以下幾個方案可以被選?。?/p>

網頁文本內容通過擴展語境，引入更多文本進行挖掘；利用語義分類樹；建立主題模型。

我們在上面提到了在線廣告的核心問題其實是找上下文，用戶，廣告三者之間的最恰當的匹配。

在展示類廣告中比較重要的一個核心考核點就是點擊率，因此點擊率預測模塊在DSP中是非常重要的部分

CTR預估涉及到三種角色：受眾用戶，媒體，廣告主

預估的目標是為特定的受眾用戶再給定的媒體環(huán)境下找到最合適的廣告，對媒體來說實現收入最大化，即按照eCPM排序的基本原則來排序。

最簡單的CTR預估的模型，根據歷史日志，統計出三個維度的CTR對照關系，預測過程中，當一個user訪問特定url時，查詢詞典如果存在的CTR，則返回CTR最高的ad，如不存在，則隨機返回ad，積累后續(xù)數據。

存在問題：基于統計數據，對舊廣告效果還可以，但對冷啟動的廣告沒有預測能力。
事實上，我們在線上做點擊率預測模型，使用的算法是邏輯回歸，后續(xù)可能考慮會用到的廣告點擊率預測方法有：

1. 機器學習方法：特征+模型+融合方案

2. 協同過濾方法：看做推薦系統來處理

排序模型以預測結果為基礎，廣告排序模型有如下幾種：

1. 點排序（point-wise approach）：變成分類問題或者回歸模型來處理

2. 對排序（pair-wise approach）：比較兩個廣告誰的優(yōu)先級高，不分類

3. 列排序（list-wise approach）：對整個廣告候選集學習排序模型

廣告行業(yè)的反作弊

作弊背后必然有一個或者一堆的人從眾有獲利，比如制造垃圾站掛廣告獲利的總是扎堆出現的。如果你抓到了一個網站流量異常，在用工具刷量，那肯定不會只是這一個網站在用這個模式在刷量；如果一個人有多個網站，如果有一個網站在刷量，那他的其他網站也應該檢查一下了。

在廣告反作弊的過程中，為了找出刷量的垃圾站背后都有哪些人，這些人有哪些網站，針對DSP平臺流量80%的網站域名去重，通過whois信息查詢到域名注冊郵箱，歸類出哪些域名屬于哪個注冊郵箱，發(fā)現其中一個刷量，則對同一郵箱下的其他域名進行嚴查。

上圖是主要的一些廣告反作弊的思路，廣告作弊是有成本的，有人作弊，還是背后有利益驅動，找出利益鏈條是反作弊的關鍵
下面對之前我們做廣告反作弊工作過程中遇到的幾類例子：

P2P流量互刷

互刷作弊有代表性的軟件是：流量寶和流量精靈

均通過客戶端軟件向服務器提交互刷任務請求，客戶端收到服務器分發(fā)的互刷任務后執(zhí)行隱藏的瀏覽任務，每天可達到數千個IP的訪問量，IP布局分散，UA隨機生成，很難通過瀏覽記錄尋找作弊痕跡?，F在唯一有效的反作弊方法需要通過蜜罐主機進行跟蹤和分析。下面介紹一下我們對于p2p刷量所采用的蜜罐主機的結構：

其中虛線框中是我們的的蜜罐系統，虛線框外面的灰色部分是我們要尋找的作弊目標
如果是對信息安全有一定了解的人對于蜜罐系統一定不陌生，也就是系統設計上有意拋一些破綻出來，讓攻擊者自己跳出來，通過對攻擊者行為的觀摩來尋找破解攻擊的思路。

由于流量寶、流量精靈一類的刷量工具多集中于windows平臺下，安裝windows vm并將系統代理指向nginx反向代理，通過刷量工具提交刷量任務。提交刷量任務的站點沒有任何真實流量，只要是訪問這個站點的IP基本上都是通過刷量工具來的流量，IP可以在RTB引擎對相關IP端進行封殺，不再進行投放；

Nginx反向代理落詳細日志通過Logstash收集、解析發(fā)送給ElasticSearch建立索引，通過kibana做可視化，統計出刷量最多的IP，域名和URL地址出來，可以作為后續(xù)模式識別的模型輸入。搜集相關證據，域名可以向adx反饋對媒體進行封殺，同時可以根據篩選出的刷量作弊域名在DSP投放過程中減少投放以避免自身損失。

CPS引流作弊

我們遇到的另外一種對于DSP投放效果有非常大影響的一類作弊手段是：CPS引流作弊

引流作弊可以幫助引流網站“提高”CPC，“提高”CPS。但對廣告主不產生實際有效的流量。

目前發(fā)現的引流作弊行為有3種：

1. 作弊代理通過回帖作弊（對媒體網站無控制權）

2. 作弊代理伙同媒體網站作弊（對媒體網站有控制權）

3. 作弊代理伙同媒體網站通過網盟作弊

也就是說在DSP投放了廣告的網站里被插入了跳轉到CPS計費鏈接的302跳轉的圖片，雖然DSP花錢從adx買了流量投放了廣告，但是這個頁面里還有大量的CPS結算的鏈接跳轉，如果廣告主既在網盟，又在DSP投放廣告的話，任何看過這類頁面的人在廣告主網站下的單，就有可能被劫持走。整個過程中，用戶都不知道有'廣告主'的存在。但是對應的'廣告主'會認為是特定CPS鏈接帶來了一個點擊，后續(xù)的cps應該是記在相應的CPS合作方名下。

Q & A

Q1：請問付總dmp數據存哪里？HBase？

數據分不同的形式存在不同的地方，原始日志存放在硬盤上，經過ETL后寫入HDFS，結構化存放在Hive表中進行查詢，cookiemapping數據經過hadoop計算過后導出成文件，存放在Tair里讓RTB查詢，用戶行為數據存放在hdfs里，畫像之后數據存放在redis供rtb查詢，跑出來的統計報表存放在mysql供報表系統調用。CM的cookie對應數據有一部分也是存放在hbase的，hbase和hadoop共用hdfs，所以查詢速度也會受到hadoop集群資源多少的影響。

Q2：請問 RTB算法模塊熱插拔大概是怎么實現的？

上面我曾經提到過RTB系統是用Linux C++開發(fā)的，如果對于Linux C++比較熟悉的人應該知道Linux下是可以動態(tài)加載動態(tài)鏈接庫的使用的主要是：

dlopen：打開動態(tài)加載庫

dlsym：獲取接口函數指針

dlcose：關閉庫

這三個函數就可以在程序運行時加載動態(tài)鏈接庫了。為了達到模塊準實時熱插拔的目標我們還使用了Linux下的inotify,
inotify是一種文件系統的變化通知機制，如文件增加、刪除等事件，可以立刻讓用戶態(tài)得知。我們在RTB程序啟動過程中向系統注冊了inotify事件來監(jiān)控配置文件，當配置文件被修改的時候立即通知程序重新加載配置文件

Q3：請問cookiemap是離線map還是實時map？map后數據正確率有多少？移動端map 主要根據那些key來map？

cookieMapping分在線和離線兩種，通常情況下廣告投放過程中會有幾個場景會發(fā)起cm

第一種，廣告主網站上布碼之后當訪客訪問廣告主網站時觸發(fā)js，dsp會主動向各家對接過后的adx進行cookiemapping

第二種，廣告投放過程中，當dsp的出價的同時會帶上廣告展現代碼里面也包含有cm代碼，當出價高于其他dsp的時候，廣告代碼會被吐到媒體網站，相應的也會觸發(fā)cm

第三種，當在adx消耗金額達到一定水平，像Tanx會按照消耗比例每天向dsp發(fā)起一定比例的dsp無法識別用戶的cm請求，這個時候dsp也會向其他adx發(fā)起cm

除此之外對于運營商數據的使用過程中通常就是離線匹配的了，方法通常是運營商的瀏覽數據來自于路由設備的DPI信息，里面有用戶的adsl賬號信息，運營商會找出一定時間內訪問過dsp指定的幾個域名的人，通常會在這個域名下面的所有頁面都布上cm代碼，通過http頭就能找出dsp的cookieID，找出的這些人都會有adsl賬號標識，通過賬號就能建立與dsp的cookieID的關系，這類cm就是離線的了。

Q4：請問怎么識別是同一個用戶？通過cookie，還是有其他先進的辦法？

PC端的用戶識別通常是依靠cookie，這類cookie好植入，但生命周期比較短，無法直接跨瀏覽器/跨設備，同時容易被各類電腦管家/助手清理，所以很容易出現信息苦苦畫好的用戶畫像，過兩天這個id就再也不出現了。

在PC端還會用flash cookie的方法來打通不同的瀏覽器，因為flash storage是同一塊存儲不同的瀏覽器可以跨瀏覽器打通。
當然還有一種叫evercookie的手段集合了包括flash cookie 之內的多種標識方式，感興趣的可以了解一下這個網址 http:///evercookie/

移動端的身份標識，安卓的包括android id，mac地址IMSI和IMEI，而iOS是IDFA。由于移動設備上安裝的app里可以嵌入SDK，而app有可能在移動端的權限也不同獲取到的標識也會有差異，所以最終也會涉及到用戶標識統一識別的問題，當然移動端的用戶標識會遠比PC端要強很多，移動廣告化之后用戶畫像將會更加的準確。