電商 PM 從零寫出平台推薦系統:資料人才種子計畫心得

我是 Peggy,在電商產業擔任數據部門 PM,主要負責數據產品。為了與技術開發人員有更良好的互動、提升工作效益,我加入「ALPHA Camp 資料人才種子計畫」。課程幫助我建立兼具商業與數據的理解力、弄懂在不同商業場景中如何找到適用的數據模型,讓我能應用在工作上、帶來更好的綜效。

為何加入資料人才種子計畫?

首先簡述一下自己的背景,我目前在電商產業擔任數據部門 PM (產品經理),主要負責數據產品。團隊組成,可以分為 PM, Data Insight, Developers 三個群體,三個群體亦可再細分為數種職位。

數據團隊的組成

各群體之間的分工合作如下圖中的兩大流程:(我主要負責黃底的支線)

數據團隊的分工合作流程

在這樣的團隊組成下,PM 的工作內容大致有以下幾點:

  • 釐清需求並定義商業問題,將商業問題轉化為數據問題
  • 考量使用者場景、技術可行性與調整彈性,提出可能解決方案
  • 管理重要關係人的期待,並建立跨團隊間的信任
  • 促使開發或分析的成果落地實行
  • 規劃後續優化方向與時程

針對上述第 1. 2. 5 點,PM 尤其需同時具有對商業端、數據與算法的理解,方能促成更好的成果。而推薦系統,恰好屬於電商平台中一大重點,但自己卻未曾接觸過的項目。因此,想透過參與「ALPHA Camp 資料人才種子計畫」的課程,來系統性地建構對於推薦系統的理解,並期許自己能應用於日後工作中,與業務及開發團隊溝通推薦系統的建立或調整邏輯,進而達到平台最大效益。

課程如何運作?

技術、實作與真實案例的內容安排

主要分成 3 個部分:

  • 商業場景說明與討論(week 0 ~ week 1)
  • 推薦系統經典模型講解與實刻(week 1~week 3)
  • 產業應用 — iCook(愛料理) 案例(week 4~ week 6)

一開始,ALPHA camp 先給予一個電商案例、其營收成本結構及其營運上碰到的困難,並請學員們針對案例情況來討論。

接著,引導學員思考可以如何設計推薦系統來解決前述案例商業上碰到的問題。在這個階段,學員會需要實刻模型,包含 Rule-based, Content-based, Collaborative Filtering (User-based & Item-based), Matrix Factorization 等。

當學員走完一輪推薦系統的實作,理解每個模型的優劣及適用場景後,最終進到產業應用的案例。根據 iCook 模糊化的實際數據(已簽訂保密協定),學員自由選擇欲構建的推薦算法,並將其實作出來。同時,邀請到技術長兼共同創辦人 Richard 來點評,並分享過去愛料理建立推薦系統的背景及帶來的商業價值、碰到困難的過程及對應的解決方式。

印象深刻的學習體驗

除了傳授技術知識、安排實作練習與提供真實案例應用,幾個良好的學習體驗讓學習成效更好。

助教即時批改作業與給予回饋

助教即時批改作業與給予回饋

學習社群提升學習成效

學員可以隨時在 slack 的學習群組中發問,或自行組建讀書會,利用社群的力量,提升自己的學習效果。

工作坊講師引導學生討論

每週的工作坊,講師會透過 case study 或是開放式問題,來引導學員勇於發言,進而建立討論的氛圍。因學員大多來自不同產業背景,常常可以聽到不同角度的見解,收穫非常多。

Show & Tell 向優秀同學學習

每週,AC 團隊會根據前一週的作業成果,選出 3~5 位學員來分享。學員們能藉此理解多元拆解、分析問題的方法,以及不同的推薦邏輯,進而回頭優化自己的專案內容。

在課程中學到了什麼?

不同商業場景,適用不同推薦模型

不同的商業目標與平台性質,皆會影響推薦系統算法的選擇。例如考量不同的營利模式,用戶、商品數量與形態等。另外,也與以下 2 個關鍵有關:

  • 清楚定義需解決的商業問題。例如:是要提升長尾商品業績?培養高忠誠度客戶?還是提升客單價?
  • 清楚理解自身平台的現況。例如:平台主要是生產內容還是銷售商品?客戶與商品的數量關係及增加頻率為何?

下面以處於不同階段的平台,來說明模型選擇的考量。

平台成立初期

在平台成立初期,因對用戶輪廓較不清晰、或商品數尚不多時,即使只推薦熱銷商品(即 Rule-based),也可能得到不錯的效果。然採取此方法時,仍需考量短尾商品銷量恆大、長尾商品無法被推薦到的問題。這可能導致用戶認為平台商品缺乏多樣性,進而影響對平台的依賴信任程度。

平台較成熟期

當平台的用戶及商品數漸增,欲採取個人化推薦時,可嘗試以下 2 種算法。

