DSP廣告系統架構及關鍵技術解析(轉)

廣告和網絡遊戲是互聯網企業主要的盈利模式

廣告是廣告主經過媒體以儘量低成本的方式與用戶達成接觸的商業行爲。也就是說按照某種市場意圖接觸相應人羣，影響其中潛在用戶，使其選擇廣告主產品的概率增長，或對廣告主品牌產生認同，經過長期的影響逐步造成用戶對品牌的轉化。

一個好的DSP系統須要知足：

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

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

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

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

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

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

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

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

廣告系統概念介紹

廣告系統業務流程

DSP系統架構

RTB競價引擎結構

點擊率預測

DMP數據處理架構

受衆定向劃分

用戶畫像與廣告系統反做弊

程序化購買的特色

下圖是在DSP產生以前和產生以後廣告行業的兩種最多見產業鏈

 

 

傳統的廣告投放模式的產業鏈是廣告主經過廣告代理，以廣告網絡/聯盟爲渠道在媒體網站展現廣告，達到接觸受衆的目的的過程。

這種模式的好處是媒體網站能夠經過經過包段或CPS的模式能夠售出本身的廣告位，可是這類售出是偏粗放型的，長期同類型的廣告投放，受衆會視覺疲勞，點擊率會降低，轉化也會隨之降低。爲了可以得到更多的收益，媒體必須經過差別化銷售細分本身的廣告位和受衆。而事實上顯示廣告領域最初的定向投放的最初動機是供給方拆分流量以得到更高的營收。好的位置，經過包段一般會供不該求，可是對於長尾流量一般是會無人問津，即使是對於廣告主來講同一個潛在客戶在大媒體出現會有廣告主包段進行購買，可是在小網站出現就會沒人買。事實上潛在客戶在哪裏出現對於廣告主都是同一我的，若是能顯示與客戶需求相吻合或接近的廣告就有可能產生轉化。在將優質廣告位包段售出後，若是對用戶有足夠的認識，有足夠多不一樣類型的廣告主，在流量能夠拆分到單次展示的購買粒度，就有可能依據不一樣的受衆定向爲每一個廣告主找到合適的人羣和流量。

程序化購買顛覆了原有廣告產業鏈，造成了全新的產業鏈。

鑑於羣裏有不少人不是作廣告系統的，爲了可以在後續的介紹過程當中更容易理解介紹的內容，這裏先介紹一些廣告行業中常見的一些概念。

DSP（Demand Side Platform），是廣告需求方平臺，DSP爲廣告主提供跨媒介、跨平臺、跨終端的的廣告投放平臺，經過數據整合、分析實現基於受衆的精準投放，而且實時監控不斷優化。

RTB（Real Time Bidding）實時競價是DSP、廣告交易平臺等在網絡廣告投放中採用的主要售賣形式，會在極端的時間內（一般是50~100毫秒之內）經過對目標受衆競價的方式得到該次廣告的展示，RTB的購買方式不管在PC端或是移動端都可以實現。

程序化購買（Programmatic Buying）根據廣告主定義的指望受衆，系統幫助其找出優選的媒體來購買受衆，爲廣告主提出最優媒介採買計劃，經過程序化購買的方式執行，並按照指望的週期反饋監測結果，並對後續投放進行優化。包括但不只限於RTB購買。

最多見的DSP行業中的供需業務流，廣告主做爲需求方，潛在客戶是最終的受衆，中間穿插着代理機構，DSP，AdNetwork，AdExchange,SSP和供應方也就是媒體。

下圖是DSP平臺的廣告投放流程，投放過程當中涉及到廣告受衆，媒體網站，adx和dsp，分別標註了廣告投放各階段伴隨發生的事件。從1~7步之間只容許100ms以內的延時，不然廣告受衆就會以爲網頁加載速度太慢而選擇離開。

在線廣告的核心問題

 

須要在特定用戶，在指定上下文的環境下，找到最合適的廣告，進行投放，並儘量產生轉化。

在線廣告的挑戰

大規模

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

高併發在線投放（天天處理百億次廣告交易請求）

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

用戶定向動態變化

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

上下文條件變化頻繁

用戶和上下文多樣化的環境一塊兒用於廣告候選檢索

DSP系統架構

 

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

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

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

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

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

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

廣告網絡將廣告代碼返回給媒體，媒體會將廣告代碼放置在js對應的位置進行展示，展示和點擊的過程當中會前後觸發廣告網絡和勝出DSP的展示代碼，廣告網絡和DSP分別接收到展示請求會對相應的展示進行計費操做（月底會相互進行對帳）

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

整個投放過程當中其實還有一些其餘的模塊出現如CookieMapping、反做弊，動態創意、網站分析系統。只不過這些系統不是在主幹流程上，後續單獨進行描述和分析。

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

RTB投放引擎的架構

 

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

