# Week 3 電商資料應用 use cases

###### tags: `week3`
###### tags: `課前準備`

TODO: 從此區塊整理過來。以敘述方式描述情境與需求
https://www.notion.so/achq/Cohort-weekly-rundown-867feb0d24c94161a6de311b723a7690#e932a197efa2485fb0a6ca42e1df0b77

## 1. ML system data-related infrastructure
**對口團隊: ML Team**

### 主要目標

支援推薦系統、search result ranking 等 Machine Learning 系統的 infrastructure

* Raw data 準備與 infra for Spark-based ML feature preparation
* A/B testing 成效驗證系統與 dashboard

### 情境描述

對電商來說，站內搜尋系統與各種推薦系統是幫助使用者找到喜歡商品關鍵的一塊。建立與優化這些系統需要大量的行為資料，透過這些資訊得以建立 ML-based product features。進而得以訓練 ML models 以及在 serving time 作為 features 做預測。

行為資料如商品的曝光、點擊。以及各式的轉換行爲，如放到 wish-list、放到購物車、購買等。這些行為資訊也往往需要涵蓋到更完整的 context 資訊。例如這個曝光是在某個關鍵字搜尋的畫面，又或是來自相似商品推薦版面。曝光所延伸的點擊與各式轉換行為，也須連結與歸因到這個曝光。藉此獲得非常精細的點擊、轉換等資訊。

推薦模型經常依賴 context, item, user 等三大類資訊。在做個人化前，context 與 item 資訊是必要的。在具備 raw data 後，後續會需要準備 ML-model 在 training 與 serving 階段需要的 features。許多 features 會是上述行為資訊數十天甚至數個月以上資料的 aggregation 結果。ML team 會需要大資料運算的 self-service infrastructure 來有效完成工作。得以建立 multi-stages 的 preprocessing 與 model training jobs。

在 ML 情境，資料的轉換很多時候較難依賴 SQL。Spark 或類似能用 programming language 處理複雜轉換的 infrastructure 是必要的，使得 features 的準備可以高度彈性、容易用軟體工程的方法系統化與管理。資料本身的結構也經常會使用 complex、nested 類型的 data types，例如 map, struct, array 等。

在 ML-base product features 上線後。不同模型之間的 A/B testing 比較，以及對整個產品成效的影響觀察也是相當關鍵的一塊。A/B testing 幾乎會是 user-sticky （randomization unit 為 user）為主，偶爾會有 page view-sticky 的需求。初期階段會是偏向手工撈資料分析，穩定成熟後各項產品皆有固定的 dashboard 來監測成效與比較不同 model 的表現。

### 資料來源

* 格式相對固定的 client-side event logs 或 server-side event logs 作為 fact tables
* 曝光、點擊與許多轉換行爲的 logs
* 後端資料庫的 orders、shops、users、items 等作為 dimension tables

## 2. 產品分析平台
**對口團隊: Product Analyst/Manager/Designer/User Researcher Teams**

### 主要目標

使用者行為分析、產品功能成效驗證

* Infra for SQL, R based analysis
* Highly flexible and structured event tracking system
* A/B testing 成效驗證系統與 dashboard

### 情境描述

在產品開發過程，可以簡單分成「探索需求」、「實踐與驗證假設」、「監測成效」三大階段或區塊。在已上線的產品會大量依賴產品實際上的數據達成上述需求。

從最簡單的監測成效，會需要知道平台轉換率、註冊率、探索深度、互動深度、來訪頻率等。從商業目標，以及使用者問題解決效率、依賴程度觀察較為終端的成效。

為了達成「探索需求」，希望能有廣泛的埋點。每個頁面的 page view 與關鍵轉換行為都有 log 記錄且容易使用 SQL 撈取。Page views 與關鍵行為行為能有 log-level primary key 相互連結，例如此 page view A 來自 page view B ，或使用者在 page view C 把商品 X 放入了購物車。如此有基本粒度與廣度的埋點使得大多數的需求探索能有數據的輔助。

