秒針系統網路廣告交易平臺介紹

小雷FansUnion發表於2015-10-01
2012~2013年，還在北京秒針系統工作的時候，接觸到了“網路廣告交易平臺”這個專案。雖說沒有親自參與這個專案的開發，但是自從瞭解到這個專案的存在，就非常感興趣。

   最早知道，是瞭解同事同學的工作，看看別人在做什麼專案。
   正此時，我的學習興趣非常濃厚，這個專案的文件非常齊全，而且很有技術含量，就重點研究了下。
   說到秒針，我最喜歡的地方是，SVN上有很多專案和文件，很多專案只要知道專案的英文名稱，就可以down下來。文件裡的資訊還是很豐富的，通過以前的文件，還可以知道公司過去是怎麼發展過來的。

   最近，由於某個不可告人的祕密，我需要重新複習下這個系統，因此有了本文。

系統介紹：網路廣告交易平臺，主要運用實時競價（Real-Time Bidding）相關技術作為核心，服務於廣告主服務平臺（DSP）和媒體服務平臺（SSP）
  媒體服務平臺，主要服務於入口網站等各種媒體網站，這些媒體上會展示很多廣告。展示這些廣告，媒體內部有專門的系統，也可能會和其它專業的廣告投放系統DSP對接。

 媒體擁有廣告位，展示廣告就獲得費用。廣告主可能直接和DSP聯絡，或者說DSP就是個工具，服務於廣告主。廣告主不希望花冤枉錢，投放廣告也希望達到更好的效果。

廣告交易平臺，是個中立的平臺，把SSP和DSP“連線”起來。SSP擁有廣告位，DSP有廣告，為了雙方利益最大化，通過實時競價進行匹配。
比如說，新浪體育頻道的使用者大多是喜歡體育，籃球足球之類的，那麼在這個頻道展示“籃球”“球鞋”等廣告就更有價值。代表廣告主利益的，如果想打球鞋廣告，在這裡就是合適的，同樣的曝光次數等條件下，“廣告主願意付更多的錢”。
 

   系統架構：

  a.Exchange網站

     Exchange網站主要實現三部分功能：一是提供API供DSP使用；二是提供Web介面供媒體機構使用者和AE使用者使用；三是提供網站和伺服器間通訊功能，保證網站上資訊的變化及時通知到各伺服器

 b.拍賣伺服器

  拍賣伺服器接受網頁上投放程式碼傳送的廣告投放請求，將請求資訊重新包裝為Bid Request，轉發給各個DSP；等待DSP返回Bid Response之後，解析Bid Response，對結果進行過濾和競價，獲得最終需要顯示的廣告，返回給投放程式碼在頁面上組裝展示

c.監測伺服器

   接收曝光監測和點選監測，生成曝光日誌和點選日誌(有日誌結算，方便廣告主等各方結算，有資料才有說服力，當然存在一定的誤差)

d.報表伺服器

 蒐集拍賣伺服器記錄的日誌和監測伺服器生成的日誌，計算報表，供網站展示和下載

e.Cookie Mapping伺服器   

  接收DSP發出的Cookie Mapping請求，從Cookie中取出MZID，通過302 redirect交給DSP，完成Cookie Mapping
 
  不同機構都會用Cookie等方式，標記使用者，不同機構之間合作交流時，需要把各自的ID關聯起來。 

f.投放程式碼  

   投放程式碼被嵌在媒體的頁面上，當頁面曝光時，向拍賣伺服器傳送廣告投放請求，獲得拍賣伺服器的返回以後，組裝廣告程式碼完成廣告的展示和監測請求的傳送

g.模擬測試系統   

   模擬測試系統包括模擬DSP和模擬媒體兩部分，用於輔助完成Exchange的測試

  

Exchange網站技術架構：

View：用jQuey做為基本的JS框架，前端用sitemesh進行頁面佈局。

Controller：採用SpringMVC框架進行流程控制，DSP通過API介面進行資料匯入、更新、檢視，管理員可以為廣告位上傳預設物料。

Service：採用Spring框架進行事務和業務處理，使用spring定時任務進行db檔案的讀取與儲存，使用HTTPComponents對媒體、物料、伺服器等修改資訊做推送處理。

DAO：採用Mybatis框架對資料庫進行操作，儲存媒體、DSP、伺服器、廣告主等資訊，同時儲存報表資料。


Java Web開發，只要是入門了，做2個專案，不懂的就去網上找資料，還是比較容易的。
個人認為，關鍵還是自學能力，解決問題的能力。

學IT技術開發，我覺得是非常“公平” 的，自身資質不太差的情況下，學得越多，工資越高。達到瓶頸1.5萬~2萬的工資後，才需要自己想辦法突破。

相關文章