糗事百科李威： 如何基於數據構建推薦系統，助力精細化運營？
（全文累計 7000 余字，建議先收藏，或移步文末直接觀看演講視頻）
大家好，我是李威，來自糗事百科。
今天主要跟大家分享：在糗事百科我們構建推薦系統的事情。因為是增長大會數據專場，所以我不會介紹推薦系統演算法細節，而是講在構建推薦系統過程中我自己的一些思考，以及碰到的一些數據問題。
我在糗事百科主要負責數據、推薦系統，或者說跟數據打交道的一些工作。我本身是演算法工程師出身，但由於接觸的產品策略非常多，需要了解更多產品相關的知識，慢慢就變成了一個產品人。簡單來說，不懂演算法的「開發」不是好「產品」。
糗事百科創始於 2005 年，是國內首個專註搞笑內容的社區。現在我們主要以視頻內容為主，所以大家可以把我們理解成一個短視頻社區。這個產品的時間線很長，所以涵蓋的產品線也很廣，包括 App、網頁端、小程序、公眾號以及微博、新媒體等。
我今天主要講的是 App 本身，先給大家建立概念，這就是一個視頻社區，一部分用戶在發視頻，一部分用戶在看視頻。
以下是我今天的分享，enjoy！
1.認識推薦系統
1.1 推薦系統的定義
我先簡單介紹一下，推薦系統就是說，某個用戶在應用內產生了足夠多的用戶行為，我們對這些數據進行分析，就能發現到他用戶的一些偏好。
由於我們是內容社區，我們就會根據他的偏好，推薦一些他喜歡的視頻內容。拿電商來舉例，假設一個用戶喜歡入耳式耳塞，而頭戴式的耳塞也包含「耳塞」這個關鍵詞，那電商就會推薦頭戴式耳塞產品，這就是基於內容的推薦。
又比如說，一個用戶喜歡電腦、喜歡攝影，另外一群用戶有同樣愛好，但他們不僅喜歡電腦和攝影，還喜歡遊戲，那我們就猜測，這個用戶可能也會喜歡遊戲，所以我們就給他推薦一些遊戲相關的產品或者內容，這就是推薦系統在做的事情。
1.2 推薦系統的價值
為什麼要做推薦系統？其實是基於這樣的一個假設：如果我們給用戶推薦了他喜歡的內容，那麼他可能就會在我們的平台上看更多的內容，看了更多的內容會怎樣呢？下圖顯示的是用戶在我們平台上每天看的帖子數，以及跟他的留存相關的一些數據。
可以看最底下這條紅線，如果他一周只看 200 個以內帖子，那他次日留存以及之後的留存其實是相對較差的；但如果他一周看 2000 個以上帖子，最上面這條紫線，你會發現他的留存會極高，從坐標軸也可以看出來，已經是 90% 以上的留存狀況了。
我們給用戶推薦了他喜歡的內容，他可能就會在我們平台看更多，就會導致他的留存愈加提升，其實這是一個 Product Market Fit（產品-市場匹配） 的過程。我們提供的內容滿足了用戶的需求和喜好，那我們的產品就給他提供了足夠的價值，做到了 Product Market Fit，這就是做推薦系統的原因所在。
我看過一句話：「一個推薦系統來到這個世界上，它只有一個使命，就是要在用戶和物品之間建立連接，數據的挖掘和分析就是為了更好地識物斷人，從而更高效的完成用戶與物品之間的對接」。
這句話讓我想起 GrowingIO 的創始人 Simon 說什麼是增長，「Growth is connecting the existing core value of a product with more people」，這兩句話講的基本上是同一件事情。
連接（connecting）什麼呢？Existing core value，也就是一個產品提供的價值。對於我們的產品來說，就是短視頻的內容，對於電商產品來說，就是你要購買的商品，這就是產品的核心價值。
總之，當我看到下面這句話時，我突然聯想到，推薦系統所做的，就是增長定義的最核心的事情，所以它是不是可以泛化成一個增長的方法論呢？
2.推薦系統與精細化運營的關係
增長策略的發展階段是這樣的：
最開始，我們沒有特別清晰的增長概念，依靠經驗或對用戶的了解來決策產品要怎麼做。
後來，我們會統計一些宏觀數據，比如 DAU 或者留存。我們發布一個版本，可能知道這個版本數據漲了，但是沒有辦法具體到是哪一個環節、哪一個策略導致了產品的增長。
在現階段，大家開始做精細化數據運營，會針對不同的用戶做分群，然後給出具體的策略。但我覺得這樣可能還是不夠細緻，我們要利用推薦系統這樣的個性化方法，做到讓數據自動決策。
舉一個例子，假設我們現在要做一場運營活動，需要一些 banner 或者是入口，設計師會設計幾套具體的方案和樣式。如果是一位非常懂數據的產品運營，他肯定會同時上線這幾個不同的 banner，然後去做 A/B Test，若發現 A 方案比 B 方案好，就會採用 A 方案。我們公司現階段也是這樣操作的。
但在推薦系統的思路里，每個人千人千面，是十分個性化的。設計師辛辛苦苦做出來 A、B、C 三套方案，其實都是可以用的。雖然 A 方案受絕大多數人喜歡，但這並不代表 B、C 方案是沒有人喜歡的。
如果我們能夠利用推薦系統這樣的一種思想，採集足夠多的用戶行為，對其進行分析，就會發現不同用戶對不同的封面有不同的喜好，那麼 A、B、C 方案就都可以用，只不過針對不同的用戶，我們會採用不同的方案。
運營同學可以通過分析將用戶分群，給他們 A、B、C 三套不同的方案，但實際上用戶的分群遠不止 A、B、C 三組，可能存在千千萬萬個分組。運營同學沒有辦法手動做更細緻的分群，這時候推薦系統就派上用場了。
2.1 推薦系統的適用場景
我們通常會把用戶分成幾個階段，比如說新用戶、老用戶或者是非常資深的用戶，還有一些即將流失的用戶。但實際上，我覺得每一個用戶可能都處在他的整個產品生命周期中獨一無二的階段，簡單的把他們分成四塊是不夠的，我們需要用推薦系統的思想去分析具體的數據。
比如說，我們要做召回策略，每一個用戶可能都有他非常個性的一個召回方案，這就是我認為整個增長接下來會逐漸進入的、更加細緻的一個領域。我們給系統提供數據，系統通過一些策略自動給出決策。後面我來說幾個這種泛化的可能實施的領域和方案，當然只是我的設想，實際上還沒有完全落地。
個性化的活動運營、視覺設計。
左邊這張圖是淘寶的首頁，下面有一些子欄目，比如說聚划算、淘寶直播、官方補貼、每日紅包，配了很多個性化的圖片，但沒有單獨用文字。
比如說，最近我們家小朋友過生日，我看了很多與玩具相關的內容，再打開淘寶的時候，我發現那裡仍然是官方補貼、每日紅包等，但配圖已經變成了與遊戲相關的。因為淘寶本身是做電商的，它的配圖可以直接用商品的圖片。
在做運營的活動封面時，每個用戶可能喜歡不一樣的圖片風格，或冷色調，或鮮艷，或柔和。那麼設計師在出不同設計方案的時候，可能需要給封面增加一些關鍵詞，比如說這個是鮮艷的，那個是冷色調的，諸如此類。隨著多次做活動運營的設計，以及採集了足夠多用戶的數據，你可以知道每一個用戶的顏色偏好。
精細化的用戶運營召回方案。
右圖是手機上的簡訊頁面，每日優鮮經常給我發這種召回簡訊，它的每一句話都不一樣，但實際上並不是個性化的，沒有特別打動我。像這種，同樣可以通過學慣用戶的數據來掌握其語言偏好，給每個用戶發不一樣的召回簡訊。比如對於直男來說，一個軟妹風的話術會更好。
註冊轉化流程的優化。
甚至在極端的註冊轉化流程當中，也可以嘗試利用推薦系統的思想給每個用戶生成不同的註冊轉化流程。
當然這裡面涉及一些問題，轉化適用於全新的用戶，你不太能獲知這些用戶之前的數據。但是如果你公司很大，或者是用戶量非常大，比如說騰訊，你可能會提前知道這個用戶大致的畫像，那註冊轉化流程其實是可以提前設計好的，等用戶來註冊這個新應用的時候，就可以個性化的給他展示這一註冊轉化流程了。
2.2 推薦系統的困境
在不同場景和領域實施推薦系統的時候可能會碰到一些阻礙：
系統本身比較複雜，成本較高，可能造成投入產出不合理。
之前我們把用戶分成新用戶、老用戶、即將流失的用戶，可能以很簡單的工作就可以完成 80%的任務。而如果我們要利用推薦系統，那可能要投入 80% 的精力才能獲得 20% 的提升。
推薦系統畢竟是基於大數據的分析，如果你不具備生產大量數據的條件，就很難做到在不同的運營、產品或者設計領域去泛化推薦系統的能力。
所謂推薦系統，就是利用了機器善於計算的事實。我們人類非常善於聯想、善於洞察事物之間關係的，可以發現一些用戶同時喜歡攝影和遊戲，但如果要真正做到個性化，最終還是要利用機器的計算能力。
以上就是我在做推薦系統的過程中，關於後續增長、發展方向的一點點想法，我們已經處於精細化運營的產品階段，可能需要再往前走一步，讓機器來幫助我們實現自動化運營，做得更加精細。
3.推薦系統的增長實踐
接下來是我在做推薦系統過程中，跟數據有關的一些案例，可能對大家有所幫助。
3.1 數據選取階段
這一階段需要考慮兩點：
1）數據需要更形象
例 1：發現更適合推薦系統的數據
做推薦系統最開始肯定是要分析，要利用哪些數據來發現用戶的偏好，顯然，點贊是一個能夠明確知道用戶偏好的行為，肯定是可以被利用的一個數據。但是否是最好的數據呢？
我們來看下面這兩張圖。左邊這張圖是用戶相應行為的人數，包括視頻觀看、點贊成功、評論成功。我們可以發現，雖然點贊這個事情非常清晰的預示著這個用戶的喜好，但是真正有點贊行為的用戶並沒有那麼多。
哪個數據用戶行為最多呢？明顯是視頻觀看。因為用戶來這裡，就是為了觀看視頻。
右邊這張圖是人均相應行為個數。同樣的，你可以發現，雖然點贊成功這件事情非常明確的標誌著用戶的偏好，但是他的行為量還是相對比較少，真正行為量最多的是視頻觀看行為。
那視頻觀看行為能否預示用戶的偏好呢？其實是可以的。一個用戶去看這個視頻，如果他不喜歡，他肯定只看兩三秒就離開了。如果他把這個視頻看完了，就可以預示他對這個視頻有偏好。
所以我們在做數據分析，或者所有的這些增長之前，要對手頭的數據有一個更形象的認知，從不同的維度，平均數、方差、中位數等把這個數據圖表化，這樣才能選取合適的數據來做我們希望的分析。
例 2：內容曝光量分析
另外一個例子是視頻曝光的數據。當這個視頻出現在用戶的屏幕上，就算一次曝光。下圖代表視頻曝光的平均數、中位數、以及最上面的 75 分位。我們可以發現一個問題，中位數是遠遠低於平均數的，平均數甚至接近 75 分位。
通過這個數據，我們能感知到一個什麼問題呢？這個平均數其實是被一群極為活躍的用戶硬生生提高了的。不管我們推薦什麼樣的內容，這批用戶都會去看。假設我們要衡量這個推薦系統的效果，那肯定會去選擇中位數，而不是平均數，因為中位數會更敏感。
這就是為什麼我們要做 EDA（Exploratory Data Analysis，探索性數據分析） 這件事情，即在真正開始處理數據之前，對這個數據有一個形象的理解，感性的認知。
2）產品特性是否對數據友好？
這裡拿抖音舉例，抖音的推薦系統做得非常好，仔細分析它的產品，它的產品特性對數據是非常友好的。
第一，產品特性決定了數據採集的難易程度。
比如說抖音，這個產品剛出來很長一段時間裡，它是沒有暫停的。你看這個視頻要麼看完，要麼就跳過，但是你不能暫停，也不能拖動進度條。
為什麼說這對推薦系統非常友好呢？因為一個用戶看視頻的時長代表著他對這個視頻的偏好。一旦你可以暫停，又可以拖動進度條，那我就很難區分你到底是在看視頻，還是處於暫停狀態，或者你只是在拖動進度條。
而抖音把這件事情做得非常簡單。如果你停留在這個頁面上，那你一定是在看這個視頻。所以，這個產品特性對數據的採集是非常友好的。
第二，產品特性決定了數據的可信賴程度。
右圖是我們自己的產品，是信息流的狀態，在滑動的過程當中會出現多個視頻。而抖音是沉浸式的，一個視頻會佔滿一整個屏幕。
抖音沉浸式體驗的好處就是，你在當下這個屏幕上產生的所有數據全部是針對同一個視頻的，這個數據是極為可信的。並且，抖音還不能自動播放下一條，只要保證你不手動滑，它就會一直維持在這個頁面上。
而在我們自己的產品中，有時候你可能無法分辨，用戶行為到底是針對上面這個視頻，還是針對下面這個視頻的。
第三，產品特性可能決定數據分析和使用的難易程度。
你的視頻時長 15 秒，或者 1 分鐘，或者 5 分鐘，用戶的觀看行為所產生的後果是完全不一樣的。
15 秒的視頻，用戶很容易就看完。如果是 1 分鐘的話，他完全看完的可能性就會極大的降低。如果是 3 分鐘，基本上就沒有用戶可以真正把這個視頻完全看完。
如果你直接拿用戶觀看時長或者比例來評判用戶的偏好的話，就會產品很大的偏差。短的視頻非常容易看完，完播率很高，長的視頻完播率很低。意味著用戶就不喜歡長的視頻嗎？
抖音在產品很長的一段時間內，會把視頻時長限制到15秒，這樣 15 秒以下的視頻，基本上就不存在剛才說的長短視頻完播率不可比的情況，需要考慮的問題就簡單許多。
如果你這個產品設計得對數據非常友好的話，產品特性對真正分析數據、後續使用數據是有極大的促進作用的。
總之，在數據採集之前，你對這個數據要有一個全面的 EDA 的掌控。同時從產品層面上講，產品特性需要對這個數據友好。
3.2 數據採集階段
對於我來說，這是最為困難的階段，非常容易出錯。一旦出錯，你的產品、運營，甚至你的老闆都會對這個數據不再信任，那整個增長就無從談起了。
所以，數據採集階段就是整個數據增長的基石。首先你要建立一個非常良好的數據採集機制，保證這個數據是準確無誤的，最終你才能產生正確的結論，讓大家相信數據，能夠利用數據做最終的決策。
這裡舉一個我們自己在數據採集中出現的錯誤，一個非常極端的例子。這個圖是用戶觀看單個視頻的平均時長。我們把用戶隨機分成了 16 個組，所以有這麼多曲線。
按理說，這 16 個組的曲線趨勢應該完全一致。但剛開始採集這個數據的時候，我們總會發現，有些組會突然產生尖峰，組與組之間曲線行為不一致，對後續的 A/B Test 等會產生嚴重的干擾。
按理說，平均數很難受到臟數據的影響，但是這次我們發現的臟數據比較極端。比如，我們的視頻一般都是 5 分鐘（300 秒）以內，但是有些用戶上報的觀看單個視頻時長達到了幾萬，或者是幾十萬秒這樣的極端情況。雖然概率非常低，但是它就是極端的影響了我們的平均數。
我們後來發現，原因可能是，用戶有時候看著看著就退出了，直接把 App 隱藏在了後台，而內部的計時器沒有停止計時，會延續到這個用戶再次打開 App 時才結束。如果用戶幾天之後再打開 App，他觀看視頻的時長就會變得極長，以此類推。最終我們把這個問題修復了，大家就可以看到用戶觀看視頻的平均時長，16 個組的曲線就都一致了。
所以說，大家在做數據採集的時候，一定要找到一個非常合理的產品研發流程，一定要建立好數據信心，一旦你在產品或運營那裡喪失了對數據的信心，數據增長這件事情就無從談起了。
3.3 數據使用階段
數據很多時候是自帶欺騙性的，我們使用數據的時候要注意以下 2 點：
1）數據是否表意明晰？
用戶數據進入推薦系統後，本質上形成了一個非常大的矩陣，縱坐標是用戶 A、B、C、D、E，橫坐標是視頻 1、2、3、4、5、6、7、8、9，對應的值為某個用戶觀看某個視頻時長的比例。這是一個極大的稀疏矩陣，觀看比例絕大多數都是 0。0 代表他沒看過這個視頻，因為用戶能夠看到的視頻相比我們視頻庫里的內容量是很小的。
如圖，用戶 A 觀看視頻 1，100% 表示看完了；用戶 B 看視頻 1，看了 80.1%。
數據處理階段，我們會把數據做截斷，只保留 3 位小數。那麼問題來了，例如圖上標紅的地方，用戶 C 看視頻 5 只看了 0.001，那我們理解為他可能不喜歡這個視頻；而對於視頻 9，真實情況他只看了 0.003，由於我們在做數據處理的時候會保留 3 位小數，這裡就變成了 0。
根據 0 在這個矩陣中的含義來看，這個數據表達的意義是不準確的，從他不喜歡這個視頻變成了他沒看過這個視頻。所以說，數據本身自帶欺騙性，如果你做了這樣的處理，那它就表達了錯誤的意思。
2）數據是否自帶傾向？
我們做推薦系統，該怎麼衡量用戶喜好呢？
假設用戶看一個視頻的時長為 50 秒，看另外一個視頻的時長為 30 秒，那我們會天然地覺得他更喜歡前者。同樣的，如果一個視頻他看了 100%，另外一個視頻看了 50%，那我們也會認為他更喜歡前者。所以，視頻觀看比例和視頻觀看時長這 2 個指標都可以作為衡量用戶偏好的標準。
看上面兩個圖表，橫坐標都是視頻時長（0~300 秒），左圖是用戶平均視頻觀看比例，右圖是用戶平均視頻觀看時長。
舉個例子，如果一個視頻大概是 50 秒，那麼平均觀看比例大概是 60%；如果一個視頻大概是 300 秒，那麼它平均觀看比例就只有 30%；但是 50 秒的視頻平均觀看時長是 30 秒， 300 秒的視頻平均觀看時長可能就是 100 秒左右。
那麼，如果你用平均觀看比例來衡量用戶偏好，50 秒的視頻有先天優勢；如果拿觀看時長來衡量用戶偏好，那麼 300 秒的視頻就天然有優勢。
根據這個例子可以看出這兩個指標各自帶有傾向，如果拿用戶觀看比例來衡量用戶偏好，則傾向於推薦短視頻；如果拿用戶視頻觀看時長來衡量用戶偏好，則傾向於推薦長視頻。
再聯想到，抖音把視頻時長限制在了 15 秒，這就把大家都拉到了同一條起跑線上，無論是用比例還是用時長衡量，結論都是一樣的。如果你的視頻時長分布非常廣，比如從 0 秒 到 300 秒，那就很難決策，到底要拿哪一個指標來衡量用戶的偏好，因為任意一個指標都有自己的傾向性。
3.4 數據分析階段
在數據分析階段，我推薦用 A/B Test 來做評估效果。
1）正確認知 A/B Test
實驗即需求本身；需求文檔就應該是一份實驗方案。
很多同學會覺得做 A/B Test 是一件耗時耗力的事情，但換一個角度想，你在寫產品需求文檔的時候，寫的實質上是一個實驗方案，實驗和需求本身是無法剝離開來的。
實驗結果往往需要關注多個指標。
真正做 A/B Test 的時候，我們需要關注很多的指標，一些指標增長的同時，另外一些指標可能會下降。
實驗需要足夠的樣本，關注實驗的統計顯著性。
A/B Test 的樣本量如果不夠，可能得出的效果就不那麼真實了。
實驗時長有限，往往反映短期效果，具有短視性。
做實驗的時間是有限的，你不可能永遠都在做這個實驗，這就天然的導致了 A/B Test 往往反映的是一個短期效果。比如說剛才那個實驗，只做一天，數據增長了，但在長期來看，它可能會慢慢趨於與其他組同樣的效果。
2）A/B Test 實例
下圖是我們推薦系統剛上線時候的一個例子，數據是用戶平均觀看時長。藍色的 0 組是測試組，剛上線時效果要比其他組好很多。但是在第二天、第三天，我們就發現效果在減退，是什麼原因導致的呢？
我們的第一反應很簡單，再上線兩個組，看是不是會產生同樣的效果，於是就上線了 12 組和 10 組。在上線前兩天，它們和 0 組一樣，數據增長的效果很好，但是到了第三天，效果同樣在減退。
由於對自身的推薦系統有足夠了解，我們推測，用戶消耗完了他們偏好的數據，而我們沒有補充上足夠多的這類數據，就導致效果減退。於是我們做了第三個測試，增大了資料庫里數據的量，給用戶推薦更多他偏好的內容，數據就增長了，而一旦消耗完，則又減退。
通過這樣的手段，我們把數據增減的原因分析得很透徹。大家要學會利用好 A/B Test ，同時配合對這個業務的理解，才能做好數據分析。
3）數據分析能力與業務理解能力的關係
最後需要強調的是，數據分析能力是建立在對業務的理解基礎之上的，兩者息息相關、齊頭並進。正如我剛剛說的 A/B Test，如果你對推薦系統本身不夠了解，就很難分析出來數據減退的原因是用戶偏好的數據量不夠。
大家一定要同時增長自己的業務理解能力和數據能力，才能最終做到數據驅動。
以上是我這次分享的主要內容，希望能夠幫助到大家，謝謝！
