過去的一年，一直在做策略相關的產品，很有意思的是，從0到1做的東西佔了絕大部分工作成果。文章預計拆分爲2~3篇，今天是第1篇，聊一下搭建策略產品的必要性以及應具備的條件。

一、搭建推薦策略的必要性

在做一件事情之前先要問問爲什麼要做這個事情，這樣才能在整個實施的過程中遊刃有餘，有的放矢。

不過，回答這個問題之前需要對推薦系統有個總體的認知。

1. 關於推薦系統

先大概回顧一下整個互聯網階段對信息處理的演變過程。隨着信息技術和互聯網的發展，一方面用戶足不出戶就可以得到的大多數的信息，但是另一方面卻逐漸受到很多無關信息的打擾，也就是信息過載。

爲了解決信息過載的問題，整個信息處理的過程大概經過了三次演變：

第一次即以門戶網站爲代表的分類處理技術。通過對互聯網的信息，內容進行分類處理，並且在用戶端進行不同入口的展示，極大的方便了用戶根據類別來篩選自己感興趣的內容，極具代表性的就是各種門戶網站。但是隨着內容越來越多，分類也越來越多，太多的分類對用戶來說也造成了信息過載，隨着出現了第二次演變。

二次演變即以PC互聯網時代google，百度爲代表的搜索引擎。用戶可以根據自己明確的目標需求進行關鍵詞查找，繁重的目標內容檢索工作交給了機器去處理，極大的提升了用戶信息查看的效率。不難發現，搜索其實是解決了用戶在有明確目標的情況下信息檢索需求。但是如果用戶沒有明確的目標呢，這時候搜索引擎也無能爲力。緊接着，第三次演變到來。

第三次演變即以移動互聯網時代的個性化推薦，也即千人千面，每個人看到的都是單獨爲其量身打造的內容。和搜索引擎不一樣的是，即使用戶不主動提供明確的需求，只要它在互聯網上發生過相關的行爲，那麼推薦就可以給到用戶最爲感興趣的內容。

簡單來說，根據用戶的歷史行爲進行用戶興趣建模，結合內容的特徵，給到用戶最能滿足其興趣和需求的內容，即推薦。

而推薦策略解決的問題就是如何能夠推薦出讓用戶滿意，讓業務受益的內容。

當然，這裏的內容（一般稱之爲item）不限其具體的形態，可以是商品，可以是文章，可以是服務等等。

2. 什麼業務適合做推薦策略

瞭解推薦的概念之後，到底哪些業務，哪些場景非常適合去做推薦系統，或者說應該去做推薦策略呢？

這個也是我一直思考的問題，總結了以下幾點：

（1）有海量的內容

推薦系統的初衷就是從海量的item當中選出用戶最感興趣的，所以首先要有海量的item，數量不足，就無所謂選擇了。

另一方面，從策略的角度來講，一個策略從誕生，到上線，再到驗證，整個過程都需要海量的數據參與，比如：item feature提取，模型訓練，指標驗證等等，海量的數據能夠確保整個過程的準確性、可行性和科學性。

（2）有海量的用戶

這個其實和海量的內容是相輔相成的。因爲推薦策略本身就是來鏈接用戶和內容的，所以從這個角度來講的話，有海量內容，就需要有海量的用戶與之對應，否則策略是不靠譜的。

從另一個角度來講，推薦策略本身是爲了提高流量的利用效率，這種利用效率可以體現爲轉化率，UV價值，RPM，GMV等具體指標，需要大量的數據進行驗證，否則就沒有意義。

因此，如果業務還在發展初期，並沒有多少用戶，那從產品目標本身角度來講，這個時候應該主要是以流量導向，而推薦策略並不佔據很重要的優先級。

（3）非工具類業務

工具類業務從其誕生一定會有一個明確的目標，對應的用戶也有非常明確的需求，所以對於這種業務一般不會去推薦其他同類內容了，當然需要區別一下資源位和推薦。

一般來說，目前應用推薦策略比較多的領域包括：電商、視頻、音樂、閱讀、社區、社交、廣告、基於位置的服務等。

（4）用戶逛的場景居多

目前用戶碎片化的時間越來越多，用來在產品上“閒逛”的時間也就越多，但是，與之對應的是同質化的產品也越來越多，在爭取用戶注意力這條道路上，能夠基於用戶的而歷史行爲，去實時，精準的推薦用戶感興趣的內容可能是一種最爲高效的方式。

個性化推薦目前已經成爲了一種新的趨勢，每一個產品基本必備一個BI模塊。不過，是否值得投入很大的資源去做一個看似高大上的推薦系統，還是需要好好考慮一下的。

