摘要：這是廣告系列的第一篇。廣告的核心是服務廣告主，爲廣告主圈定對應的人羣從而達到好的廣告轉化效果。而在其中起到橋樑作用的就是標籤。廣告主會根據自身的性質選定一類或幾類有明顯特點的人羣，這裏用標籤表示。而我們要做的就是給用戶打上標籤，然後提供給廣告主使用。廣告主選擇標籤，而標籤後面則代表人羣。本文基於實戰項目介紹如何爲廣告主圈定人羣以及如何刻畫用戶對標籤的興趣度得分。
本系列文章主要結合實際項目圍繞廣告行業出發，涉及統一興趣建模、NLP文本理解、圖計算等等內容，會持續更新。對相關內容感興趣的小夥伴可以關注，互相探討學習。
文章目錄
-
更通俗的理解爲廣告主圈合適的人羣
-
構建廣告主和用戶之間的聯繫
-
如何刻畫用戶對標籤的興趣度
01 更通俗的理解爲廣告主圈合適的人羣
圖 1 爲廣告主圈人羣
廣告主是幹什麼的？通俗的理解有點像甲方。廣告主說我現在想投入1W塊提升下自身的影響力，這裏的提升影響力可以是增加點擊人數、下載人數、註冊人數等等。
有甲方那肯定就有乙方。乙方就是我們移動端廠商。甲方有錢，而我們乙方則可以說是有展示廣告的資源。過去廣告行業可能是這樣的，有個廣告主想打廣告，看到有棟大樓有個很顯眼的位置空着，然後廣告主就找到大樓的擁有者說，我出1W塊，想在你這個空着的位置打個廣告，然後大樓的擁有者收了錢，在上面貼了廣告。
隨着移動互聯網時代的到來，大家花在手機上的時間越來越多。而對於移動廠商來說，賣出的這X億部手機都可以是移動的廣告展示位。區別在於什麼？以前的廣告就貼在那棟樓上，來來往往的人都能看到。而現在的廣告是”千人千面”。同一時刻小A的手機上展示的是傳奇遊戲的廣告，而小B的手機上可能展示的是東方仙俠的廣告。對應到圖1中移動廠商就提供了中間那個展示廣告的大盤子X億部手機終端。
如何做到給不同的人展示不同的廣告呢？這就是我們標籤團隊要做的事情了。我們需要構建廣告主和手機用戶之間的聯繫。對應到圖1中，我們要將大盤人羣根據不同的興趣愛好給用戶打上不同的興趣標籤。
02 構建廣告主和用戶之間的聯繫
圖 2 廣告主和用戶聯繫圖
構建廣告主和用戶之間的聯繫主要經過以下五個步驟：
1、構建一個興趣類目體系
這個興趣類目體系就是廣告主選擇人羣的一個標準。興趣類目體系需要覆蓋所有廣告主需求。現在我們可能存在這樣一個簡單的興趣類目體系：
其中傳奇遊戲標籤就代表對傳奇這一類遊戲有興趣的人羣。
2、建立用戶操作行爲的關聯user-item
用戶對手機的所有操作行爲都屬於item，比如用戶登錄app、登錄網址等等都屬於用戶操作行爲。這裏用戶操作手機行爲用user-item來表示。user-item的數據來源主要是通過手機終端埋點獲取。實際項目中數據源可能會用到app、ad、site、query_word、news、微信小程序等等。
3、建立數據源和標籤的關聯item-tag
其實就是給數據源打上標籤。拿app舉例，比如成龍大哥代言的一刀傳奇我們可以打上傳奇遊戲標籤，而這些標籤的制定都是在第一步興趣類目體系中完成的。
給數據源打標可以通過人工標註或者模型打標。目前項目中app打標採用的是人工打標，主要原因是app數量較少，通過人工打標即可完成app識別。人工標註app也存在很多問題，比如同一個app不同的人由於社會閱歷、經驗等原因會打上不同的標註。如何更精準的給item打標也是目前項目中一個非常棘手的問題，這個後續會總結一些項目經驗和大家一起探討。
而新聞資訊news和用戶搜索詞query主要通過模型打標，主要使用的是NLP裏大名鼎鼎的BERT模型。這裏打個小小的廣告，廣告系列的第二篇文章會主要講一下在實際項目中如何使用BERT來給數據源打標，有興趣的小夥伴可以關注一波。
4、建立用戶和標籤的關聯user-tag
根據user-item和item-tag我們可以構建user-tag的關聯。有的小夥伴可能要問怎麼做？將上面兩種關係分別持久化到hive表中join一下就能拿到user-tag的關聯了。通過上面四個步驟我們已經得到人羣和標籤的關聯了。
5、廣告主從標籤池中選擇標籤圈定人羣
廣告主會根據自身的需求選擇一個或者多個標籤，而這些標籤背後都有各自對應的人羣。這裏人羣可能存在重疊，也就是說有人可能既喜歡傳奇遊戲，還喜歡西方魔幻遊戲。
廣告主和標籤的關係是多對多的關係，一個廣告主可以選擇一個或者多個標籤，而一個標籤也可能被一個或者多個廣告主選中。
總結下整個流程：首先我們會制定一個興趣類目體系；然後分別構建user-item和item-tag的關聯；接着根據user-item和item-tag進行join即可拿到user-tag的關係。到這裏我們已經給用戶打上對應的標籤了；最後廣告主會根據自己的需求去標籤池中選擇標籤，選擇標籤就是選擇人羣，最終完成了給廣告主圈人羣的整個流程。
03 如何刻畫用戶對標籤的興趣度
通過上述部分我們已經生產出了user-tag的關聯。現在有個新的問題，假如現在有個成龍大哥代言的一刀傳奇app，現在有100W人登錄這個app，按照上述流程我們會給這100W人打上傳奇遊戲這個標籤。有個對傳奇遊戲標籤感興趣的廣告主想打廣告，而廣告主僅僅需要曝光50W人。那麼如何從這100W人羣中選擇需要曝光的50W人羣？
因爲廣告展示位本身是有價值的，有效曝光(曝光並且有轉化)會爲我們手機廠商帶來廣告收益，而無效曝光(曝光無轉化效果)則會讓我們白白浪費資源，所以我們希望選中的50W人會有更好的曝光轉化效果。廣告的轉化效果越好，廣告主就願意出更多的錢來投廣告。
來段題外話，現在廣告行業競爭也異常慘烈。一般廣告主會同時在多個平臺投放廣告，並進行對比。如果他在頭條或者騰訊都花了1W塊，但是騰訊帶來的廣告效果更好，那廣告主爲什麼不把更多的錢花在騰訊呢？所以如何選出廣告轉化效果更好的這50W人羣，這就需要刻畫用戶對傳奇標籤的興趣度得分，選擇得分高的用戶進行曝光。
如何刻畫用戶的興趣度也是該篇的重點內容。通過統一建模流程我們可以系統批量的生產標籤。
統一建模流程整體架構如下：
圖 3 統一建模整體架構
1、如何計算當天用戶的興趣度User-tag(score_daily)
User-tag(score_daily)主要是計算日維度用戶u在標籤t上的得分。
這裏拿app舉例，其他數據源item計算流程類似。得分score_daily代表用戶u在當天d對標籤t的興趣度，計算公式如下：
該公式主要由三部分組成：
下面分別講解上述三部分：
1.1、用戶u使用app的程度W_behave
這裏用戶使用app可以是登錄次數、登錄時長、付費次數等等。
如果對於app行爲只看登錄時長，那麼用戶使用app的程度由用戶u使用app的時長在所有使用該app的時長排名來決定。W_behave的計算公式如下：
其中MTS_mid表示使用該app的所有用戶的時長的中位數。而MTS_u,i表示用戶當天使用app的時長(同時修正異常值)，單位爲秒。TS_u,i表示用戶使用app的時長。
MTS_u,i計算公式如下：
min中後半部分表示使用該app的所有用戶的時長均值加上3倍的標準差。
有些小夥伴可能要問W_behave如何修正異常值？W_behave公式中min部分的取值爲0或1。當出現異常數據時(最明顯的是用戶u使用app的時長大於1天)會設置爲1，因爲按照日維度計算計算情況下用戶一整天使用app，但不可能大於1天。公式中max部分取值爲大於等於0的值。當出現異常值時比如MTS_mid大於1天的時間時log部分會是負數，則會自動置爲0。而正常值時則會顯示一個正數。
如果覺得上述流程太複雜
，那麼W_behave通俗簡單的理解是分位數。
比如小A當天使用抖音的時長爲5個小時，超過了90%的抖音用戶，那麼我們可以簡單的設置W_behave=0.9。
在實際項目中可能使用的是用戶的多種操作行爲，比如同時使用登錄行爲和付費行爲，這樣涉及到不同行爲的權重也是不同的。對於遊戲類app我們主要看中用戶的付費行爲，所以付費行爲的權重會大於登錄行爲的權重。
1.2、App本身的重要程度W_importance
這裏使用了類似TFIDF的策略，主要目的是對活躍人數多的app進行打壓。通俗的理解是如果一個app比如微信很多人都會登錄，那麼使用這個app去識別某個標籤的能力會大大降低，我們就會認爲這個app的重要程度很低。而這類app本身對於興趣標籤挖掘意義不大。反過來，有些人數不是那麼多的app它更能識別對該類app是否有興趣。
W_importance的計算公式如下：
其中N代表大盤總的人數，n_i代表某個app的使用人數。舉例來說，極端情況下當一個app所有人都使用了，那麼它的重要性爲0。
還拿抖音舉例，假如N代表當天所有使用app的人數爲2億，n_i表示抖音用戶爲1億，那麼抖音app的重要度W_importance=log(2/1)=log2
1.3、App所屬標籤的可能性W_tag_possible
設置這個的原因是針對item理解的時候會同時採用人工標註和機器學習模型識別。針對人工識別的app我們會設置爲1，而對於通過機器學習模型打標的app我們會設置爲概率值(因爲使用機器學習模型時通常會輸出一個判定爲正例的概率值)。
總結下，通過上述一大推猛如虎的操作我們可以得到在app數據源上用戶u當天在標籤t上的得分score_daily。通過score_daily我們可以很好的刻畫當天哪些用戶更有廣告價值，而這些用戶可能會帶來更好的廣告轉化效果。
這裏咱們的核心目標永遠是廣告轉化效果，廣告轉化效果，廣告轉化效果！重要的事情說三遍。計算用戶u當天在標籤t上的得分流程對應圖3中黃色的方塊部分。
2、如何計算一段時間內的用戶興趣度User-tag(score_p_daily)
通過上述我們可以得到用戶u在當天標籤t上的得分score_daily。但是僅僅考慮當天用戶在標籤t上行爲就決定是不是給用戶打上對應的標籤是不合理的。
比如有個用戶在過去一個月經常登錄傳奇遊戲，但是昨天因爲某些原因並沒有登錄傳奇遊戲，所以我們就沒有給這個用戶打上傳奇遊戲標籤，這顯然很不合理。反應用戶興趣標籤應該考慮一段時間內的行爲而不是某一天，所以用戶最終的興趣得分應該是當天用戶u在標籤t上的得分和最近一段時間上累計的興趣得分共同來決定。計算公式如下：
其中score_p_d(u,t,d-1)代表前天用戶u在一段時間內(一般設置爲3-6個月)在標籤t上累計的興趣得分。
score_d(u,t,d)代表昨天當天用戶u在標籤t的上的得分，也就是上一部分得到的score_daily。α_t代表衰減係數，該值表示當前用戶最終興趣得分在最近一段時間得分和當天用戶u在標籤t上的得分的一個權衡。α_t的計算公式如下：
舉例來說，如果我們認爲用戶在90天裏沒有登錄某個標籤的app，那麼我們認爲該用戶u在標籤t上的得分最終降低爲0.0001。當降低到0.0001時我們認爲用戶對該標籤已經沒有興趣。那麼
總結一下，刻畫用戶u在標籤t上最終的興趣得分不僅要看用戶當天對標籤t的興趣得分，還要看最近一段時間內累計的興趣得分。計算score_p_daily流程對應圖3中紫色的部分。
3、多個數據源融合
通過上述部分我們可以得到用戶u在app數據源上在標籤t上的最終興趣得分，該興趣得分可以反映用戶在一段時間內對該標籤的興趣程度。
實際項目中我們不僅僅會用到app數據源，還會包括新聞資訊news、網址site等等。所以我們需要將不同的數據源的得分進行融合得到在多種數據源下最終的興趣得分，計算公式如下：
其中weight_i代表數據源i的權重，score_p_daily_i代表用戶u在數據源i上累計興趣得分，將所有數據源上的得分乘以數據源的權重然後累計相加得到最終的興趣得分。
通過融合多個數據源我們得到了用戶在多個數據源下的綜合的興趣得分，我們稱爲統一興趣建模流程。
到這裏，大功告成。總結一下，通過統一建模流程，我們可以批量生產標籤，通過控制底層數據源的標註可以動態的增減標籤，更好的滿足廣告主的需求。
說點輕鬆的
文章裏一直在拿傳奇遊戲舉例子。一個很重要的原因是小時候有幸經歷過傳奇遊戲風靡的時代，還記得那時候想盡一切辦法偷偷去網吧上網而被媽媽抓住暴打的樣子。那個戰法道橫行的時代，和公會的小夥伴一起攻打過沙巴克，還有我最喜歡的法師職業。可能是那個年代裏大家很難忘記的回憶。也許正是因爲這個原因，儘管現在比傳奇遊戲好玩的遊戲有那麼多，還是有那麼多中年油膩大叔會願意花很多很多錢去玩傳奇遊戲。這也是目前我們遊戲板塊傳奇遊戲依然是重頭角色的原因吧。而我加入標籤團隊的第一個標籤優化任務就是傳奇遊戲標籤。一點感慨，不過是青春罷了。
下一篇會通過使用NLP中BERT模型對資訊news、用戶搜索詞query進行文本識別，從而給這些數據源進行模型打標。
喜歡本類型文章的小夥伴可以關注我的微信公衆號：數據拾光者。我會同步在知乎、簡書、csdn等平臺。也歡迎小夥伴多交流。
關注
