4月17日QCon業(yè)務(wù)架構(gòu)專場(chǎng)會(huì)議上，騰訊QQ空間營(yíng)收功能后臺(tái)技術(shù)負(fù)責(zé)人馮啟航以“QQ空間平臺(tái)百億級(jí)流量的社交廣告系統(tǒng)海量實(shí)踐”為主題，用自身在QQ空間增值營(yíng)收服務(wù)上的多年探索經(jīng)驗(yàn)，為大家分享了他對(duì)于大數(shù)據(jù)為增值營(yíng)收帶來(lái)新的增長(zhǎng)引擎的獨(dú)特思考。以下是馮啟航的分享實(shí)錄：

馮啟航：大家下午好，我是來(lái)自騰訊的馮啟航，2010年畢業(yè)一直就職于QQ空間，現(xiàn)在是QQ空間的營(yíng)收以及人工智能后臺(tái)的負(fù)責(zé)人。今天要講的是我們一直建設(shè)了差不多四年左右的廣告系統(tǒng)。互聯(lián)網(wǎng)的商業(yè)模式就是流量變現(xiàn)，這對(duì)產(chǎn)品很重要的過程，做營(yíng)收的，怎么把流量合理應(yīng)用起來(lái)，是我們一直要解決的問題，今天分享的就是怎么流量變現(xiàn)的服務(wù)實(shí)踐，以往講廣告系統(tǒng)挺多是講廣告的算法，今天是更多的講工程實(shí)踐。

***部分講業(yè)務(wù)背景，第二部分講我們?cè)诩軜?gòu)過程中的一些設(shè)計(jì)思路，列舉一些具體的案例看看實(shí)踐的問題，第三部分講一下做ROI提升做的事情，***再小結(jié)一下。

業(yè)務(wù)背景：空間里的廣告除開廣點(diǎn)通的效果類的展示廣告外大部分流量都是自己平臺(tái)管理的，比如有品牌類展示廣告，還有平臺(tái)自身的推直播、UGC功能，黃鉆收入的需求，我們這些視作內(nèi)部的大廣告主，他們的問題是我們聚焦要解決的。

今天分享的系統(tǒng)叫QBOSS，取這個(gè)名字是最開始建設(shè)定位于Qzone業(yè)務(wù)支撐系統(tǒng)，隨著發(fā)展，QQ空間等產(chǎn)品接入廣告渠道有數(shù)百個(gè),系統(tǒng)每天的有三百億左右的日常流量，流量訪問是很大的，日常峰值40萬(wàn)每秒，性能要求高，我們的要求是整個(gè)廣告請(qǐng)求耗時(shí)在50ms內(nèi)。

架構(gòu)設(shè)計(jì)的***步是理清一些業(yè)務(wù)概念。

中間核心是廣告，根據(jù)廣告的業(yè)務(wù)特點(diǎn)分了四個(gè)維度四個(gè)方向上設(shè)計(jì)了概念。首先在廣告的左側(cè)是建立渠道的概念，有利于規(guī)范的管理。右側(cè)是體現(xiàn)平臺(tái)和產(chǎn)品運(yùn)營(yíng)導(dǎo)向的一些內(nèi)容，例如作為對(duì)平臺(tái)健康來(lái)說，防止廣告對(duì)用戶進(jìn)行騷擾也很重要，比如用戶重復(fù)看過的廣告還出現(xiàn)這是不允許的，還有就是按時(shí)間排期，優(yōu)先級(jí)等體現(xiàn)平臺(tái)產(chǎn)品的運(yùn)營(yíng)導(dǎo)向的。上面的方向是真正用戶能夠感受到廣告體驗(yàn)的，我們稱為資源，它分為兩部分，一個(gè)是素材數(shù)據(jù)，這個(gè)圖片是什么樣子，視頻是什么樣子，這是素材問題，另外還有一個(gè)很值得說的，對(duì)開發(fā)者我們給他一個(gè)控制展示邏輯json模板的DIY定義機(jī)制，他是能夠支持開發(fā)者結(jié)合渠道制定自己展示邏輯，這也是一個(gè)很關(guān)鍵的設(shè)計(jì)，它做到了讓渠道業(yè)務(wù)的邏輯和廣告系統(tǒng)解耦，而且對(duì)開發(fā)組非常友好。廣告概念下面的方向是講用戶細(xì)分，廣告給更合適的用戶，避免全量用戶去展示，騷擾用戶也浪費(fèi)了流量。在這個(gè)方向也有很多算法和大數(shù)據(jù)的發(fā)展空間。

