資料運營實操案例：資訊流feeds產品最佳化

編輯導讀：本文作者帶領大家對資訊流的基礎推薦引擎和影響因子有了初步瞭解，並透過資訊流feeds資料運營中的一個實際案例梳理總結了資料運營的價值，供大家一共學習和參考。

一、資訊流引言

資訊流（Feeds）的形態已經近乎無所不在，貫穿在我們24小時的網際網路生活的當中。當你通勤時在地鐵刷刷今日頭條瞭解最新資訊，資訊流已經把一篇篇時事熱文整齊地排成佇列等待你的閱讀；當你想要好好美餐一頓，大眾點評的資訊流給你“種草”了不少同城餐廳；夜不能寐想剁手來犒勞下辛苦工作一天的自己，淘寶上琳琅滿目的推薦商品流怎麼那麼精準，刷得停不下來……

儘管資訊流這種形態已經廣泛應用，但其實最早的應用是在資訊內容場景，始於Facebook在2006年釋出的資訊資訊流（News Feed）功能。

平臺透過既定的演算法、規則排序後聚合內容，使用者可以在單頁面內進行流暢而高效的內容消費。使用者不再需要如移動互動網史前時代那樣，在入口網站、部落格站點之間進行頻繁地跳轉；平臺也透過提供聚合的內容展示平臺，更高效地把使用者留在了自己的轄區內。

資訊流的英文是“Feed”，實在是用得很妙的一詞了。Feed在英文裡是“餵養”的意思，生動地刻畫了資訊流場景裡，使用者被平臺按一定的順序“投餵”內容的場景。

使用者消費的內容時間是有限的，平臺如何在有限的時間內，給使用者投餵TA最喜歡消費的內容、從而讓TA在平臺消費更多的內容（從而給平臺帶來更高的潛在商業價值），就是所有Feed場景運營人員經年累月在不斷鑽研的“推薦排序”問題了。

二、資訊流的基礎：推薦引擎

推薦引擎的核心，是“如何把合適的物品推薦給合適的使用者”，所以“物品”和“使用者”之間聯絡的建立，是推薦演算法裡最核心的命題。整個推薦的過程基本可以總結為“召回”→“排序”→“調權”→“輸出結果”的過程，對這個過程進行一個簡單的比喻，來幫助大家理解這個過程。

大家應該都曾經在學生時代參加過軍訓，軍訓最後的分列式檢閱是整個軍訓過程的高光時刻。那該如何對佇列進行合理的排布呢？

首先，教官會需要先“召回”A班的所有學生來到操場上，等待進行排列，只能是A班的學生，其他B、C班的同學先不需要參與；

緊接著，教官會要求同學們按從高到矮的規則進行“排序”，這樣隊伍看起來就不會參差不齊；這時，雖然同學們已經按從高到矮排好了，但可能有個別學生匯演時需要在軍樂團做演奏，教官就需要對這些學生進行“調權”，把他們排除在外；

最後，按這樣的規則排列下來的隊伍，就是最後匯演時A班的隊伍排布了。

推薦演算法是一門頗深的學問，技術性也很強，但因為本書面向的讀者主要是運營人員，所以筆者嘗試從更顯性的層面總結如今影響資訊流排序的主要影響因子：

三、難題：資訊Feeds如何做冷啟動？

講到這裡，給大家分享筆者此前運營一款工具產品的經歷。大多工具產品的困境大家可能都有所瞭解：使用者停留時間長、粘性差，從而導致變現的效率和方式都很有限。市場上競品眾多，如果不能快速從資料指標上證明我們產品的價值，那整個產品都面臨著被砍掉的風險。

於是，如何提高使用者提高時長，成了我們團隊內一個很重要的命題。我們這款工具產品具有WiFi連線的功能，此前使用者在連線WiFi成功後跳轉的落地頁就是一個“連線成功”的頁面，除此之外，沒有別的承接；

但此時使用者處在操作完成的情緒高點、且在流量不敏感的WiFi場景，我們想，是不是可以透過承接資訊Feeds的內容，從而提供給使用者一些內容消費的價值，同時還創造了一個商業化變現的場景？

但我們是工具產品的團隊，此前完全沒有內容運營的經驗，要如何從0到1做一個資訊Feeds出來？分析了我們團隊的現狀，我們決定從以下幾個方面快速啟動：首先，資訊內容從哪兒來？我們的一些兄弟產品有現成的資訊內容，但具體的推薦演算法需要我們自研；我們的演算法團隊雖然沒有內容推薦的經驗，但在軟體分發上推薦的經驗，也有異曲同工可借鑑複用的地方。

