作者：人月神話，新浪博客同名

簡介：多年SOA規劃建設，私有云PaaS平臺架構設計經驗，長期從事一線項目實踐

最近大家可能都注意到，今日頭條App端和后臺管理端都增加了文章統計分析的詳細數據，可以看到展現瀏覽詳細數據，點擊率，評論轉發量，用戶平均流量時長，數據按天的時間趨勢圖等詳細數據分析。

因此今天準備先從今日頭條的推薦機制分析開始，談下從文章推送到文章詳細數據統計的技術實現機制和關鍵點。在分析前我們還是先看下電商平臺推薦引擎的內容，要明白文章本身也是一個商品，實際上核心的推薦引擎思路和電商推薦引擎基本還是一致的。

電商平臺推薦引擎機制分析

推薦引擎在當前電商平臺用的相當多，推薦引擎的分類一般可以分為基于大眾行為的推薦引擎和個性化推薦引擎。

大眾行為的推薦引擎，對每個用戶都給出同樣的推薦，這些推薦可以是靜態的由系統管理員人工設定的，或者基于系統所有用戶的反饋統計計算出的當下比較流行的物品。

個性化推薦引擎，對不同的用戶，根據他們的口味和喜好給出更加精確的推薦，這時，系統需要了解需推薦內容和用戶的特質，或者基于社會化網絡，通過找到與當前用戶相同喜好的用戶，實現推薦。

這是一個最基本的推薦引擎分類，其實大部分人們討論的推薦引擎都是將個性化的推薦引擎，因為從根本上說，只有個性化的推薦引擎才是更加智能的信息發現過程。

大部分推薦引擎的工作原理還是基于物品或者用戶的相似集進行推薦。那么參考圖 1 給出的推薦系統原理圖，根據不同的數據源發現數據相關性的方法可以分為以下幾種：

• 基于人口統計學的推薦：基于用戶的基本信息發現用戶的相關程度
• 基于內容的推薦：根據推薦物品或內容的元數據，發現物品或者內容的相關性
• 基于協同過濾的推薦：根據用戶對物品或者信息的偏好，發現物品或者內容本身的相關性，或者是發現用戶的相關性

下面根據我重新畫的圖來說明下常見的一些模式：

1. 基于用戶畫像后的推薦

注意基于用戶畫像的針對性營銷本身也是一種推薦引擎，要做到這樣首先是要對用戶進行精確畫像，然后再根據用戶畫像+商品營銷策略進行針對性推薦。

舉例來說我們要對一款發燒耳機進行針對性營銷，那么我們首先要從用戶畫像里面找到20歲以下，愛好音樂，發燒友這幾個關鍵用戶標簽，然后再進行針對性推薦。

2. 基于人口統計學的推薦

簡單來說找到用戶A和用戶B的相關性和相似性，然后將用戶A的購買行為推薦給用戶B。可以看到該模式下只分析用戶相關性，沒有分析物品相關性，也沒有分析用戶購買行為間的相關性。這種模式本身的推薦準確度個人感覺偏低，但是好處就是解決新用戶冷啟動問題。

比如當一個18歲的女大學生注冊成功后，雖然這個用戶還沒有發生任何購買，但是根據用戶相關性分析已經可以馬上就可以進行相關物品的推薦。

3. 基于內容的推薦

根據推薦物品或內容的元數據，發現物品或者內容的相關性。舉個簡單例子即當我看了一部愛情浪漫影片后，可以馬上給我推薦類似的影片。

主要什么影片是類似影片？要基于內容推薦首先就要對物品的相關性或相似性進行建模，這種相關性是靜態的關系，物品相似度的分析僅僅依賴于物品本身的特征，這里沒有考慮人對物品的態度。

舉例來說，最近幾天我都在某電商網站瀏覽某類的產品，這個時候我們根本沒有登陸電商系統，只是做了瀏覽和加購物車的操作等。可能過2兩天你就會收到電商平臺發出的EDM營銷或推薦郵件。在這種模式下即基本是基于內容推薦。當然推薦的時候電商平臺會優先幫你選擇銷量高，評價好或性價比高的相似產品。

4. 用戶相關性+用戶購買行為協同過濾推薦

注意不是單純靜態用戶相關性推薦，也不是單純的用戶購買行為推薦，而是將兩者結合起來進行協同過濾推薦。簡單來說就是首先根據用戶購買行為發現了用戶A和用戶C是相關或相似用戶，而不是根據靜態用戶屬性簡單判斷用戶相似，然后再根據相關性特點將用戶A的購買推薦給用戶C。

