# Use Case - From rule based recommendation to AI recommendation

- ### 組別
- DataTeam從刪庫到跑路，ML Infra 從建構到爆破。
- ### 產業別
- 電商產品廣告平台
- ### 商業模式
- 摘要:幫客戶的產品在網路上進行廣告投放與推薦，並將流量導向客戶的電商網站，以點擊(CPC)計價收費。
- 我們是一個內容廣告平台，目前專注在商品內容廣告，它通常在網站上的頁面底部放置廣告。這種平台的商業模式通常是基於「交換」的，也就是廣告主和網站發佈商在這個平台上互相合作。
廣告主通常會在平台上創建廣告計劃，並設定要展示廣告的內容。然後，廣告主會支付給平台一定的廣告費用。內容發佈商則會在我們平台上登記並獲得一定的收益，因為它們在其網站上放置了我們的廣告。
平台會通過使用機器學習技術來確保廣告在適當的時間，地點和給適當的人顯示。這種模式有助於廣告主達到高轉化率和有助於內容發佈商獲得額外的收益。
- ### 簡易組織架構(包含公司規模、重要的部門)
- 公司規模：170人
- R&D:
- FE engineer: 15人 （負責前端user event埋點串接）
- BE engineer: 15人（負責後端服務與管線建置開發）
- Data engineer: 20人（負責data pipeline相關基礎設施建置與開發）
- Algo/ML engineer: 20人（負責推薦演算法與機器學習模型之開發）
- IT engineer: 20人（負責底層雲基礎設施建置與維護）
- 非R&D:
- Product manager: 10人
- Sales: 20人
- Marketing: 10人
- Labeling: 20人
- Others: 20人
- ### product team 人數以及組成
- 新成立來專門做CBR(content-based recommendation)
- Data engineer x2
- Database
- Data pipeline
- Crawler->Data Lake/WareHouse
- Article->Labelizer->Labelized Data->Data Lake/WareHouse
- Algo/ML engineer x3
- Research
- Algo Infrastructure
- Train/Retrain/Experiment/Evaluate pipeline
- Serving
- BE engineer x2
- API develop
- Crawler develop
- PM/PO x1
- Label部分開ticket交由公司內Label team進行
- 埋點部分開ticket給其他部門
## Use case 中的需求情境
- ### 需求單位
- COO 想要一個基於AI的廣告商品推薦方案(user/content based recommendation)
- ### 對接單位
- 原本公司就有的廣告後台與推薦系統
- ### 提出需求的原因/目的/想達成的效果
- 原因：目前公司使用的rule-based推薦系統效果不佳，使用者歷程相關資料正在進行串接中，AI浪潮正盛，因此COO希望通過以AI為基礎的推薦系統，觀察使用者正在觀看的網頁內容(Content)，挖掘潛使用者的潛在興趣產品。
- 目的：希望能升級推薦系統，使用演算法參考網頁資訊進行推薦。
- 想達成的效果：提升公司廣告平台產品的推薦的點擊率與轉化率。
- ### 需求單位期待的交付物，或需求單位期待如何使用這個服務/產品
- #### 需求單位期待的交付物
- 一套content based的推薦系統，至少含有下述功能，並具有擴增Feature的能力。
- Machine Learning Training Flow
- Machine Learning Serving Flow
- Data(content) Ingestion/Transformation Flow
- Monitoring Dashboard
- #### 需求單位期待如何使用這個服務/產品
- 希望後端能無痛從rule-based服務方案切換至content-based的服務方案，獲得更準確的產品推薦結果。

- ### 需求單位期待的 SLA（Service level agreement）
- Conversion rate(CVR) or CPC lifts 5%
- 99% service up time
- maximum 200 ms response time increase
- ### 這需求對於企業/組織的價值
- 推薦使用者更感興趣的產品，能增加CVR&CPC，提升廣告主滿意度與企業獲利

## 來源資料與細節
- ### 資料來源
- 前端追蹤: page_views, clicks, display_events
- 爬蟲: document_meta, document_topics
- 廣告後台: promoted_content

- ### 資料格式
- page_views 瀏覽資料 -- 使用者看了那些文章和背景屬性
- user_id, document_id, timestamp, platform, geo_location, traffic_source
- display_events 廣告曝光 -- 有關廣告曝光的資訊
- display_id, user_id, document_id, timestamp, platform, geo_location
- clicks 點擊資料 -- 使用者在廣告列表裡點了哪篇文章
- display_id, ad_id, is_clicked
- promoted_content 廣告內容
- ad_id, document_id, campaign_id, advertiser_id
- document_meta 文章的內容資訊 -- 例如文章內的物體名稱，類別，主題，發行商
- document_id, source_domain_id, publisher_id, publish_time
- document_topics 文章主題
- document_id, top_id, confidence_level
- ### 資料量
- 每兩週

| Table Name | Data Size | Data Quantity |
| -------- | -------- | -------- |
| page_views | 10GB | 200 million rows|
| display_events | 300MB | 2 million rows|
| clicks | 200MB | 8 million rows|
| promoted_content | 5MB | 6 thouthand rows|
| documents_meta| 10MB | 300 thouthand rows|
| documents_topics | 50MB | 1 million rows|

- ### 資料速度（多久會增加多少資料）
- page_views: 14M/day (EPS:162/s)
- display_events: 140K/day
- clicks: 570K/day
- promoted_content: 400/day
- documents_meta: 20K/day
- documents_topics: 70K/day

- ### 範例資料
- 範例描述: 在某情境下推給某使用者的內容推薦，每個內容推薦列表可能會被使用者點擊一個或多個的推薦。使用者(user_id)瀏覽網頁(document_id), 網頁有內容文章例如新聞。推薦曝光(display_id)發生在當使用者瀏覽網頁時被推薦多個廣告(ad_id)，每個廣告屬於一檔由廣告主(advertiser_id)所舉辦的廣告活動(campaign_id)。
- Data Table Relation 
- page_views 
- display_events 
- clicks 
- promoted_content 
- document_meta 
- documnet_topics 

- 請選擇公司的 IT 基礎建設，選項如下，每個選項至多兩組，請至 Google 表單填寫，先選先贏：
- Others(Public + Private hybrid cloud)

- Reference
- [outbrain-click-prediction](https://www.kaggle.com/competitions/outbrain-click-prediction)
- [how-feature-engineering-can-help-you-do-well-in-a-kaggle-competition-part-i](https://medium.com/unstructured/how-feature-engineering-can-help-you-do-well-in-a-kaggle-competition-part-i-9cc9a883514d)

## POC MVP timeline

[reference](https://hackmd.io/Ldvv5tp2TQqLHaDVwNi_iQ)