當時咱們的RTB採用Linux C 開發，經過Adapter適配器層解耦適應不一樣的SSP/adx，算法池內部拆分紅五層，五層之間相互正交，算法模塊容許熱插拔，編譯完成的動態連接庫可根據配置文件的變化實時進行加載和卸載，容許多算法鏈並行拆分流量進行A/B測試，流量處理過程當中會對流經不一樣算法鏈的流量打上不一樣的算法標籤，並在後續展示，點擊過程當中持續帶上此標籤用於後續效果的跟蹤和分析。

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

因爲一個dsp要接觸到儘量多的流量和用戶纔有可能找到符合廣告主定向的目標受衆，那dsp必定要對接不少的adx和ssp，來接受盡量多的流量。設計適配器層的目的就是將不一樣adx之間的流量格式差別消滅在適配器這一層，對於進入系統內部的流量都一視同仁，簡化了rtb系統的複雜性。RTB系統在設計之初就考慮了AB測試的環節，讓算法的效果可以進行橫向比較，方便算法進行優化。RTB自己是不帶狀態的，也就是說，它只能依靠外部的輔助系統提供的信息，如點擊率預測，人羣定向和反做弊這類模塊提供的數據才能實現快速反饋的同事能正確反饋。

DMP

對於RTB的設計在後續提問和討論的環節咱們再作進一步分析，下面講一下DSP系統中除了RTB以外的另一個核心：DMP

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

 

 

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

 

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

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

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

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

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

因爲以前在羣裏的分享中,王新春@大衆點評 ，王勁@酷狗音樂 講了不少storm實時處理和大數據架構的內容，他們二位都是大數據領域的大佬了，我在這裏就不班門弄斧了，簡單提一下廣告行業裏是怎麼作的，基本上大同小異，你們用的東西都差很少。

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

 

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

按照計算框架不一樣這些受衆定向能夠分爲三類：

用戶標籤t(u)，即在時間序列上用戶歷史行爲爲依據，爲用戶打上的標籤。

上下文標籤t(c)，即當前用戶聯繫上下文在當前的訪問行爲達到的即時標籤。

廣告主定製化標籤t(a,u)，是根據特定廣告主提供的特定用戶羣在其網站上的訪問行爲數據加工所得。

其中：地域定向、頻道定向和上下文定向屬於t(c)的定向方式；人口屬性定向、行爲定向屬於t(u)的定向方式；

而重定向和Look-alike則是t(a, u)的定向方式。

地域定向主要用於商家銷售目標侷限於特定區域的狀況下；

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

重定向是對特定廣告主必定時間段內訪客投放廣告以提高效果的廣告投放方式，人羣規模由廣告主固有用戶量和媒體重合量共同決定；新客推薦是在重定向規模過小，沒法知足廣告主接觸用戶需求的狀況下，以重定向用戶爲種子，根據廣告平臺數據積累，爲廣告主找出行爲類似用戶的定向條件。

用戶畫像的方法

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

 

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

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

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

用戶在瀏覽一系列網站的過程當中是多少會帶着一些目的性進行瀏覽的，即使是沒有明確目的，也會帶有一些我的喜愛，有了這些目的和喜愛，就會進一步縮短咱們在推送廣告過程當中對於用戶定向的選擇難度。上圖就是在上下文定向中對網頁關鍵字提取的子系統的架構。【上下文定向】能夠經過網頁關鍵字提取，創建一個cache，根據URL創建對應標籤，當廣告請求到來時，命中相應URL則返回cache的命中內容，若是URL未緩存則返回空集合，同時將URL添加到後臺抓取隊列，在URL被抓取，並打上標籤存入cache，爲cache設置TTL，當長期不訪問則將該URL的記錄清楚，而熱點內容URL的關鍵詞是始終被緩存的，運行較長的時間則大多數熱點URL大多會被緩存。在抓取到內容以後，須要對網頁內容進行內容挖掘，在挖掘的過程當中有如下幾個方案能夠被選取：

 

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

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

在展現類廣告中比較重要的一個核心考覈點就是點擊率，所以點擊率預測模塊在DSP中是很是重要的部分

 

 

 

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

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

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

存在問題：基於統計數據，對舊廣告效果還能夠，但對冷啓動的廣告沒有預測能力。

事實上，咱們在線上作點擊率預測模型，使用的算法是邏輯迴歸，後續可能考慮會用到的廣告點擊率預測方法有：

機器學習方法：特徵 模型 融合方案

協同過濾方法：看作推薦系統來處理

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

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

對排序（pair-wise approach）：比較兩個廣告誰的優先級高，不分類

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

廣告行業的反做弊

 

做弊背後必然有一個或者一堆的人從衆有獲利，好比製造垃圾站掛廣告獲利的老是扎堆出現的。若是你抓到了一個網站流量異常，在用工具刷量，那確定不會只是這一個網站在用這個模式在刷量；若是一我的有多個網站，若是有一個網站在刷量，那他的其餘網站也應該檢查一下了。