5. 物品相關性+用戶購買行為的協同過濾推薦

即物品相關性不是簡單進行物品靜態相關性建模，而是根據用戶購買行為來發現物品相關性。即我們常說的購買了物品A的也同時購買了物品B。比如購買了蘋果手機的用戶也同時購買了蘋果手機保護膜。

這種推薦模式是我們經常看到的模式，比如我們在電商購買購買書籍，購買某種商品的時候，實時出現的推薦都屬于這種模式為主。系統會告訴你購買了某本書的用戶一般還同時購買了哪些書籍。我們不用去探究用戶本身是否相關，而是關心用戶購買行為觸發的物品相關性。

頭條文章的推送和推薦機制

如果我們將頭條和微博比較，雖然頭條也可以關注某個頭條號或用戶，但是頭條核心的推薦仍然是基于內容的推薦機制，即本身弱化用戶之間的關系，這是頭條和微博推送的一個關鍵區別。

我們瀏覽頭條你可能也會發現一些文章推送特點。

比如我們可能會瀏覽到我們關注的某個頭條號發送的文章或微頭條，或者你最近正在關注三十而已，那么會收到大量關于該電視劇的內容推薦。或者說你最近瀏覽小孩教育方面的文章比較多，也會收到很多類似文章推薦。當然你也可能收到你居住城市的熱門內容推薦。

因此頭條整體的文章推薦機制可以理解：

核心內容推薦+關注推薦+區域推薦+熱門事件推薦組成。

注：即使你每天都花費大量時間瀏覽頭條文章或視頻，但是你時間看到的內容可能連千萬分之一都不到，僅僅是整個頭條海量內容的冰山一角。而且你瀏覽的越多，頭條越懂你，給你推薦你感興趣的內容，但是同樣也導致你的知識內容面越來越窄，這也是我們也經常說頭條會讓你變得越來越懶于思考的原因。

所以你可以看到整個頭條文章的推薦核心就是用戶本身的標簽關鍵字和文字提取的標簽關鍵字的一個匹配過程。只要匹配上那么就可以進行推送。

首次推送一般也叫冷啟動，簡單來說就是先很小范圍給你推一波，看下點擊率，閱讀量，點贊和轉發量，如果數據都不錯，就進一步給你推送到一個更大的流量池，如果效果不好往往就降低推送量或停止推薦。

用戶的關鍵詞往往都是基于用戶大量的歷史文章瀏覽所形成和提取出來的，但是對于用戶的關鍵標簽關鍵詞，本身應該形成不同的權重。

而權重需要考慮到用戶的瀏覽頻度和瀏覽時間兩個方面

• 瀏覽頻度：用戶一個長時間周期經常會瀏覽的關鍵詞，那么權重應該很高
• 時間頻度：近期瀏覽的權重高，瀏覽時間長的權重應該高

比如我們最近1，2天突然開始大量瀏覽圍棋教學類視頻，那么你可能看到頭條會大量推薦圍棋主題相關的視頻和內容文章。

也正是這個原因，即使你在頭條一個賬號都沒有關注，但是頭條仍然會根據你的瀏覽習慣和內容進行精確的內容推薦。關注和粉絲推薦反而在頭條瀏覽里面權重不高。

反之，如果你根本就沒有大量內容瀏覽和閱讀，那么頭條無法根據你的動態瀏覽行為進行推薦，則只能根據當前主流事件熱點，你關注的人，你的區域等靜態信息進行推薦，直到你產生大量瀏覽和閱讀行為后，再來分析你的內容關鍵字。

頭條文章的推送和推薦機制

最近頭條對每一篇文章都增加了文章詳細統計數據分析功能，如上圖。

即可以看到你單篇文章的展現量，閱讀量，粉絲閱讀量，點擊率，用戶平均閱讀時長。評論，點贊，收藏，轉發等用戶互動行為分析，同時還可以看到這些統計數據按天進行的時間趨勢圖分析。這些數據可以更好的方便創造者對自己創造的內容進行分析評估，并對創作內容進行持續優化和改進。任何一個自媒體創造者也是一個運營者，需要有數據驅動思維，基于數據分析來驅動自己的內容運營。

在前面我們已經談到，頭條更多是以內容驅動的推薦引擎模式。文章，微頭條，視頻等都是內容的呈現形式。而對于文章我們首先要分析行為事件和統計計算間的關系。