騰訊通用技術(shù)積累

看經(jīng)典的三層架構(gòu)里，接入層有TGW WNS MSF TSW等，。中間層里SPP是騰訊內(nèi)部最多使用的后臺(tái)服務(wù)開發(fā)框架，把網(wǎng)絡(luò)通信相關(guān)的功能都已經(jīng)收歸了。還有一個(gè)同步中心，這是我們Qzone自研的，因?yàn)镼zone這樣量級(jí)的產(chǎn)品肯定是存在異地服務(wù)的，現(xiàn)在是深圳、上海、天津三地同步服務(wù)的，就涉及到數(shù)據(jù)的同步問題，我們都抽象成一個(gè)公共服務(wù)建設(shè)出來(lái)做了同步中心。另外我們用的比較多的是SSVR，它類似于一種隊(duì)列型的服務(wù)，但是不一像大家經(jīng)?？吹降脑脐?duì)列的服務(wù)，我們是一個(gè)流水來(lái)實(shí)現(xiàn)本地隊(duì)列的服務(wù)，這個(gè)簡(jiǎn)單可控，實(shí)踐證明這么多年用下來(lái)沒出什么問題。存儲(chǔ)層的選型比較多，首先CKV是騰訊最廣泛使用的產(chǎn)品，CDB是在MySQL上建立起來(lái)的，Redis用的也是比較多，TDW是針對(duì)海量數(shù)據(jù)做的一個(gè)數(shù)據(jù)庫(kù)。

左邊是一些系統(tǒng)或者組件，比如織云是我們的運(yùn)維門戶包含了很多運(yùn)維標(biāo)準(zhǔn)工具和流程;L5是做負(fù)載均衡的，羅盤、DC上報(bào)、CRA等是報(bào)表系統(tǒng)依賴的系統(tǒng) ，神盾是推薦引擎，另外當(dāng)然有成熟CDN支持我們的廣告素材數(shù)據(jù)發(fā)布和訪問。那我們搭一個(gè)海量系統(tǒng)還需要做什么事情?用它來(lái)湊一湊，這個(gè)就比較靠譜了?其實(shí)整個(gè)廣告系統(tǒng)麻雀雖小五臟俱全，很多非核心服務(wù)我在這里就不贅述了。今天重點(diǎn)講的在線服務(wù)有策略中心、用戶中心，數(shù)據(jù)中心，還有離線處理部分，主要把用戶的數(shù)據(jù)處理上去。我們的客戶系統(tǒng)終端覆蓋PCQzone，獨(dú)立版APP，QQ，接入渠道是個(gè)人中心，應(yīng)用開屏，F(xiàn)eeds廣告。先看策略中心是很綜合的一個(gè)服務(wù)，相當(dāng)于廣告系統(tǒng)的中控，把SSP \DSP\DMP都結(jié)合起來(lái)了。這里都是重控制邏輯的部分，分享里也不贅述。

用戶中心服務(wù)，先從DMP建設(shè)開始