實踐與驗證假設，會有更細緻與彈性的數據需求。每個產品 feature，例如改了一個搜尋頁品類篩選功能，會想觀察篩選功能使用狀況。改了註冊流程會想監測每個註冊階段的放棄率。每個產品 feature 會伴隨着許多的新埋點埋設與驗證、舊埋點優化與埋點數據探索。數據結構希望框架穩定可高度復用，又同時高度彈性，可以容易增加埋點規格，也容易用 SQL 撈到各種埋點，計算任何階段的轉換狀況。關鍵產品 feature，會建立 SQL-based 的 dashboard 來長期觀察。

Dashboards 經常由 PM, PD, PA 與 UR 自行建立，這些成員通常能自己下 SQL 撈資料或建 dashboards。

以 user 為單位的 A/B testing 是必要的。多數中小型的產品 features 的上線皆會伴隨着 A/B testing。每個產品功能的實驗希望觀察的指標也有所差異，像是註冊率、探索深度或是轉換率等。後續能用 R 來分析數據，包含很細緻的視覺化與假設檢定。R 應該要能直接存取 data warehouse 中的資料。

### 資料來源

* 格式相對彈性的 client-side event logs 作為 fact tables
* 後端資料庫的 orders、shops、users、items 等作為 dimension tables

## 3. 行銷 Channel 流量歸因平台
**對口團隊: Marketing Team**

### 主要目標

瞭解各個行銷渠道的表現，藉此做渠道策略調整、管理各渠道資源分配。

* dashboards。能夠從不同維度觀察不同 channel, campaign 的成效
* 有多種 multi-touch attribution 策略可選擇
* 可以彈性調整 channel grouping 邏輯

### 情境描述

行銷團隊掌管著不同行銷渠道（channels），肩負着這些流量帶來的訂單與營收成果。需掌握各個 channel、campaign 以及各種不同的廣告類型帶來的新舊用戶人數、訂單數量與營收。除了用來監控成效，也是操作與調整各個 channel、campaign 接下來經營與操作的重要資訊來源。

Channels 包含 Direct, Facebook/Instagram posts, Facebook/Google/Criteo Ads, Google/Bing/Yahoo Search, Email, Web/App Push notifications 等。會有兩層的 channel grouping。例如 Facebook Ads 下可再細分成新客開發、舊客重新觸及與近期行為 retargeting 等。部分使用 landing page 的 referer URL 判斷（像是 Google search），部分使用 landing page URL 的 UTM 標記判斷（例如 Facebook posts/ads 的區隔）。

Campaigns 有長期的 campaigns 像是固定的 branding 或 retargeting 類型廣告與通知。也有短期跟著行銷與品類團隊一檔一檔的期間優惠手動設置。每個 campaign 背後有著各自的預算以及預期的投報率。Campaign 會由經營團隊在 URLs 中的 UTM 標記中標註，在使用者 landing 時，系統可從 URL 中解析出來。

同一位使用者可能在短期內踩過多個 channel 與 campaigns。期待的歸因區間是 7 天。意思是使用者下訂單後，往回推算七天內使用者踩過的 channels 與 campaigns，把這個訂單的營收歸因分配給這些 channels 與 campaigns。系統至少需支援下列三種歸因邏輯。且都排除 Direct 流量。

1. last click：最後一個點到的 channel 或 campaign credit 全拿
2. first click: 七天內第一個點到的 channel 或 campaign credit 全拿
3. positional: 第一個 landing page 與最後一個 landing page 各拿 40%，中間所有的 channels, campaigns 平均分配 20% credit。

最終建立一個 dashboard。可在 runtime 時讓 dashboard 使用者選擇流量的時間區間，篩選不同的 channels 或 campaigns，以及選擇不同的歸因邏輯。

此 dashboard 的使用者期待是完整設計的一個 dashboard，他們通常不會寫 SQL，也不擅長自行修改 dashboards。由於經常會需要比較不同歸因邏輯的結果，以及即時監控各個 channel 的表現。對 dashboard 的 response time 要求也比較高。當 filter 或歸因邏輯調整時，希望可以在十秒內看到結果。

### 資料來源
* landing page 的 page view logs
* 後端資料庫的 orders table

## 5. 即時訂單與營業額報表

**對口團隊：各品類經營團隊**

### 主要目標

各品類的經營部門希望接近即時的瞭解銷售狀況。

