大家好，我是李威，來自糗事百科。

今天主要跟大家分享：在糗事百科我們構建推薦系統的事情。因為是增長大會資料專場，所以我不會介紹推薦系統演算法細節，而是講在構建推薦系統過程中我自己的一些思考，以及碰到的一些資料問題。

我在糗事百科主要負責資料、推薦系統，或者說跟資料打交道的一些工作。我本身是演算法工程師出身，但由於接觸的產品策略非常多，需要了解更多產品相關的知識，慢慢就變成了一個產品人。簡單來說，不懂演算法的“開發”不是好“產品”。

糗事百科創始於 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，如果你對推薦系統本身不夠了解，就很難分析出來資料減退的原因是使用者偏好的資料量不夠。

大家一定要同時增長自己的業務理解能力和資料能力，才能最終做到資料驅動。