像上圖左邊這樣，我們?nèi)ニ鸭芏嗥脚_(tái)相關(guān)的活躍特性，你是不是黃鉆，是不是登錄活躍用戶，把這些數(shù)據(jù)建立成一個(gè)標(biāo)簽，廣告主就可以任何組合選出一個(gè)用戶群定義出來(lái)。還有一種是號(hào)碼包方式，騰訊內(nèi)部還有很多做數(shù)據(jù)挖掘的團(tuán)隊(duì)，另外騰訊的業(yè)務(wù)實(shí)在太大了，很多的數(shù)據(jù)產(chǎn)生方，不能都集合到我這里來(lái)，你必須用號(hào)碼包的方式組織起來(lái)，這個(gè)用的比較廣泛。最開始最簡(jiǎn)單的架構(gòu)就是對(duì)外服務(wù)，提供一個(gè)協(xié)議就是詢問用戶是不是這個(gè)用戶群的，服務(wù)就回答YES or NO，就是做了一個(gè)匹配邏輯，把用戶的數(shù)據(jù)和用戶群定義的數(shù)據(jù)做一次比對(duì)，這是最簡(jiǎn)單最開始的架構(gòu)，但是遇到了一些問題，一個(gè)是你DMP要做強(qiáng)大，你的tag數(shù)據(jù)一定要做的多，tag來(lái)源很多，很多的數(shù)據(jù)團(tuán)隊(duì)并不一定他的數(shù)據(jù)會(huì)放在你這個(gè)地方。就算是給你離線緩存有這個(gè)權(quán)限，對(duì)你的系統(tǒng)來(lái)說也是很大的負(fù)擔(dān)，還有個(gè)成本就是開發(fā)效率，投放體驗(yàn)優(yōu)化等，做這個(gè)系統(tǒng)的時(shí)候人力緊張，有的廣告系統(tǒng)的團(tuán)隊(duì)專門做這個(gè)，而我們這里只有一到兩個(gè)人開發(fā)做這個(gè)DMP，必須關(guān)注研發(fā)的效率。再就是內(nèi)存存儲(chǔ)成本，性能要求決定了你的存儲(chǔ)的選型只能用內(nèi)存，但是內(nèi)存設(shè)備價(jià)格太高了，如果DMP都存下所有數(shù)據(jù)那你想想這幾百個(gè)指標(biāo)要多少數(shù)據(jù)容量和設(shè)備呢?

我們帶著問題繼續(xù)往下走。***個(gè)問題，我們?cè)趺刺岣哂脩舢嬒駎ag的建設(shè)效率，之前怎樣做的呢?其實(shí)很多兄弟團(tuán)隊(duì)還是這樣做的，比如我要做年齡和性別進(jìn)來(lái)，一定是在TLV協(xié)議上取一個(gè)新的名字，這樣每增加一個(gè)tag效率是很低的 ，每個(gè)標(biāo)簽的增加需要開發(fā)介入，更改協(xié)議，更改匹配邏輯的代碼。后來(lái)我們決定，放棄這個(gè)設(shè)計(jì)，采用bit協(xié)議來(lái)管理(如下圖)，增加一個(gè)tag就是增加一個(gè)ID是很簡(jiǎn)單的事情，bit的資源就是上線一套存在就有64位上去，再增加一套就是128了，對(duì)資源有分配序號(hào)的，每一個(gè)tag要新增我就給你分配對(duì)應(yīng)的bit，我新增一堆tag沒有工作量了只需要分配。

第二個(gè)問題是增加一個(gè)適配層來(lái)處理數(shù)據(jù)來(lái)源。其實(shí)騰訊還有很多是有數(shù)據(jù)的技術(shù)團(tuán)隊(duì)，但是沒有渠道觸達(dá)用戶，我們把這個(gè)數(shù)據(jù)接入能力做成適配協(xié)議后，走出一個(gè)插件式高效率的方式開放出去。數(shù)據(jù)團(tuán)隊(duì)按這個(gè)協(xié)議寫好服務(wù)，接入就可以提供給廣告主使用了。另外適配也可以兼容一些必須實(shí)時(shí)訪問的tag數(shù)據(jù)服務(wù)方。

