本文筆者對推薦產品經理的工作流程進行了梳理，主要是對客戶的業務邏輯、數據積累和項目預期進行思考，希望希望通過此文能夠加深你對推薦產品經理的認識。
為什麼寫這個主題？
一是目前大家在網絡上能找到的絕大部分關於推薦產品的材料，大家抄來抄去，講的內容大差不差，到了實際工作中，會發現，這些抄來抄去的知識內容，只佔工作中很小一部分。
二是筆者最近剛好在做電商推薦的項目，有一些經驗總結。將其整理出來，在梳理自己知識體系的同時，也與大家交流討論。
本文的受眾對象是對推薦產品經理的工作職責有一定了解，具體一點，默認你已經讀過，比如《推薦系統實戰》，或者一些關於推薦算法在實際生產環境中應用的一些文章。再有了這些基礎之後，閱讀我這篇文章，會更有收穫。閱讀篇文章的收穫，取決於你在這個過程中，是否有進行思考，以及與你之前的經驗知識進行結合。
一、業務背景
客戶是一家電商，主營業務是奢侈品售賣。該業務，具有的特徵是高客單價，低消費頻次。客戶希望進行針對性推薦營銷，在進行郵件營銷，或短信營銷的時候，推送給用戶的item，是用戶最有可能購買的。
二、分析思路
面對這樣的需求，沒有經驗的產品經理，可能會說，ok，沒問題，提供給我們數據吧，我們可以為你們提供解決方案。
而一個資深的，或者說有經驗的產品，會遵循如下的思考步驟：
- 客戶的業務邏輯
- 客戶的數據積累
- 客戶的項目預期
1. 客戶的業務邏輯
要做推薦，首先第一步，推薦是給用戶做的推薦，而從推薦到用戶，是需要載體的，這個載體可以分為兩種：電腦，手機。
電腦端的電商推薦，我們可以分為兩種：一種是像京東、蘇寧易購這種大的電商；還有一種是商家自己的網站。
手機端的電商推薦，根據是否是由自己獨立運營，也可以分為兩種：
- 獨立運營：APP、小程序
- 非獨立運營：大型電商，比如淘寶、京東。
我們分別來了解一下web端和手機端的推薦。
（1）💻Web端
大型電商的推薦場景，一般有首頁推薦、單品頁推薦、購物車頁面，不同頁面推薦的商品不同，展示形式不同，推薦的數量也有差異。如下圖：
（圖一 首頁推薦）
（圖二 單品頁推薦）
（圖三 購物車頁面）
從推薦內容的相似度來說，圖二和圖三的相似度更高，但是推薦的商品也並沒有重合，由此可見其邏輯也是不一樣的。從其文案，我們可以進行推斷，單品頁的文案是“人氣單品”，猜測可能是某一類商品中每月/每季度銷量最高的商品；購物車頁面的文案是“購買了該商品的用戶還購買了”，這就是一個電箱u2i的模型，就是user to item；購物車頁面還有一個文案是“您可能還需要”我猜測這個地方的推薦邏輯是i2i，就是item to item。
解釋一下user to item與item to item。
總結一下上述的分析，在京東這個電商網站上，一共有3個推薦場景，每個場景的推薦邏輯都是不一樣的。在瞭解了這種大型第三方電商之後，我們再來看看一些自營的電商。
（圖四 首頁推薦）
（圖五 單品頁推薦）
金奉祥這家珠寶商的網站，我一共看到兩個推薦場景，其實實際上應該也是3個，首頁、單品頁、購物車頁，至於為什麼沒有購物車頁呢？因為我在他們網站上的單品頁沒有找到可以將item加購到購物車的功能，這個設計也是很迷。不過，像這種比較傳統的企業，IT基礎確實比較弱。
（2）📱手機端
在手機端，我們不得不說的是APP，在APP裡面不得不說的是淘寶，淘寶的千人千面總能為我推薦我喜歡的物品，比如我買了一罐蛋白粉，他會為我推薦搖搖杯（喝蛋白粉專用）非常厲害。
接著我們看看小程序，
2. 客戶的項目預期
對客戶的業務有了瞭解之後，我們需要和客戶確認對方的預期。對方希望通過推薦系統，為業務帶來什麼影響。一般來說，採取一個新技術，對業務的影響，產品經理分析思路如下：
- 這個功能是否能夠幫助客戶建立一個新的業務增長點？
- 如果不能，是否能夠幫客戶提升現有業務流程的效率，或降低現有業務的成本？
- 這個解決方案的服務模式和收費模式如何？是基於雲平臺的API調用並按調用次數收費，還是定製化的軟件服務並按軟件授權來收費？等等。
為什麼我說，這個問題是需要產品經理思考的呢？一句話，當我們不知道要談什麼，以及對要談的內容，我們心理是沒有答案的話，那麼，永遠不要上談判桌，因為，這種狀態上談判桌，我們是非常被動的。只有對談判桌上會發生什麼，以及瞭解了客戶關注的利益點，在談判桌上的我們，才能遊刃有餘。
當我們提供給客戶一項新技術，我們能帶給客戶的利益，以及客戶需要付出的代價，就是我們的思考框架。
我們提供的推薦系統，是否能幫助客戶建立一個新的業務增長點？即，是否會給用戶帶來業務的增長，注意哦，這裡說的是業務的增長。這個怎麼理解呢？比如，對於媒體類產品，我們提供推薦系統，可能最大的價值，是延長客戶的用戶在其產品上的停留時長，畢竟現在媒體類產品，爭奪的都是注意力。如果是對電商類產品，那這個業務增長，可以是gmv，也可以是轉化率。
我們提供的推薦系統，能否幫助客戶提升現有業務流程的效率？對這個感興趣的同學，可以看看我之前寫的一篇NLP的文章，在那篇文章裡面，我詳細講述了利用NLP技術，來提升企業運營效率，降低運營成本的一個case。
服務模式和收費模式。為什麼要談收費呢？因為我們提供給客戶的產品，能創造的價值是A，那麼我們對創造的這部分價值，所能收取的費用B，B是小於A的。
梳理清楚客戶的預期目標後，就可以開始和客戶聊數據啦～
3. 客戶的數據積累
在我們本篇的討論中，我們暫時將場景鎖定在web網站。
在數據這裡，涉及到取數。如果客戶的數據基礎好，對一些用戶的關鍵行為節點都有埋點，那麼可以直接從客戶的數據庫裡提取這些字段來使用，但是，如果客戶的數據基礎差，那麼，作為方案解決方，我們需要在客戶的官網上進行埋點，然後再通過API接口的方式，獲取這些數據。
分別介紹一下埋點和API接口的基本概念。
（1）埋點
前端的埋點方式主要有代碼埋點，可視化埋點，無埋點三種：
1）代碼埋點
代碼埋點主要是由研發工程師手工在程序中寫代碼實現，通過觸發某個動作後程序自動發送數據。
優點：很強的靈活性，可以控制發送的時機和發送方式
缺點：人力成本高
2）可視化埋點
可視化埋點以前端可視化的方式來記錄前端設置頁面元素與其操作的關係，然後以後端截屏的範式統計數據
優點：簡單、方便
缺點：上報的行為信息有限
3）無埋點
無埋點綁定頁面的各個空間，當事件觸發時就會調用相關的接口上報數據
優點：無需埋點，方便，快捷，省事
缺點：傳輸數據量比較大，需要消耗一定的數據存儲資源
在記錄埋點信息時候，主要的埋點事件分為點擊事件、曝光事件和頁面停留時長3類
- 點擊事件。用戶每點擊頁面上的一個按鈕就會記錄一次數據，如下午當用戶點擊一次“酒店住宿”按鈕時，便會統計一次點擊事件
- 曝光事件。當用戶成功進入一個頁面時記錄一次數據，當刷新一次頁面時也會記錄一次數據
- 頁面停留時長。頁面停留時長主要用來記錄用戶在一個頁面的停留事件，可以通過記錄用戶進入頁面的事件t1和離開頁面的時間t2，計算公式為t2-t1
（2）API接口
學習了埋點，我們來聊聊API接口，我會先講講什麼是API，接著我會介紹一下如何利用API進行數據傳輸。
埋點和API傳輸，分別對應兩部分，收集數據，傳輸數據。除了這兩部分之外，需要確認的是，需要收集哪些數據，即哪些字段。
以上要素確認完成之後，就可以開始進行埋點了。還有一點需要確認，就是我們需要用來訓練模型的數據數據，需要收集多長時間，客戶的業務是否有時許特徵，比如是否有周期性，如果客戶的業務週期性是以季度為單位，但是我們收集的數據，總週期只有2個月，那麼可能這個就是會對後期的數據有影響的。
如果說在聊數據的這個階段，發現可能數據質量會影響項目，那麼需要儘早和客戶溝通。這裡想多說一點，因為我是做乙方的，每時每刻，讓客戶感受到筆者的專業是第一準則。因此，在同客戶取數的時候，我們最好：
- 將對於推薦系統來說，什麼是高質量的數據，先告訴客戶，
- 並且提前發給客戶數據確認文檔
這樣既可以節省時間，也可以讓客戶感受到我們的專業。
對於推薦系統來說，時序行為相關的字段是高質量數據中不可或缺的部分。數據確認文檔的格式可以從兩個維度展開：數據量，時間維度。即一共提供了多少數據，每個字段的分別業務含義是什麼，以及數據的時間週期。
總結
一般來說，做完上述3個步驟，就是為這樣一個推薦項目，開了個好頭～
PS：筆者是乙方，所以是從乙方的角度來講述推薦產品經理的工作流程，但是本質與甲方推薦產品經理的工作一致。
#參考資料#
《數據產品經理修煉手冊》
本文由 @一顆西蘭花 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
