類似微博的 feed 熱度演算法如何計算？

01-06

現在有2個類型的feed內容，微博和博客，都是用feed形式推送給用戶的。要計算熱度，根據熱度推送。
已有數據情況： ===
微博：轉發數、評論數
博客：轉發數、評論數、閱讀數
現在想要割統計的feed熱度計算公式，不單獨計算微博的或博客的。

請問有誰有辦法計算呢，
難點在：微博沒有閱讀數，比博客少一個參數，而閱讀數一般又很高...

A 為某篇文章的具體發布時間，精確到秒；B 為一個固定的時間常量，2008-12-01 00:00:00。則可以計算得到 A 和 B 間隔的秒數 ts。

ts=A-B

M表示某篇文章的來自於微博客的推薦次數，R代表來自於閱讀器分享的分享次數，D代表來自於網摘收藏的次數。引入不同權重因子，則可以計算得到變數Z：

Z=M*3+R*1+D*0.8

最後定義 SRRank 公式為，

SRRank=log10Z+ts/45000

參數註解基本和Reddit一樣，不同的就是沒有反對票：

1）時間點 B，2008-12-01 00:00:00，是一個固定的值。ts 反映了文章的新鮮程度。引入 B 是一個非常優雅的技巧，它使得新鮮度的度量可以獨立於系統當前時間。

2）45000 代表的是一個 12.5 小時周期內的總秒數。它與 ts 一起使用，隨著時間的推移，新文章的得分會逐漸超越高投票數的老文章，從而實現自動更新的效果。

3）log10 的使用是另外一個技巧，它可以使得早期的投票獲得更大的權重。比如，前 10 票獲得的權重，與 11 到 101 票所獲得的權重是一樣的。

http://www.cnblogs.com/zhengyun_ustc/archive/2008/12/22/ju690_sr.html

可以關注一下鄭昀的博客。

UGC與演算法|2017行業產品FEED流產品設計，我如何落地UGC信息流？

Original 2017-06-30 KEVIN Kevin改變世界的點滴

UGC的核心—FEED

由於工作原因，近期正在負責公司產品UGC模塊設計，尤其是經過需求的開發挑戰、BOSS挑戰，產品經過一輪評審、二輪評審之後，產品的需求逐漸落地下來。最近在負責產品UGC模塊，以及FEED的相關演算法

UGC社區，無論是在PC端還是移動端，其最重要的就是信息流展示，其信息流的展示方式和排序方式是我在調研的重點，這裡提出廣場、熱門兩個概念，可作為覆蓋UGC模塊的基本屬性模塊。

提到UGC模塊，產品經理在進行落地設計首先需要考慮的是用戶的社交關係，這一點在不同產品中，有弱、有強的傾向；

產品經理在進行UGC模塊設計之前，首先搞清楚其產品用戶社交關係、以及產品社交定位的強度

01用戶關係與內容源

大多數UGC的分類，都會將UGC進行內容以用戶角度與平台角度分類，推出相應內容，當然在如今的智能個性化推薦中，平台還是既能夠保證平台需要曝光的內容進行展出，也需要曝光的內容是用戶需要的內容。

【平台內容的分類】

【用戶內容】

平台與用戶如何達到一個共節點，這是PM設計UGC中FEED流的關鍵，什麼是FEED？做PM的朋友可以自己百度，這裡我就不詳細解釋了。

這裡提出一個內容源概念，在UGC設計中，在當前社區或論壇的模塊中，其信息的來源有那些？將系統、運營人員、用戶的三種角色的內容進行區分，我們可以將FEED的內容進行羅列

【FEED內容源】

為此，FEED的內容源頭我們將其區分，有利於我們進行對不同的內容進行設計，其核心欄位是什麼？運營的每個內容源核心欄位？用戶內容的行為操作所產生的內容源欄位是什麼？

這樣的最後結果可以將FEED的有效性與區分達到用戶可識別的效果，這裡以QQ他們將平台類不同的內容源進行設計，達到內容的有效性散播與增強用戶區分性

【視頻類】

【簽到類】

【系統類】

QQ將系統內容、用戶內容、用戶簽到行為的內容進行區分，毫無疑問將內容的有效性大大提供，每個FEED的核心欄位進行提取，方便了運營與用戶的玩法

02廣場與熱門

FEED的內容源與區分既然上面說了，下面就是FEED的集中展示了，這裡我以常見的廣場與熱門來舉例

廣場：所有消息的集合，系統、運營、用戶消息集合（常見的），（不排除因產品定位不同，有將系統、運營、用戶消息部分過濾）

熱門：根據演算法將熱門的內容以熱門從高——低進行排序，或以用戶活躍進行排序等（將特點權重的屬性進行排序）

【廣場舞APP中最新發布與熱門】

因此FEED的分類，需要注意的是在不同的分類其涉及的演算法就不同，或者以同一個演算法滿足所有分類，其最簡單粗暴的就是目前熱門的智能推薦系統，不管你是那個版塊，FEED的分類是怎麼樣，都可以儘可能的去推薦，滿足讓用戶看到他需要的內容。