第三個(gè)問題是號(hào)碼包定投，一開始我們想的也比較簡(jiǎn)單，用nosql存儲(chǔ)存用戶uin為key，value是包含某個(gè)號(hào)碼包id的數(shù)組，存一下用戶在哪個(gè)號(hào)碼包里面，每次訪問的時(shí)候拿這個(gè)數(shù)據(jù)判斷就行了，看起來(lái)很簡(jiǎn)單很容易理解，但是實(shí)踐的時(shí)候會(huì)發(fā)現(xiàn)有缺點(diǎn).首先是投放體驗(yàn)，投放一個(gè)五千萬(wàn)或者一億的號(hào)碼，系統(tǒng)需要把這個(gè)號(hào)碼的所有用戶的數(shù)據(jù)都拿出來(lái)一邊讀一邊寫。那這樣一個(gè)投放操作需要影響在線的服務(wù)，因?yàn)樗脑诰€的數(shù)據(jù)，在線的容量也會(huì)受到影響，而且廣告主什么時(shí)候投放號(hào)碼包也不確定，投放幾個(gè)也不知道，對(duì)外網(wǎng)服務(wù)的穩(wěn)定性造成的風(fēng)險(xiǎn)挺大的。并且我們有三個(gè)地方的服務(wù)，深圳上海天津，如果你在深圳投放，你還要同步這個(gè)數(shù)據(jù)到上海和天津，耗時(shí)更長(zhǎng)。存儲(chǔ)回收也比較麻煩，很多號(hào)碼跟著廣告走的，廣告一旦下線，這個(gè)數(shù)據(jù)的意義就不大了，但是你很難回收。你只能把這個(gè)號(hào)碼拿出來(lái)再更新一下。我們以前做過被動(dòng)的更新，當(dāng)你用到這個(gè)用戶的時(shí)候再拿出來(lái)比對(duì)是否過期，不過這是非常被動(dòng)的。解決這個(gè)問題，我們用了Qzone自研的存儲(chǔ)利器好友參與系統(tǒng)，非常適合改造出適合號(hào)碼包的topic類型存儲(chǔ)，我們認(rèn)為topic是個(gè)主題，是否參與一個(gè)游戲、是否在一個(gè)號(hào)碼包里，都可以看作topic主題。以前最火的QQ農(nóng)場(chǎng)，你可以看到有多少個(gè)好友在玩農(nóng)場(chǎng)，上千個(gè)好友都要看他是否在玩農(nóng)場(chǎng)，這是非常大的計(jì)算量，于是我們就做了這個(gè)存儲(chǔ)系統(tǒng)。我們可以根據(jù)這個(gè)存儲(chǔ)系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)需求，把順序的號(hào)碼包數(shù)據(jù)處理成一個(gè)Btree樹結(jié)構(gòu)，還有他用tmpfs處理這個(gè)號(hào)碼包，使得每個(gè)btree文件就是服務(wù)器上可以管理的文件，可視化的，我們的深圳上海天津三地同步也很簡(jiǎn)單，只需要跨地域同步文件就可以，現(xiàn)在都是可視化操作了。管理方便，回收數(shù)據(jù)也很方便，直接刪除文件即可。性能也非常好。

數(shù)據(jù)中心服務(wù)。它的難點(diǎn)主要是管理用戶的廣告反饋數(shù)，廣告系統(tǒng)里面，數(shù)據(jù)中心和其他的和UGC很大的功能不同是，他是讀多寫多的訪問模型，為什么這么說呢?比如最普通的場(chǎng)景里：一次廣告曝光，曝光之前我需要看一下這個(gè)用戶有沒有看過這個(gè)廣告，就需要再讀一次，如果覺得這個(gè)用戶能夠被曝光，他就要寫一下廣告記錄，所以每一次曝光都需要讀寫這個(gè)數(shù)據(jù)，讀和寫的頻次都是很高的。不同于普通的功能類型產(chǎn)品，我發(fā)表一個(gè)說說相冊(cè)一般來(lái)說都是讀的情況很多，寫的情況相對(duì)很少。另外我還是存在需要異地服務(wù)接入，數(shù)據(jù)同步問題也是，因?yàn)榱看罅耍腿菀锥氯ǖ馈?/p>

數(shù)據(jù)中心服務(wù)架構(gòu)剖析：每一個(gè)地區(qū)是左邊這樣一個(gè)架構(gòu)，首先我的主要是邏輯服務(wù)，存儲(chǔ)是CKV，在邏輯上讀寫命令處理是分開部署的，代碼雖然是一起的。另外我做了快慢分離，同步轉(zhuǎn)異步，比如我要統(tǒng)計(jì)這個(gè)廣告的曝光點(diǎn)擊量，點(diǎn)擊率，第三方監(jiān)控(我在你這里投廣告你曝光了多少第三方需要統(tǒng)計(jì)一下)這些需求的性能實(shí)現(xiàn)是相對(duì)慢的，還有自己的一些統(tǒng)計(jì)功能，包括還有到同步中心的同步數(shù)據(jù)操作到另外兩地都是很慢的，這個(gè)絕對(duì)不能放在在線的寫操作里。 SSVR起到了一個(gè)隊(duì)列作用，它一部分是很快地接收數(shù)據(jù)寫入到隊(duì)列文件里去，另外再起一組進(jìn)程讀文件，按后端服務(wù)的容量，往后隊(duì)列的形式，跟后端通道通信，對(duì)后端慢的服務(wù)也是按需調(diào)度服務(wù)的，只要跑得過這個(gè)流水產(chǎn)生的時(shí)間就行了。