* 即時反應架上商品狀態與銷售狀況的 dashboard，包含商品種類、賣家資訊、訂單數量、營業額等。
* 可自由選擇時間區間，與跨時間區間比較，例如 YoY, MoM, WoW 等資訊。
* 可根據訂單靜態資訊做篩選，如品類、賣家、商品。
* 可根據訂單動態狀態做篩選或統計，例如付款、出貨狀態。

### 情境描述

各個品類的經營部門肩負着該品類的可銷售商品、賣家種類，與銷售成效。品類像是背包、服飾、居家擺飾、美妝保養等。在看這些資訊時，他們希望能有更即時的報告，來讓他們可以更快速的應對狀況。資料的延遲不超過 10 分鐘，此爲此系統的 service-level agreement。

當某個商品或品牌可銷售數量不足時他們可以更快速的反應，調整主推品牌或商品。當改了主推品牌或商品後，或是 landing page 上的行銷文案或優惠後，能更快的看到買家的反應是否如預期。

一個訂單會多維度的狀態，包含下訂、付款、出貨、到貨、完成訂單、退貨。在不同物流、金流也有不同的流程考量，例如一般出貨是先付款後出貨，貨到付款則是反過來。在看終端成效時只考量已完成訂單的訂單，但在即時監控希望能在使用者下訂時就能在報表上顯示。

終端成效更看重 YoY，這通常是團隊的主要 KPI。但即時監控有時會比較 WoW 或 DoD 等更細緻的時間區段比較，更抓準每個調整帶來的短期效果。

此 dashboard 的使用者期待是完整設計的一個 dashboard，他們通常不會寫 SQL，也不擅長自行修改 dashboard。

### 資料來源

* 後端資料庫的 orders 、items、categories、shops 等 tables

## 4. 賣家後台廣告報表
**對口團隊: Seller Success Product Team**

### 主要目標

提供賣家廣告系統同時，也須提供近即時的廣告成效報告。

* 整合在賣家後台，可選擇時間範圍，顯示成效表格，以及各種 metrics 的折線圖
* 簡單的 last click 歸因邏輯，使得訂單可以歸因到三十日內的最後一個廣告點擊
* 報告需能顯示站內各個曝光渠道的表現。至少細分到「搜尋頁的關鍵字」、「分類瀏覽的分類」

### 情境描述

作為一個 B2B2C marketplace，平台上有眾多的賣家在銷售商品。在這樣的競爭關係下，平台可以提供廣告服務，讓賣家可以透過投注廣告費來獲得更大的曝光，平台也可透過這樣的服務獲得額外的收益。在許多類似的平台，廣告服務收益甚至可超過來自商家銷售的抽成。

此廣告平台類似於搜尋廣告，但不需指定關鍵字。許多頁面如搜尋頁、分類瀏覽頁、相似推薦頁，都有廣告專屬區塊。只要你的商品符合該頁面出現的條件，且你有對該商品投放廣告，你的商品就有機會在這些廣告區塊顯示。具體來說，若你的商品是一個後背包，原本在「後背包」搜尋頁排名在第二頁的中下方。投放廣告後，就有機會顯示在「後背包」搜尋頁第一頁的廣告區塊。廣告曝光的機率與排名根據賣家投放廣告的 cost per click 與商品在該頁面的相關度綜合決定。

在報表上，期待可知道指定時間區段的每個商品的廣告成效。具體數據包含廣告曝光次數、點擊次數、購買數、廣告花費、CPS(cost per sale)、ROAS(return on ad spend)。各個 column 為不同的 metrics，各個 rows 為不同的商品。更進一步的，賣家會期待可以知道廣告曝光的細節情境，例如 130 個廣告曝光來自「後背包」搜尋頁，87 個廣告曝光來自商品的相似推薦系統、89 個廣告曝光來自「背包」分類頁。

訂單的歸因取 last click。意味著若此使用者點過同賣家的三個廣告曝光，最後在三十日內買單。此訂單成效歸屬於最後一個廣告曝光。每個賣家的訂單是分開的，一個訂單最多歸屬一個賣家。

由於賣家眾多有數萬個。不同於內部使用的 dashboards，此後台報表需能有非常低的 response time 與相當高的 concurrency。

### 資料來源

* client-side event logs 中的廣告點擊事件
* 後端資料庫的 orders, item_ads, items tables