【熱門與關注】

這裡要提出的是一個UGC中，基於用戶的生態與平台生態，這一點也是FEED的推送中算考慮中權重佔比高的2點思考點。

平台的生態也就是針對於產品中的模塊關聯性與平台中所提供的產品關聯，這一點產品經理需要考慮相關的產品是什麼？相關的功能模塊是什麼？

以UGC模塊為例，其典型的案例就是群聊與社區的模塊是關聯的；

以證券類產品來說，其錦囊與觀點的產品線是相同的；

【模塊的關聯與產品的關聯】

這裡需要重點說明的，其模塊的關聯與產品的關聯，產品經理往往一個人沒辦法全局打量，建議和幾個產品經理或LEADER一起腦暴一次，將所有可能會存在的關聯點進行列舉，這樣才能保證FEED流能夠流到各個地方。

每一個路徑就是FEED流可能流動的地方，其能流動的地方都會有用戶存在，僅能可能滿足用戶的所有對FEED的需求，除了依靠演算法，其產品的關聯與生態尤為重要。

FEED的功能關聯，這裡說一下，如果有數據體系支撐，建議通過將模塊、產品建立在數據漏斗、熱力圖進行分析，用數據驅動，會幫助產品人少走一些彎路。

之前更新過：產品數據的一些坑，可以學習

FEED流演算法與設計

這裡就是本次分享的重點，FEED流的演算法和設計落地，在這裡首先拋出幾個FEED流典型的產品體系和演算法以及2個關鍵詞

UGC產品體系：強社交體系、弱社交體系

演算法：重力排序法、時間排序法、智能推薦排序法（概述）

關鍵詞：未讀池、FEED存儲區

1.強社交體系

強社交體系的UGC社區，就是目前最典型的以微信朋友圈為代表，其微信的社交關係建立在用戶與朋友之間的鏈接，因此微信的內容為UGC的代表，微信的FEED方法就是以時間排序法，並且微信將每時每刻中，自己的好友圈所生成的FEED，都將刷新出來。關注的好友沒有權重，時間線成了唯一標準。

2.若社交體系

若社交體系的UGC社區，這裡我們以微博來舉例。微博因內容涵蓋好友與非好友，在此對於用戶的社交圈中，就屬於若社交體系。並不強調用戶與好友之間的關係，而是強調用戶與用戶的關係，微博這裡就涉及用了FEED存儲區、FEED未讀池，並且微博的UGC經歷了重力排序法到目前的智能推薦排序法的一個過渡過程。

3.時間排序法外的2個演算法

重力排序法

重力排序法，在做公司UGC模塊中，我在網上查了不少相關的文檔，其中網上對於這一塊的演算法參考資料較少，因此在學習以及自我建立過程中，我將重力排序法以案例的方式進行講解

【重力排序法】

首先重力排序法還是依靠時間進行FEED拉去，在這裡根據時間的從近到遠，依次將FEED進行拉去展示，這就是重力；權重標籤，這裡可以是指的是FEED的權重標籤，可以是內容的、也可以是針對產生FEED的對象；

比如針對內容：點贊、閱讀、轉發...

比如針對對象：關注好友、好友活躍度、好友粉絲度排序

重力排序法的意義：

因此重力排序法是基於時間的演算法，儘可能的將有效的內容展現給予用戶，讓用戶能夠去得到需求或平台高質量的內容，並且還是依據時間流的順序，不會讓用戶產生無厘頭的感覺，並且不是全是系統消息、無效的消息。但重力排序法需要給予一個時間存儲段，為什麼要這樣做？這裡在下面FEED存儲區我會說明。

智能推薦系統（概述）

針對於智能推薦，可以說是目前每個高用戶UGC社區都想做的一塊演算法，其解決的核心問題是：在平台中將用戶所需要的內容推薦給予用戶

【基礎信息的採集】

智能推薦系統通常會有一個智能推薦引擎，其中引擎就是各種演算法的結合，系統將基礎的信息採集後會分別進入相應的採集庫，通過引擎將平台中的內容推薦給與相應的用戶，這一點在行業中今日頭條一直處於領先。

【推薦引擎】

智能推薦系統，增加了用戶停留在FEED的時間長度變長的可能性，但智能推薦系統仍然是目前中小型企業所必須要去以後過渡的一種演算法，比如智能推薦系統在FEED中，給予用戶的就是非線性時間軸，用戶會有一種，昨天球賽比賽完了，但今天刷新出FEED說，「球賽開始了」這種FEED錯覺。

當然演算法的精度與過濾，也是PM需要去考慮的，這裡簡單說明下推薦系統的大概。

4.高並發量與高用戶UGC社區中，FEED的演算法設計

