http://www.360doc.com/content/15/0806/07/2909773_489803369.shtml

此文是根據付海軍在【QCON高可用架構群】中的分享內容整理而成，轉發請註明出處。

付海軍，現就職於時趣互動，任技術總監，負責移動原生廣告平臺引擎開發和資料探勘工作，06年畢業於蘭州大學，曾就職於阿里巴巴集團萬網從事主機面板和雲端計算底層開發；之後加入億瑪線上從事網際網路廣告程式化購買相關的工作，負責RTB競價投放系統和大資料平臺。對於系統架構設計和技術團隊建設感興趣，關注高併發實時系統，海量資料處理。

前言

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

廣告和網路遊戲是網際網路企業主要的盈利模式

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

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

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

2. 擁有先進的使用者定向(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廣告系統架構及關鍵技術：

1. 廣告系統概念介紹

2. 廣告系統業務流程

3. DSP系統架構

4. RTB競價引擎結構

5. 點選率預測

6. DMP資料處理架構

7. 受眾定向劃分

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

程式化購買的特點

下圖是在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和反作弊系統。

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

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

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

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

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

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

7. 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中就是需要找出相應的受眾定向，下面簡單分析一下幾類受眾定向：

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

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

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

2. 上下文標籤t(c)，即當前使用者聯絡上下文在當前的訪問行為達到的即時標籤。

3. 廣告主定製化標籤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，積累後續資料。

存在問題：基於統計資料，對舊廣告效果還可以，但對冷啟動的廣告沒有預測能力。
事實上，我們在線上做點選率預測模型，使用的演算法是邏輯迴歸，後續可能考慮會用到的廣告點選率預測方法有：

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

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

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

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

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

3. 列排序（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種：

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

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

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端要強很多，移動廣告化之後使用者畫像將會更加的準確。

本文策劃 秋翾@百姓網, 內容由國忠，陳剛編輯與釋出，其他多位志願者對本文亦有貢獻。讀者可以通過搜尋“ArchNotes”或長按下面圖片，關注“高可用架構”公眾號，檢視更多架構方面內容，獲取通往架構師之路的寶貴經驗。轉載請註明來自“高可用架構（ArchNotes）”公眾號。