架構(gòu)里我們?cè)诮y(tǒng)計(jì)數(shù)據(jù)功能實(shí)現(xiàn)上做了兩個(gè)獨(dú)立的通道，左邊DC上報(bào)這是騰訊公司級(jí)的組件層面做的一個(gè)，是基于用戶維度處理，用戶實(shí)際曝光和點(diǎn)擊哪些廣告，在羅盤系統(tǒng)上做出一個(gè)統(tǒng)計(jì)報(bào)表。另外右邊在隊(duì)列服務(wù)后面我們自己做了一個(gè)統(tǒng)計(jì)的數(shù)據(jù)，我們是根據(jù)廣告ID的維度做的，我們不想再處理很大量的問題，我們不關(guān)注用戶ID信息了，只關(guān)注廣告ID的維度，所以就可以上一些取巧的數(shù)據(jù)合并操作，數(shù)據(jù)量、計(jì)算量減少顯著，很簡(jiǎn)單地?cái)?shù)據(jù)統(tǒng)計(jì)就可以把這個(gè)報(bào)表生成。兩個(gè)通道兩個(gè)獨(dú)立邏輯，兩個(gè)通道得出的數(shù)據(jù)是一致這個(gè)報(bào)表的數(shù)據(jù)就是很準(zhǔn)的。

***講一下右邊數(shù)據(jù)中心的異地同步方案。先對(duì)比一下通常的功能產(chǎn)品的模型，一般都是三地讀一地寫，比如你要看照片三地都可以看，你要發(fā)表一個(gè)照片一定要先接入到深圳收歸寫操作，然后再同步到上海和天津，這樣設(shè)計(jì)比較簡(jiǎn)化，要考慮成功率去重試、時(shí)序性等，同步服務(wù)哪個(gè)數(shù)據(jù)失敗了要重試，一定程度會(huì)堵塞通道，還比較難避開這個(gè)問題。而在這個(gè)廣告系統(tǒng)里一定是要多讀多寫的，如果按這個(gè)常規(guī)方案會(huì)出現(xiàn)一個(gè)問題：用戶在上海點(diǎn)了一個(gè)廣告，本來(lái)當(dāng)用戶第二次請(qǐng)求已經(jīng)過來(lái)了，不該出現(xiàn)廣告了，但是還出現(xiàn)了，因?yàn)閿?shù)據(jù)還在深圳往上海趕的路上。所以需要在本地直接寫好數(shù)據(jù)，所以我們只有選擇三地寫三地讀的方案，而這就要在同步中心建六個(gè)通道，比一般的產(chǎn)品投入量會(huì)大很多。所以我們要考慮如何簡(jiǎn)化設(shè)計(jì)。廣告系統(tǒng)強(qiáng)調(diào)的是實(shí)時(shí)性、對(duì)數(shù)據(jù)的三地一致性和時(shí)序性要求并不強(qiáng)烈。所以根據(jù)這個(gè)我們大膽做了一個(gè)不做堵塞通道的一個(gè)同步邏輯，而且我們同步的數(shù)據(jù)只同步一些增量動(dòng)作信息，比如我在深圳點(diǎn)擊一個(gè)廣告，我并不告訴你深圳存的是什么，往上海天津同步的就是告訴有這個(gè)動(dòng)作發(fā)生，由每個(gè)城市的被你的服務(wù)自己決定如何改寫數(shù)據(jù)。因?yàn)楹芏嗲赖慕尤氡壤彤惖胤桨覆灰粯樱栽谶@個(gè)設(shè)計(jì)上，***深圳上海天津的數(shù)據(jù)總?cè)萘亢陀脩鬹ey下面的value其實(shí)都不一樣。容災(zāi)方面假如通道有一些故障都斷的情況下，短時(shí)間斷了會(huì)形成三個(gè)“孤島”，三個(gè)“孤島”的***的問題是假如用戶在上海點(diǎn)了個(gè)廣告，下一次他又去深圳了，這個(gè)廣告就會(huì)被看到了。我們敢這么設(shè)計(jì)是大膽地嘗試，基于接入方式不會(huì)這么頻繁的變動(dòng)的假設(shè)，我們有去實(shí)際模擬驗(yàn)證一下，這樣的用戶按我們的統(tǒng)計(jì)，一天影響量才萬(wàn)分之五.而要發(fā)生這樣一整天的故障，本來(lái)在騰訊也不常見，有這樣的故障，我們的平臺(tái)肯定已經(jīng)做了其他的接入服務(wù)的調(diào)度容災(zāi)方案，例如當(dāng)初的天津大爆炸，我們很快就把服務(wù)流量切走了，不會(huì)讓用戶進(jìn)入“孤島”。