二、搭建策略產品需要哪些條件

下面有些內容在之前的文章裏面提到過：這一年，我做策略產品遇到的坑，在一個業務線搭建推薦策略產品時，需要先看看如下條件是否滿足：

1. 結構化數據是否必備

現在產品人經常講的數據驅動，我覺得更全面的說是結構化數據驅動。因爲處理亂七八糟的數據是一種很糟（dan）糕（teng）的經歷。

關於結構化數據的定義可以看之前的文章。對於搭建策略產品而言，主要看三個：

（1）產品埋點是否完備

埋點是唯一能夠準確，實時的採集到線上用戶行爲的手段，而對於鏈接用戶和物品信息的推薦產品來說，用戶行爲的重要性就不言而喻了。

（2）埋點數據是否存儲

對於數據來說，埋點僅僅解決了線上是否有采集工具的問題，至於是否能夠真正發揮其數據價值還需要看這些數據是否被存儲下來。

就類似城市攝像頭，如果僅僅佈置了一個可以實時顯示當前區域內景象的工具，其實對於城市建設沒有任何用處。

在我們之前的一次實施的過程中就遇到過類似的問題。uuid（用戶設備編號）本身各種日誌是有記錄的，但是數據表中卻沒有把這個字段存下來，導致無法直接使用，如果進行表結構改動，做研發的同學應該知道，這個工程量和複雜量絕對不小。

（3）數據存儲結構是否合理

最後一個就是關於存儲結構的問題，主要是指數據表結構設計的是否合理。

我見過很多業務線的後臺數據的表結構就是按需建表，沒有一個統一的規劃，就類似一個大的房子，沒有提前做統一規劃，而是按照各自需要進行分割，結果可想而知。

最主要的額影響就是在搭建系統過程中，表結構需要不停的進行整合，重建，本來三天可以進行入方案開發，會延期一週甚至更長時間用來處理這些問題。

一個不合理的數據庫設計，會導致工程效率低下。

這些都是我親身經歷過的事情。可以說以上三點，直接決定了一個業務線是否能夠搭建推薦策略產品。

還是那句話：底層數據各種屬性不全，最好的規則也白搭。

引以爲戒。

總之，結構化的數據對於推薦策略產品的搭建主要有兩個作用：

• 一是用於用戶行爲feature的建立用於推薦結果的召回，比如：點擊行爲、關注行爲、加購行爲、下單行爲等；
• 另一方面是用於對推薦效果的驗證，主要是通過線上埋點採集數據，進行計算相關指標進行推薦效果檢驗。

另外再說一下我關於數據驅動的理解：目前的數據驅動其實大多數停留在數據佐證，人驅動上面，換句話說大多數情況下把數據當做一種工具，用來證實或證僞，然後人再去做相應的決策。

我理解真正的數據驅動應該在用戶進來的那一刻開始，數據工程就開始運作，來決定給用戶展示什麼，怎麼展示，怎麼引導。

2. 是否有較好的應用場景

前面也提到了，不是所有的業務都適合做推薦策略產品，其實最主要是要看這個業務線當中是否有比較好的應用場景進行支持。

通常來說，我覺得有兩種場景是可以用推薦系統進行滿足的：

第一種：更加高效滿足用戶需求。

比如同樣對於筆記本這種產品，當我們還無法感知用戶對品牌，配置需求的時候，可以按照商品本身各維度進行推薦（物品單邊特徵），爭取把性價比最高，品質最好的產品推薦給用戶，逐步引導用戶產生消費行爲。

這種場景通常可以稱作是“千人一面”的場景，就是把業務內最“好”的東西展示給用戶，這個“好”的定義隨業務線的不同而不同。

另一種：滿足用戶的個性化需求。

當我們掌握大量了用戶行爲數據的時候，就可以大概知道一個用戶是什麼樣的，比如他喜歡的品類，能夠承受的價格等等，從而去建立他的標籤模型，依據該模型即可進行個性化推薦了。

這種場景通常可以成爲“千人千面”場景，典型的淘寶首頁就是按照這種場景進行搭建，所以，現在一般不叫淘寶購物，而叫“逛”淘寶，這種“逛”的背後就是數據決策的驅動。

其實不難發現，對於不明確用戶目標的情況下，推薦有助於高效，精準的給到用戶最滿意的物品，是這種場景下的不二之選。

以上。

這篇主要講了關於搭建推薦策略的必要性以及需要具備的相關條件，下一篇會具體覆盤一下整個搭建過程的步驟。

作者：夏唬人，公衆號：夏唬人，某廠策略產品經理

本文由 @夏唬人 原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議