過去的一年,一直在做策略相關的産品,很有意思的是,從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 協議
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!