平臺(tái)海量服務(wù)運(yùn)營(yíng)能力，首先是監(jiān)控能力，接口級(jí)別監(jiān)控，實(shí)實(shí)在在統(tǒng)計(jì)他的成功率和延時(shí);用戶端是監(jiān)控，真正看你廣告拉出來(lái)的延時(shí)，還有廣告數(shù)據(jù)監(jiān)控：廣告有沒有按時(shí)出現(xiàn)，有沒有點(diǎn)擊率符合預(yù)期。其次是服務(wù)容量，不考慮研發(fā)bug的情況下，我們的服務(wù)都定型后，所謂質(zhì)量就是個(gè)容量問題，容量夠了質(zhì)量就好，容量不夠質(zhì)量就不好。容量對(duì)變化無(wú)常，這是廣告系統(tǒng)會(huì)遇到的問題，廣告計(jì)算的負(fù)載波動(dòng)比較大，特別是平臺(tái)類型的廣告系統(tǒng)，不像效果性廣告可以保持平穩(wěn)的廣告輸出量，特征是比較平的，我們這兒不一樣，比如手Q的banner有廣告沒廣告對(duì)你的系統(tǒng)有一個(gè)明顯的影響的，還有每個(gè)廣告的計(jì)算需求都會(huì)不一樣，例如是否定投計(jì)算是否驗(yàn)證曝光數(shù)據(jù)等，希望云計(jì)算的彈性能力來(lái)做這個(gè)事情，但是現(xiàn)在的技術(shù)發(fā)展情況下要快速應(yīng)對(duì)這種非常突然的負(fù)載變化時(shí)候，服務(wù)質(zhì)量不抖動(dòng)是很有難度的。那我們能做的就是，對(duì)未來(lái)要承擔(dān)的負(fù)債有一個(gè)預(yù)警，你就要去算，因?yàn)閺V告主都會(huì)有提前量，比如下午的廣告上午就投了，不會(huì)馬上生效，總有一個(gè)時(shí)間去檢測(cè)我的負(fù)債是否足夠?？偙仍谥苣┕?jié)假日突然發(fā)現(xiàn)負(fù)載不行了，措施不及要強(qiáng)。另外還有是做高性能，性能足夠我就可以在設(shè)備需求不大的情況下，留夠5到8倍的buffer，如果性能不行，同樣的buffer需要的設(shè)備數(shù)量就巨大了，運(yùn)維兄弟的壓力就會(huì)很大。 性能方面很多常規(guī)的優(yōu)化的手段都有做，例如盡可能的緩存，和對(duì)應(yīng)的淘汰邏輯，微線程的方式提供服務(wù)，堅(jiān)持業(yè)務(wù)和廣告邏輯解耦，避免json協(xié)議編解碼，還有各種分離部署，避免一些服務(wù)抖動(dòng)毛刺，例如數(shù)據(jù)中心的讀和寫以及回收多個(gè)命令字就分開服務(wù)，為了避免有些廣告可能突然間會(huì)量上來(lái)，有一些代價(jià)大的操作會(huì)給代價(jià)小的服務(wù)帶來(lái)不穩(wěn)定表現(xiàn)。容災(zāi)方面，盡量設(shè)計(jì)無(wú)狀態(tài)的服務(wù)，那么結(jié)合L5負(fù)載均衡避開單機(jī)故障印象了，我們支持城市級(jí)別容災(zāi)。值得強(qiáng)調(diào)的是抓細(xì)節(jié)吧，所謂容災(zāi)，其實(shí)一些很關(guān)鍵的服務(wù)，我們總是可以覆蓋住的，但是實(shí)際檢驗(yàn)起來(lái)讓你容災(zāi)難以為繼的可能都是一些細(xì)節(jié)，所以重在細(xì)節(jié)，找短板。