影響文章統計計數的關鍵行為或事件

影響文章統計計數的關鍵行為或事件，主要包括了如下內容。

• 文章進行一次推送，直接影響到文章的展現量計數
• 用戶點擊進入到文章里面，即閱讀量計數，同時退出的時候計算閱讀時長
• 用戶進行轉發，評論，點贊，收藏等，直接影響到文章的對應指標計數
• 對文章推送用戶中區分粉絲用戶，進行單獨的展現量和閱讀量計數

以上即是我們實際在文章詳細統計數據里面看到的關鍵信息。同時我們看到，對應每篇文章還提供了統計數據的時間趨勢圖，可以詳細查詢一個周期里面的統計數據信息。

對于文章推送，前面已經談到基于推薦引擎機制結合冷啟動的數據進行持續迭代文章推送。這個推送本身可能呈現為兩種方式。

• 其一：左下角首頁處出現小紅點提升，說明有了新信息推送過來
• 其二：你可以不斷的下拉刷新當前頁面，那么系統會持續推送新內容過來

另外對于數據統計，我們可以看到應該是存在一個最小刷新間隔，比如是30秒或者1分鐘，那么在這個間隔里面你可以看到展現量或閱讀量并不會變化。

其次，對于點擊率和閱讀時長，你可以看到是當天只能夠看到前一天的數據，即你可以理解為是非實時計算，可能是在凌晨計算昨天一天的最終統計數據結果，即按天增量計算。

整體實現思路初步思考

有了前面的初步思考，我們可以看到每篇文章都有一組最終的統計數據，這些統計數據可以存放到類似redis緩存庫里面。如果數據有最小刷新間隔概念，那么實時的數據計數應該在統計在內存里面，然后再更新到Redis緩存庫中。

如果以一天為一個完整的統計周期，那么Redis庫應該只記錄當天的數據，當天數據統計完成后，當天的數據應該寫入到類似influxdb的時序數據庫中，這種數據庫來實現文章的時間趨勢線分析是最合適的。

基于以上分析，以最小刷新間隔1分鐘，我們給出一個很粗的實現思路圖。

基于當前統計數據可以看到：

點擊率 = 閱讀量/展現量

那么我們再看下對應平均閱讀時長如何處理。

當監測到用戶退出事件的時候，我們就可以計算出文章的閱讀總時長。

那么在1分鐘的間隔內，我們的內存計算應該計算 閱讀總時長，這個時候不用去計算平均閱讀時長。包括到了Redis庫也是同樣道理，我們只需要將閱讀總時長進行累加計數即可。

當需要計算上一天的閱讀平均時長的時候，我們再進行計算，即：

當天閱讀平均時長 = 閱讀總時長/閱讀次數

但是注意這是當天的閱讀平均時長。而我們將每天最終的統計數據寫入到類似influxDB時序數據庫的時候，我應該計算一下文章截至到當前的總計數信息。

比如一篇文章已經發布了10天，那么我們應該有一個總計算信息，即：

第1到10天：文章ID，總推薦量A，總閱讀量A，總閱讀時長A，平均時長A

而第11天的數據我們統計后可以得到當天的統計計算為

第11天：文章ID，總推薦量B，閱讀量B，總閱讀時長B，平均時長B

在這個時候，我們不會對平均時長再進行平均，而是應該重新計算平均時長，即：

平均時長新 = （總閱讀時長A+總閱讀時長B）/(總推薦量A+總推薦量B）

另外，對應截止到上一天的匯總統計數據，這個數據應該更新到一個單獨的數據庫統計表中，這個信息可以放到結構化數據庫中共數據展現時候使用，而不是查詢的時候再去實時計算。即作者查詢文章詳細數據的時候，詳細統計數據 = 當天Redis計數+文章截至到上一天的歷史累計計數。

是否使用消息中間件

前面看到對應文章推送，用戶瀏覽，交互等各種行為事件都會影響到文章計數，那么這些事件是否都需要統一寫入到消息中間件，通過消息中間件進行削峰處理。

我個人理解是如果使用消息中間件的話可以進一步實現異步解耦，消息中間件可以替代內存計算過程，這個時候消息中間件直接對接到Redis庫即可。

當然實際上頭條最終的計算遠比我上面初步思考復雜，在這里也僅僅給出一個簡單實現思路供參考。特別是這種思路是否還存在進一步的線程安全，線程鎖定等問題。在這里就不再做進一步的分析。