在廣告反做弊的過程當中，爲了找出刷量的垃圾站背後都有哪些人，這些人有哪些網站，針對DSP平臺流量80%的網站域名去重，經過whois信息查詢到域名註冊郵箱，歸類出哪些域名屬於哪一個註冊郵箱，發現其中一個刷量，則對同一郵箱下的其餘域名進行嚴查。

 

上圖是主要的一些廣告反做弊的思路，廣告做弊是有成本的，有人做弊，仍是背後有利益驅動，找出利益鏈條是反做弊的關鍵

下面對以前咱們作廣告反做弊工做過程當中遇到的幾類例子：

P2P流量互刷

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

均經過客戶端軟件向服務器提交互刷任務請求，客戶端收到服務器分發的互刷任務後執行隱藏的瀏覽任務，天天可達到數千個IP的訪問量，IP佈局分散，UA隨機生成，很難經過瀏覽記錄尋找做弊痕跡。如今惟一有效的反做弊方法須要經過蜜罐主機進行跟蹤和分析。下面介紹一下咱們對於p2p刷量所採用的蜜罐主機的結構：

其中虛線框中是咱們的的蜜罐系統，虛線框外面的灰色部分是咱們要尋找的做弊目標

若是是對信息安全有必定了解的人對於蜜罐系統必定不陌生，也就是系統設計上有意拋一些破綻出來，讓攻擊者本身跳出來，經過對攻擊者行爲的觀摩來尋找破解攻擊的思路。

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

Nginx反向代理落詳細日誌經過Logstash收集、解析發送給ElasticSearch創建索引，經過kibana作可視化，統計出刷量最多的IP，域名和URL地址出來，能夠做爲後續模式識別的模型輸入。蒐集相關證據，域名能夠向adx反饋對媒體進行封殺，同時能夠根據篩選出的刷量做弊域名在DSP投放過程當中減小投放以免自身損失。

CPS引流做弊

咱們遇到的另一種對於DSP投放效果有很是大影響的一類做弊手段是：CPS引流做弊

引流做弊能夠幫助引流網站「提升」CPC，「提升」CPS。但對廣告主不產生實際有效的流量。

目前發現的引流做弊行爲有3種：

做弊代理經過回帖做弊（對媒體網站無控制權）

做弊代理夥同媒體網站做弊（對媒體網站有控制權）

做弊代理夥同媒體網站經過網盟做弊

也就是說在DSP投放了廣告的網站裏被插入了跳轉到CPS計費連接的302跳轉的圖片，雖然DSP花錢從adx買了流量投放了廣告，可是這個頁面裏還有大量的CPS結算的連接跳轉，若是廣告主既在網盟，又在DSP投放廣告的話，任何看過這類頁面的人在廣告主網站下的單，就有可能被劫持走。整個過程當中，用戶都不知道有'廣告主'的存在。可是對應的'廣告主'會認爲是特定CPS連接帶來了一個點擊，後續的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 開發的，若是對於Linux C 比較熟悉的人應該知道Linux下是能夠動態加載動態連接庫的使用的主要是：

dlopen：打開動態加載庫

dlsym：獲取接口函數指針

dlcose：關閉庫

這三個函數就能夠在程序運行時加載動態連接庫了。爲了達到模塊準實時熱插拔的目標咱們還使用了Linux下的inotify,

inotify是一種文件系統的變化通知機制，如文件增長、刪除等事件，能夠馬上讓用戶態得知。咱們在RTB程序啓動過程當中向系統註冊了inotify事件來監控配置文件，當配置文件被修改的時候當即通知程序從新加載配置文件

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

cookieMapping分在線和離線兩種，一般狀況下廣告投放過程當中會有幾個場景會發起cm

第一種，廣告主網站上布碼以後當訪客訪問廣告主網站時觸發js，dsp會主動向各家對接事後的adx進行cookiemapping

第二種，廣告投放過程當中，當dsp的出價的同時會帶上廣告展示代碼裏面也包含有cm代碼，當出價高於其餘dsp的時候，廣告代碼會被吐到媒體網站，相應的也會觸發cm

第三種，當在adx消耗金額達到必定水平，像Tanx會按照消耗比例天天向dsp發起必定比例的dsp沒法識別用戶的cm請求，這個時候dsp也會向其餘adx發起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://samy.pl/evercookie/

移動端的身份標識，安卓的包括android id，mac地址IMSI和IMEI，而iOS是IDFA。因爲移動設備上安裝的app裏能夠嵌入SDK，而app有可能在移動端的權限也不一樣獲取到的標識也會有差別，因此最終也會涉及到用戶標識統一識別的問題，固然移動端的用戶標識會遠比PC端要強不少，移動廣告化以後用戶畫像將會更加的準確。

做者：宿逆 連接：https://www.jianshu.com/p/0d14c0faf531 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。