下面部分再講一下廣告系統(tǒng)ROI優(yōu)化之路，這是我們走過的彎路。首先在ROI優(yōu)化前先要找準(zhǔn)自己的瓶頸，我們的廣告數(shù)量級(jí)并不大，因?yàn)槎际谴髽I(yè)務(wù)的需求，可能廣告里就五個(gè)六個(gè)，不大于十個(gè)的廣告，但是效果廣告系統(tǒng)的廣告數(shù)據(jù)量是很大的，成千上萬(wàn)的，甚至?xí)?jīng)過初選、試選，算法復(fù)雜程度都不一樣，很多事情可以做，他可以做到千人千面。而我們需求量也不穩(wěn)定，所幸的廣告質(zhì)量是可控的，因?yàn)閺V告主離我們比較近，我們了解他們的需求?；谶@個(gè)前提，我們?nèi)ピO(shè)計(jì)適合咱們的ROI策略算法。

ROI提升實(shí)踐三種嘗試

***種是最開始走的彎路，有用戶進(jìn)來(lái)通過各種方式查體的數(shù)據(jù)查在線的優(yōu)化，會(huì)發(fā)現(xiàn)就算你知道用戶喜歡哪一類廣告，但是你現(xiàn)在的庫(kù)存里面是沒有這類廣告，你沒辦法的。同樣一個(gè)項(xiàng)目他的廣告通過更多渠道去做他，可能這個(gè)廣告的用戶群并沒有在這個(gè)渠道上投，他去了另外一個(gè)渠道也可以做，廣告主來(lái)說他投放的代價(jià)是很大的，因?yàn)槊總€(gè)投放會(huì)帶來(lái)開發(fā)成本和投放成本，因?yàn)槊壳蓝际遣灰粯拥?。第三是非常有用的方式，我還是把渠道流量給一個(gè)項(xiàng)目，但是你不能再用一個(gè)廣告了，必須要設(shè)計(jì)多個(gè)廣告進(jìn)來(lái)自己跟自己競(jìng)爭(zhēng)，不同點(diǎn)在于廣告A投的是這個(gè)用戶群，廣告B投的是另外的用戶群，或者設(shè)計(jì)多個(gè)廣告圖。讓用戶點(diǎn)擊數(shù)據(jù)說話，技術(shù)上等待二三十分鐘就可以選出來(lái)優(yōu)劣，讓點(diǎn)擊率高的廣告生存下來(lái)，這個(gè)策略最直接的作用就是起到廣告主和用戶間的溝通橋梁，你做的工作好壞用戶會(huì)給你反饋，這個(gè)是刺激到廣告主你要去用新做一個(gè)廣告，其實(shí)很多廣告投放也很有門道的。有了這個(gè)反饋廣告主會(huì)更善于利用流量，ROI提升落到實(shí)處了。

ROI另外一些很重要的功能點(diǎn)就是負(fù)反饋。我們分析過，有的人看廣告七次都不會(huì)點(diǎn)進(jìn)來(lái)，你給他投放再多次或者其他類型的廣告他也不會(huì)點(diǎn)，他選擇性地忽視了，這部分人群不要給他出廣告，對(duì)他來(lái)說他體驗(yàn)也好了，對(duì)我們來(lái)說我們收益上也沒什么損失，還減少了騷擾。還有是頻率限制，流量出來(lái)后并不是馬上給它消耗完，平穩(wěn)地在一天或者更多天消耗完。甚至發(fā)現(xiàn)一個(gè)偶然的好處，第三方投放的時(shí)候，因?yàn)樗麄兺惶繯zone流量的威力，經(jīng)常網(wǎng)站頂不住，等到網(wǎng)站頂住了的時(shí)候，流量卻消耗完了。雖然廣告主不知道我們Qzone的流量有多厲害，但是他肯定知道他的網(wǎng)站可以頂多少訪問量，按需做頻率限制就做好了廣告的轉(zhuǎn)化體驗(yàn)。