在常規的產品線中，用戶數量在百萬內，根據產品的屬性不同其日活躍可能在30%，也可能因為運營推廣做的數據質量太差，活躍可能在1%，但存在高並發量UGC，也就是在用戶的FEED產生能夠在一時間軸的緯度下，會有上千、上百或更多的FEED產生，如何去踢去無效的FEED，將有效的FEED推薦給與用戶，其業務流程如下：

【FEED的出入流程】

這裡用戶在拉去FEED的過程中，這裡我們常有的是三種演算法，第一種是PUSH、第二種是拉、第三種是推和拉集合。

其中推類似以FACEBOOK這樣的，將FEED推給用戶，用戶將直接接受到其FEED

【推的模式】

拉的模式恰恰相反，類似與新浪微博的形式每用戶下拉其將其FEED存儲區的FEED拉進來，而不是全部獲得存儲區的FEED。

FEED存儲區

這裡說到FEED存儲區，就要引入未讀池的概念，如何在高並發量以及高量FEED產生的情況下，保證用戶能夠索取到想要的內容？

【FEED存儲】

這個就是FEED的存儲方式，將其FEED存儲在資料庫中，我們以最近的FEED、近期FEED、比較長期的FEED，3個時間區進行存儲。

剛才上面說的關於重力排序法中，時間段的區分，就是在這裡進行時間區分，其中這個時間刷新我列舉了3個小時、1天、7天，但這個時間段產品經理應該利用自己的數據分析能力，將其UGC社區中的FEED量進行統計，預算出其可行的FEED時間劃分段

【FEED隨時間的發帖數】

如以上FEED因每天產生的內容在100條FEED左右，因此建議用3小時、1天、7天作為時間點，太短了FEED也沒有新的生成，太長了也沒辦法將FEED進行拿出

但請注意的是，這裡是的FEED並發量低的時候或量不多的時候

那麼回到剛才的問題，高並發量或高FEED量怎麼辦？

這個時候我們就要引入未讀池的概念，這也是我猜測微博所採用的一套機制。在FEED產生高並發的情況下，用戶下拉的FEED不可能把整個平台的FEED全部拉取（幾千上萬條，看都看不完），當然產生這麼多的FEED原因是因為微博的定位並不是做好友間的社交關係鏈，而是以用戶之間、人與人之間的社交關係

對於微博的UGC模塊中，FEED其核心的就在於未讀池的演算法處理（這裡我猜測是以智能推薦，早期可能是重力排序法）

【未讀池FEED】

這樣的FEED產生之後，其在未讀池中，FEED可能會出現永遠都不可能被用戶閱讀到，系統通過之前我說明智能推薦演算法，將其認為的垃圾FEED或無效FEED永遠不上傳給予用戶，因此這套機制就能夠解決高並發量的情況下，給予用戶有效的FEED

但這裡也會存在一個問題，因為FEED的產生有時間屬性，因此用戶在拉去FEED是的時候會發現有一些FEED因為不具備時間軸的順序，本來昨天發生的事情，今天才拉去出來。讓用戶產生摸不著頭腦的感覺

總結

對於FEED，這是一個UGC的必備屬性，產品經理需要不斷的學習和思考根據自己的產品業務屬性、產品定位來制定相應的演算法，但市面上大部分的產品對於FEED的把控依舊不夠，這裡的原因有很多，其中最重要的就是FEED的高並發、用戶數太少，比如微博、微信這樣大體量的產品，不是每天都可能誕生。

但是對於FEED的過濾，PM至少應該知道其演算法，在近期產品需求調研中工作中，我希望將學習到的FEED演算法共享，第一是相關資料比較少；第二是目前FEED的演算法相對來說其門檻較高。

另外關於深圳線下分享會

之前有一個帖子，KEVIN也說了正在和小夥伴們籌備深圳線下產品分享會帖子在這裡啟動|Kevin和他的產品朋友線下沙龍分享會（深圳地區）

這裡建立了個深圳分享會的群，有興趣或到時候可能有時間的朋友，可以先進群，相關活動的進展和情況我也會在群里說明

【KEVIN改變世界的點滴 作者：張晉壹 】

【金融產品經理一枚坐標：深圳】

【每周六，我的一次經驗分享在這裡】

最近更新：

我的三年產品基本功（PRD）|將交互、業務邏輯、需求欄位撰入文檔

3年進階之談|產品助理（專員）、產品經理、高級產品經理、產品總監應該達到什麼樣子？

2017知識付費大戰|PM如何落地付費產品設計？

撕逼的工作與完美主義的生活|產品經理工作挑戰點

繼續更新中......

【IOS用戶專享】

2017年，讓我們繼續前進！

與KEVIN一起在產品中學習交流QQ群：257051609

並且建立了第三個微信群（150人）進群請修改備註

名稱—地區——職位

寫的有點繁複。

4 day(s) ago

Most upvoted comments above

Learn about writing a valuable comment

關於微博的可以參考熱門微博上榜只是個開始不是結果

中文版Reddit：91頭條 - 來自互聯網的頭版頭條。演算法差不多。