巧婦難為無米之炊，“米”和“巧婦”都已具備，但要做成“炒飯”還是“湯飯”我們的使用者才覺得最好吃，我們得多嘗試才能得出結論。

推薦排序的因子那麼多，但對於我們來說，因為工具產品的屬性，所以能用的並不多。根據我們的情況，我們決定做如下三組的A/Btest實驗：

基於使用者畫像排序。我們可以獲得的使用者屬性資料有：使用者的軟體安裝列表資料，可以一定程度推測使用者的喜好；使用者的地理位置資料，可以推薦一些本地新聞、附近景點等資訊。綜合這兩方面的使用者資料，混合給使用者推薦合適的資訊內容。

基於熱度排序。因為我們拿到的資訊內容並沒有附帶在其他平臺的熱度資料，所以熱度排序在我們產品中是相對滯後的過程，需要使用者不斷透過點選行為去“投餵”給演算法進行學習，從而把產品內更熱門的內容推薦給更多的使用者閱讀。

基於資訊釋出時間排序。相當於是一個基礎對照組，不對資訊做太多演算法排序上的干預，用於對比前兩組實驗的效果。

基於三組實驗的設定，我們選定了三組隨機測試的使用者群進行策略的投放，並且設定了“平均資訊消費時長”作為關鍵評估指標。等待實驗效果回收的時間有三天那麼漫長，這三天的期間我們團隊內也在打賭哪個策略表現會最優。讀者們，你們也來猜猜哪個策略的表現會最好呢？

四、分析：找到問題更深層的原因

團隊內的打賭，基本都集中認為是前兩組的策略會更優。認為使用者畫像更好的同事的觀點直截了當，使用者會對與自己更相關的內容更感興趣。認為熱度排序效果會更好的同事也很在理，更多人點選的內容往往是獵奇新鮮的，自然也會吸引更多人閱讀。

但我們運營人員回收整理了實驗資料後，卻有點大跌眼鏡：最不為大家青睞的基於時間排序的方案三，竟然“平均資訊消費時長”都要優於前兩個方案。團隊內一時間有點洩氣，對演算法團隊同事的技術能力質疑也在暗暗有聲。

作為運營人員，此時我們需要透過資料分析去多走一步看看：資料指標所呈現的，就是全部的真相了嗎？

為了分析這個問題，首先我們對問題進行了拆解。

實驗的資料指標上：

我們設定的資料指標有沒有問題？

資料指標的計算有沒有問題？

各實驗方案的資料指標計算是否都在同一個口徑上？

實驗的方案設計上：

實驗組使用者的選擇上是否足夠隨機？

實驗策略所需要的資料需要齊全？

實驗策略是否對其使用者組完全生效？

拆解分析後發現，我們看到前兩組方案資料指標不好的現狀，並不盡然是全部的真相。首先我們發現，“平均資訊消費時長”的指標設定存在一定問題。因為我們的產品屬性畢竟是工具產品，大部分使用者在連線上WiFi後是用完即走，資訊Feeds註定只是給一部分相對有閒的使用者的功能。

所以，實驗組之間使用者的“平均資訊消費時長”十分離散，方案三中存在個別極端值使用者拉高了整體平均時長資料。為了解決這個問題，我們在計算時可以對極端值做一定處理，並增加“平均資訊點選率”的資料指標，可以更客觀地評估各方案之間的效果。

其次透過分析還發現，方案一和方案二由於資料採集上的原因，並沒有完全實現其策略各自的效果。比如方案一“基於使用者畫像排序”，許多實驗組使用者由於安卓許可權限制，安裝列表資料不全；對部分使用者IP的地理位置識別也不夠精準，測試發現給有的在廣州的使用者推薦了北京的本地新聞，自然也會影響策略的效果。

比如方案二，由於部分“標題黨”內容點選率很高，所以導致實驗組使用者首屏全是“標題黨”內容，內容質量很低，使用者點選後也很快跳出，導致策略的實驗效果很差。

五、資料運營思維的重要性

如果我們沒有對資料指標呈現出來的情況做進一步分析，單看實驗的結果，我們可能直接就會認為對於我們的使用者，“時間排序”就是最好的方案了，以後都應該往這個方向去發展，所謂模型演算法的最佳化也都沒有必要了。但只有透過分析，才能更清晰地看到事實的全貌，不斷提出最佳化方案進行迭代。

這裡體現出的，是問題拆解思維的重要性，是有邏輯的問題分析思維的重要性。希望透過本書，可以跟讀者你分享這些思維框架，成為一個更優秀的運營。

寫在後面

後續在平臺上會分享更多資料運營、網際網路產品（或夾帶一些個人的藝術愛好私貨）的文章，歡迎各位交流！

本文由 @黃一元 原創釋出於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。