還有一個(gè)是Qboss人群分析統(tǒng)計(jì)，你投完之后我們可以測(cè)試這個(gè)tag組選的好還是不好，你選一組tag后，我們統(tǒng)計(jì)出曝光和點(diǎn)擊人群里，符合這個(gè)tag的占比多少，如果兩個(gè)持平了，可能說這個(gè)tag在廣告受眾里不是很明顯的東西，如果點(diǎn)擊比例高于曝光的，這就是很正向的tag，反之就是負(fù)向的。通過這個(gè)工具，廣告主就學(xué)習(xí)到了經(jīng)驗(yàn)，以后投這類廣告的時(shí)候你就是知道優(yōu)先要投哪部分人群。

ROI提升的事情我們是去年12月之前結(jié)束的，看各渠道的點(diǎn)擊率提升，有的是百分之十幾，有的是百分之三四百，這個(gè)是符合預(yù)期的，我們提供的只是一種工具，一個(gè)反饋渠道讓廣告主得到信息和經(jīng)驗(yàn)。你自己廣告主的優(yōu)化必須是你自己想辦法做的事情，做的好就是百分之四百，做的不好你還是百分之十幾。

系統(tǒng)架構(gòu)設(shè)計(jì)心得

我們技術(shù)價(jià)值一定要體現(xiàn)在業(yè)務(wù)上面，我們開始做的廣告系統(tǒng)，比如今天講的聽起來(lái)很樸素的，但是他能解決業(yè)務(wù)問題就是一個(gè)好的東西。還有是職責(zé)識(shí)別，我們把一個(gè)廣告系統(tǒng)分成3個(gè)大的方向，每個(gè)大的方向有它的職責(zé)范疇，抽象一下也就能滿足大系統(tǒng)小做的要求了，一個(gè)復(fù)雜問題簡(jiǎn)單化，比如用戶中心這塊兒你只需要給我判斷這個(gè)用戶是不是用戶集的，別的問題都不用管。再是抽象一個(gè)層，可以解決很多需求問題。善于在存儲(chǔ)上做性能提升例如redis的成功，邏輯很簡(jiǎn)單，性能也非常好，包括我們剛才介紹的好友參與系統(tǒng)都能很快解決問題。低成本的優(yōu)化思路上盡量?jī)?yōu)先考慮業(yè)務(wù)場(chǎng)景特點(diǎn)的利用，如果成本高，首先可能考慮到存儲(chǔ)的介質(zhì)優(yōu)化，看看有沒有一些數(shù)據(jù)協(xié)議壓縮等等手段，可是收效不一定好，我建議大家還是從業(yè)務(wù)家度上考慮問題，可能他給你帶來(lái)的是上十倍百倍的成本節(jié)約，廣告系統(tǒng)就大量利用廣告短期時(shí)效性的特點(diǎn)去做了很多成本節(jié)約。盡量做無(wú)狀態(tài)的服務(wù)，能夠保證你的負(fù)載均衡一致性，容災(zāi)也方便。還有各種部署的分離，在一些小的系統(tǒng)里這個(gè)有點(diǎn)多余，但是在海量系統(tǒng)里這個(gè)還是很有必要的。***我們所有的架構(gòu)設(shè)計(jì)都是依賴自己的數(shù)據(jù)方面經(jīng)驗(yàn)的，但是在你上線前或者后一定要通過數(shù)據(jù)驗(yàn)證它。例如我們?cè)O(shè)計(jì)的異地同步方案，容災(zāi)的考慮就有數(shù)據(jù)調(diào)研，上線后也去驗(yàn)證了，這樣我們才能讓這個(gè)架構(gòu)繼續(xù)工作，也有利于后續(xù)的經(jīng)驗(yàn)積累。