Content-based 算法:

推薦與用戶曾購買商品相似的其他商品。但傳統而言,此推薦方式還是存在冷啟動(Cold Start)的問題。若是在平台上未曾有過購買行為的新戶,便無法對其有效推薦。因此有些平台會在用戶初註冊時,詢問用戶有興趣的領域或類別,並依此作為初期推薦基準。

Collaborative Filtering (協同過濾)算法:

可再細分為 Item-based 與 User-based。概念為分析用戶或商品間的相似性,並預測用戶可能感興趣的內容,再將內容推薦給用戶。然此方法同樣有冷啟動的問題,亦存在資料稀疏性(Sparsity)問題。因此通常會搭配矩陣分解(Matrix Factorization)的方式,來提升運算效能,或取得矩陣資料的隱含意義。

協同過濾 Item-based 與 User-based 的比較表

業務目標與資料品質,也影響推薦系統選擇

各部門有不同業務目標,就有不同的考量

範例:要不要在過幾天的大促上最新版本的推薦系統?

  • 開發部門:新推薦模型的成效還不是太好。若現在採用,會造成平台系統不穩定,再等待兩個月,準確度及穩定度皆會改善,可達到較好的效益。
  • 業務部門:這次大促的目標是以往的兩倍,不採用新推薦系統的話,不可能達到!
  • 客服部門:用戶最喜歡的就是在平台上可以輕易找到喜愛的商品,若貿然啟用新推薦系統,可能造成用戶因不喜歡而流失。

資料品質影響推薦系統的效益

同樣以不同階段的平台來說明。

開發期間

實作完數週的推薦系統後,深刻感受到「資料處理好,推薦沒煩惱」的真諦!推薦系統的核心包含召回、過濾、特徵抽取、特徵計算、相似度排序等處理過程,因此若前期做好資料探索(EDA) 、資料清理與資料處理,可以大大地影響推薦系統的準確度與運算效率(不用跑一次推薦系統,就要等一輩子)。

上線之後

推薦系統上線後,即需記錄用戶對應的行為(例如:用戶點擊、購買了哪些被推薦的商品)。因此若推薦系統在尚未完善時就上線,可能導致蒐集的資料品質不佳,如後續欲使用此資料來調整以優化模型,便很難達到良好的成效。

除上述兩點以外,另有一點是在工作坊中聽 Richard 和其他學員分享後,我才被點醒的。針對訓練資料(Training Data)做 EDA 時,應避免一頭栽進解讀資料的世界,拚命往裡頭鑽。要記得提醒自己回頭看看平台的實際情況,了解這些資料是如何形成的。很可能並不是基於用戶本身對商品/內容的興趣,而是平台本身的系統邏輯所致。

例如:在探索愛料理用戶所收藏食譜的資料時,發現大多數食譜創建的時間和其被用戶收藏的時間僅相距短短幾天。回平台上模擬用戶行為瀏覽後,才發現原因是,針對非 VIP 的用戶,平台存在呈現給其近幾天創建之食譜的邏輯。在這樣的情況下,確實越接近用戶搜尋時間創立的食譜,越具有較大的曝光量,被收藏的可能性也越高。

總結

ALPHA Camp 資料人才種子計畫課程,有滿足我最初的目的與期待。身為 PM,確實以結構性的方式更理解了推薦系統,也因此在工作中偶爾能和團隊的 Machine Learning Engineer 與 Data Scientist 交流對推薦系統的想法。PM 向開發人員請教技術,開發人員與 PM 討論商業場景應用,進而在之中達到良好的平衡,這是我認為很棒的團隊文化及氛圍。

此外,在這次初學推薦系統後,也深刻了解到推薦系統真的是門博大精深的學問。過程中雖然無數次在繳交作業截止日的前夕崩潰哀嚎,但最終回過頭看,仍是覺得學到的內容其實很有趣且值得。同時,對於自己能夠實刻推薦系統程式碼,感到非常不可思議,真的是蠻有成就感的一段旅程。

最後,想跟大家分享在這次的課程中,自己特別的感觸:

Data literacy and communication are quite important.

如同前面所提及,以推薦系統而言,不單只是把算法寫出來那麼簡單。能不能真的被應用、實際上能帶來怎麼樣的成效,都需要一定程度地去與非數據背景的同仁溝通,或甚至教育他們資料的解讀與利用。可以想見的是,當溝通越順暢、相關部門同仁對資料的理解越深,在建構推薦系統的路上,就可以走得更加順利。

當然,除了推薦系統以外,還有很多數據產品的發展與落地,都很需要這兩項能力。因此,我也期許未來自己能夠承著在這門課的所學,持續吸收不同面向的資料相關知識,以及培養與不同對象溝通的能力,慢慢成為一位強大的數據產品 PM。

本文轉載自作者部落格