事件命名

行為事件的命名遵循 namespace.action 格式（模組一 事件命名規範）。行為分析場景對命名的額外要求是：同一個 funnel 內的事件要能用 namespace 前綴篩選。

例：註冊流程的事件用共同前綴 signup：

1signup.page.view          使用者看到註冊頁
2signup.form.submit        使用者送出表單
3signup.email.verify       使用者點擊驗證信連結
4signup.complete           註冊完成

用 signup.* 就能篩選出整個註冊流程的事件，不需要事先知道每一步的完整名稱。

屬性設計

每個事件除了名稱，還帶有屬性（properties / parameters）描述事件的 context。屬性分成三層：

通用屬性（每個事件都有）

• timestamp：事件發生的時間（UTC，毫秒精度）
• session_id：當次使用的 session 識別碼
• user_id：使用者識別碼（去識別化後，見 模組七）
• platform：iOS / Android / Web
• app_version：app 版本號

事件類型屬性（同類事件共有）

• 頁面瀏覽事件：page_name、referrer
• 按鈕點擊事件：button_id、button_text
• 搜尋事件：query、result_count

事件專屬屬性（特定事件才有）

• signup.form.submit：form_method（email / Google / Apple）
• purchase.complete：amount、currency、product_id

屬性設計的判斷標準是：這個屬性是否用於回答一個分析問題。「註冊方式的轉換率差異」需要 form_method 屬性；如果沒有這個分析問題，就不需要這個屬性。

Funnel 定義

Funnel 是一連串有順序的事件，代表使用者完成一個目標的步驟。Funnel 定義在事件設計階段完成 — 決定哪些事件構成一個 funnel、順序是什麼、每步之間的最大時間間隔。

定義一個 funnel 需要：

步驟清單：funnel 包含哪些事件，順序是什麼。

時間窗口：步驟之間的最大間隔。使用者在步驟 A 之後 30 天才做步驟 B，是否算在同一個 funnel 內？時間窗口的設定取決於業務場景 — 電商結帳 funnel 通常是 30 分鐘，SaaS onboarding funnel 可能是 7 天。

完成條件：什麼算「完成」funnel。到達最後一步即完成，還是需要特定屬性值（purchase.complete 且 status = success）。

過度收集的成本

行為事件收集的邊界是「能回答已知的分析問題」。收集超出分析需求的事件有三個成本：

儲存成本：每個事件佔一行 JSONL。高頻事件（每次滾動、每次 hover）的資料量遠大於低頻事件（按鈕點擊、頁面瀏覽）。

隱私風險：收集的事件越多，包含可識別個人行為模式的風險越高（模組七 資安與隱私）。

噪音：分析時需要從大量事件中篩選出有意義的模式。事件越多，訊噪比越低。

設計好的行為事件直接成為 Funnel analysis 的輸入 — funnel 的每一步對應一個行為事件。行為事件在四類事件分類中屬於 Event 類，完整的分類定義見模組一 四類事件定義。收集行為事件前必須完成去識別化 — 使用者行為模式本身就是可識別資訊。

基本計算

Funnel 的每一步有兩個數字：進入人數和完成人數。轉換率 = 完成人數 / 進入人數。

以四步註冊 funnel 為例：

整體轉換率 = 310 / 1000 = 31%。但更有價值的資訊在每步的轉換率：步驟 2（填寫表單）流失 38%，步驟 4（email 驗證）流失 46.6%。這兩步是優化的優先目標。

流失原因的區分

Funnel analysis 指出「哪一步流失」，但不直接回答「為什麼流失」。流失原因需要結合其他資料推斷。

設計問題導致的流失

使用者看到表單但沒填寫（步驟 2 流失 38%）。可能原因：表單欄位太多、要求的資訊太敏感（信用卡號在註冊階段）、表單 UI 在特定裝置上有問題。

判斷方式：按平台、裝置、螢幕尺寸細分轉換率。如果 iOS 轉換率 70% 但 Android 只有 45%，可能是 Android 的表單 UI 有問題。

技術問題導致的流失

使用者送出表單但 email 驗證沒完成（步驟 4 流失 46.6%）。可能原因：驗證信被歸到垃圾郵件、驗證連結過期太快、驗證頁面載入失敗。

判斷方式：結合 error 事件。如果步驟 4 有大量 signup.email.verify.failed error，是技術問題；如果沒有 error 但流失高，使用者可能沒收到信或沒看到信。

意圖問題導致的流失

使用者到了註冊頁但根本沒打算註冊 — 只是瀏覽。這類流失不是問題，是正常的使用者行為。

判斷方式：看使用者在流失步驟停留的時間。停留 < 3 秒就離開，可能是誤點或沒有註冊意圖；停留 > 30 秒但沒完成，可能是遇到障礙。

Funnel 的時間窗口

同一個使用者在步驟 A 和步驟 B 之間隔了多久，仍算在同一個 funnel 內？時間窗口的設定影響 funnel 的計算結果。

窗口太短：使用者中途離開稍後回來完成，被計為流失。Funnel 的流失率被高估。

窗口太長：使用者今天瀏覽、一個月後被廣告重新帶回來完成，兩次獨立的意圖被合併成一個 funnel。轉換率被高估。

合理的窗口依業務場景而定：電商結帳 funnel 用 30 分鐘到 1 小時，SaaS onboarding 用 7 天，B2B 銷售漏斗用 30-90 天。

畫面狀態矩陣和 funnel 的關係

畫面狀態矩陣（ux-design 模組一）描述每個畫面的狀態和轉換。Funnel 描述使用者跨畫面的操作路徑。兩者的對應是：funnel 的每一步通常對應一個畫面狀態的進入事件。

狀態矩陣中的退出路徑（back 按鈕、取消操作）就是 funnel 的流失點。狀態矩陣的退出路徑為空 = UX 死胡同，funnel 分析中表現為「使用者進入後既沒完成也沒退出 — session 中斷」。

下一步路由

• 不同使用者群體的行為差異 → Cohort analysis
• 行為事件的設計 → 行為事件設計
• 自架方案做 funnel → 從 collector 資料做基礎 funnel 分析

Cohort 的定義方式

時間 cohort（最常用）

按使用者完成某個動作的時間分群。「1 月份註冊的使用者」「第 12 週 onboarding 完成的使用者」。

時間 cohort 回答的問題：產品的留存率是否隨時間改善？新版本上線後註冊的使用者留存是否比舊版本高？

行為 cohort

按使用者的行為特徵分群。「首次使用就完成購買的使用者」「使用過搜尋功能的使用者」「連續 3 天登入的使用者」。

行為 cohort 回答的問題：哪些行為和留存相關？做了 X 的使用者留存率是否比沒做 X 的高？

屬性 cohort

按使用者的固有屬性分群。「iOS 使用者」「企業方案使用者」「來自特定廣告渠道的使用者」。

屬性 cohort 回答的問題：不同平台/方案/來源的使用者行為是否不同？

留存率矩陣

留存率矩陣是 cohort analysis 最常見的呈現方式。每行代表一個 cohort（例如某月註冊的使用者），每列代表註冊後的第 N 天/週/月，格中的值是該 cohort 在第 N 期仍活躍的比例。

從這張矩陣可以看到：留存率逐月改善（1 月 → 3 月的第 1 週留存從 45% 升到 52%）。如果 2 月有產品改版，這個改善可能和改版相關。

Cohort analysis 的判讀

自然衰減 vs 產品問題

所有產品都有自然衰減 — 使用者隨時間減少是正常的。Cohort analysis 的價值在於區分「正常衰減」和「異常衰減」。

如果所有 cohort 的衰減曲線形狀相似，衰減是產品層面的結構性問題（例如缺少持續使用的理由）。如果某個 cohort 的衰減明顯比其他 cohort 快，需要調查該 cohort 的特殊情況（當時的產品版本、市場環境、使用者來源）。

穩態留存

留存率通常在某個時間點後趨於穩定 — 留下來的使用者不再大量流失。穩態留存的百分比和到達穩態的時間是產品健康度的核心指標。

穩態留存高但到達時間長 = 產品有價值但 onboarding 需要改善。穩態留存低 = 產品的持續使用價值不足。

和 funnel 的關係

Funnel analysis 回答「使用者在哪一步流失」（單次流程），cohort analysis 回答「使用者是否持續回來」（長期行為）。兩者互補：funnel 改善單次流程的轉換率，cohort 追蹤改善是否帶來長期留存的變化。

下一步路由

• 使用者從哪來 → Attribution
• 單次流程的流失分析 → Funnel analysis
• 使用者分群的工程實作 → RFM 分群
• 客戶終身價值 → LTV
• 留存率 → Retention

歸因模型

Last-touch attribution

把轉換功勞全部歸給使用者轉換前最後接觸的渠道。上例中功勞歸「直接輸入網址」。

優點：實作最簡單 — 只需要記錄轉換事件的 referrer 或 UTM 參數。

缺點：忽略了前面渠道的貢獻。Facebook 廣告讓使用者第一次知道產品，但在 last-touch 模型中功勞為零。長期使用 last-touch 會導致行銷預算過度集中在「最後一步」渠道（品牌搜尋、直接訪問），低估「認知階段」渠道（展示廣告、社群媒體）。

First-touch attribution

把轉換功勞全部歸給使用者第一次接觸的渠道。上例中功勞歸 Facebook 廣告。

優點：強調「獲客」渠道的貢獻，適合評估品牌認知和獲客效率。

缺點：忽略了後續渠道的推進作用。使用者第一次看到廣告但沒行動，可能是後續的 Google 搜尋才促成轉換。

Multi-touch attribution

把轉換功勞分配給使用者轉換路徑上的所有渠道。分配方式有多種：

• 線性歸因：每個渠道平均分配。三個渠道各得 33.3%。
• 時間衰減：離轉換越近的渠道得到越多功勞。
• Position-based（U 型）：第一個和最後一個渠道各得 40%，中間渠道分 20%。
• 資料驅動（data-driven）：用機器學習模型從歷史資料學習每個渠道的貢獻。需要大量資料。

技術實作

Attribution 的技術實作需要解決兩個問題：跨 session 的使用者識別，和觸點的記錄。

跨 session 識別

同一個使用者在不同 session、不同裝置、不同瀏覽器上的行為需要關聯到同一個人。

Web 端用 cookie（first-party）或 login ID 關聯。Mobile 端用 device ID 或 login ID。跨裝置關聯需要使用者登入 — 未登入的使用者在不同裝置上是不同的匿名 ID。

觸點記錄

每次使用者接觸產品的渠道需要記錄。Web 端記錄 referrer、UTM 參數（utm_source、utm_medium、utm_campaign）。Mobile 端記錄 deep link 參數、app store 來源（需要 attribution SDK 如 AppsFlyer、Adjust）。

自架方案的歸因能力

自架 collector 能做基礎的 last-touch attribution — 在轉換事件的屬性中記錄 referrer 和 UTM 參數。

Multi-touch attribution 需要跨 session 的使用者行為歷史，實作複雜度顯著上升。如果 multi-touch 是核心需求，商業方案（GA4、Mixpanel、AppsFlyer）通常比自架更實用。

下一步路由

• A/B test 驗證渠道效果 → A/B test 的統計基礎
• 使用者分群 → Cohort analysis
• 行為事件設計 → 行為事件設計
• 客戶取得成本 → CAC

假設檢定

虛無假設和對立假設

虛無假設（H0）：兩組沒有差異，觀察到的差異來自隨機波動。對立假設（H1）：兩組有真實差異。

A/B test 的邏輯是：假設 H0 成立（兩組沒有差異），計算「在 H0 成立的前提下，觀察到目前這麼大的差異的機率」。如果這個機率（p-value）很小（通常 < 0.05），拒絕 H0，接受 H1。

p-value 的意義

p-value = 0.03 代表「假設兩組沒有差異，觀察到目前差異的機率是 3%」。這個機率足夠小，合理推斷差異是真實的。

p-value 不代表「改版比原版好的機率是 97%」。p-value 是在 H0 成立的條件下計算的，不是改版效果的機率。

兩類錯誤

Type I error（偽陽性）：實際上沒有差異，但統計結果判定有差異。機率由顯著性水準 α 控制，通常設 0.05。

Type II error（偽陰性）：實際上有差異，但統計結果判定沒有差異。機率由統計檢定力（power = 1 - β）控制，通常要求 power ≥ 0.8。

樣本量計算

樣本量決定了 A/B test 能偵測到多小的差異。樣本量太小，即使改版有效果，test 也沒有足夠的統計檢定力偵測到。

樣本量計算需要四個參數：

• 基準轉換率：control 組目前的轉換率（例如 5%）
• 最小可偵測效果（MDE）：想偵測到的最小差異（例如 5% → 6%，相對提升 20%）
• 顯著性水準 α：通常 0.05
• 統計檢定力 1 - β：通常 0.8

以基準轉換率 5%、MDE 相對提升 20%（5% → 6%）、α = 0.05、power = 0.8 為例，每組需要約 14,500 個樣本。如果每天有 1,000 個使用者，需要跑 29 天。

樣本量不足時的常見錯誤是「提早看結果」— 跑了 3 天看到 p < 0.05 就停止。提早停止會膨脹 Type I error 率，因為隨機波動在小樣本中更容易產生看似顯著的差異。

多重比較

同時跑多個 A/B test 或測試多個變體（A/B/C/D）時，整體的 Type I error 率會膨脹。

跑 20 個 test，即使所有 test 的 H0 都成立（沒有真實差異），預期有 1 個 test（20 × 0.05）會出現 p < 0.05 的偽陽性。

Bonferroni 校正

最簡單的校正方式：把顯著性水準除以測試數量。跑 5 個 test，每個 test 的顯著性水準改為 0.05 / 5 = 0.01。

Bonferroni 校正很保守 — 降低了偽陽性但也降低了統計檢定力，可能錯過真實的差異。

False Discovery Rate（FDR）

Benjamini-Hochberg 方法控制的是「被判為顯著的結果中偽陽性的比例」，比 Bonferroni 更寬鬆。適合探索性分析（同時測試多個指標，容許一些偽陽性）。

A/B test 在自架方案的可行性

自架 collector 可以做基礎的 A/B test 分析 — 在行為事件中記錄使用者的分組（variant: "control" / variant: "treatment"），計算每組的轉換率，用統計檢定比較差異。

統計計算（p-value、信賴區間）可以用 Python（scipy.stats）或 R 完成。不需要商業 A/B test 平台。

商業 A/B test 平台（Optimizely、LaunchDarkly、Firebase Remote Config）額外提供的是：隨機分組管理、提早停止的統計保護（sequential testing）、多變體管理的 UI、和其他分析工具的整合。

下一步路由

• 推薦系統概論 → 推薦系統概論
• 使用者分群 → RFM 分群
• 行為事件設計 → 行為事件設計

Collaborative Filtering

Collaborative filtering 的核心假設是「和你行為相似的人喜歡的東西，你也可能喜歡」。它不分析物品的內容，只看使用者的行為模式。

User-based

找到和目標使用者行為最相似的一群人（neighbors），把 neighbors 互動過但目標使用者沒互動過的物品推薦給目標使用者。

資料需求：使用者-物品互動矩陣（user × item matrix），每格是評分、點擊、購買等互動訊號。

挑戰：使用者數量增加時，計算使用者相似度的成本呈平方增長。冷啟動問題 — 新使用者沒有足夠的互動歷史來找到 neighbors。

Item-based

計算物品之間的相似度（根據哪些使用者同時互動過這兩個物品），推薦和使用者已互動物品相似的物品。

資料需求：同上，但相似度計算的維度是物品而非使用者。

優勢：物品的相似度矩陣比使用者相似度穩定（物品不會突然改變行為，使用者會），可以離線計算和快取。Amazon 的「購買此商品的人也買了」就是 item-based collaborative filtering。

Content-based Filtering

Content-based filtering 分析物品的內容特徵，推薦和使用者過去喜歡的物品內容相似的物品。

資料需求：每個物品的特徵向量（genre、author、price range、keywords）和使用者的偏好 profile（從歷史互動推斷）。

優勢：不依賴其他使用者的行為 — 單一使用者就能產生推薦。新物品只要有特徵描述就能被推薦（解決 collaborative filtering 的新物品冷啟動）。

挑戰：推薦結果傾向和使用者歷史行為相似，缺乏意外發現（serendipity）。特徵工程的品質直接影響推薦品質 — 物品的特徵描述不完整或不準確，推薦就不準確。

混合方法

結合 collaborative filtering 和 content-based 的優勢，減少各自的弱點。

加權混合

兩種方法各自產生推薦清單，用加權分數合併。權重可以固定，也可以根據情境動態調整（新使用者偏重 content-based，老使用者偏重 collaborative filtering）。

特徵增強

用 content-based 的特徵增強 collaborative filtering 的矩陣。使用者-物品互動矩陣加上物品的內容特徵，讓相似度計算同時考慮行為和內容。

級聯

先用一種方法粗篩，再用另一種方法排序。Collaborative filtering 產生候選清單，content-based 根據使用者的內容偏好排序。

行為事件在推薦系統的角色

推薦系統的輸入是使用者的互動行為 — 瀏覽、點擊、加入購物車、購買、評分。這些互動行為就是行為事件（模組一 心智模型）的 event 類型。

行為事件的設計直接影響推薦系統的資料品質。事件的粒度決定了推薦的精細度 — 只記錄「頁面瀏覽」比記錄「頁面瀏覽 + 停留時間 + 滾動深度」的推薦信號弱。

下一步路由

• 使用者分群的工程實作 → RFM 分群
• 行為事件設計 → 行為事件設計
• 自架方案的分析能力邊界 → 從 collector 資料做基礎 funnel 分析

三個維度

Recency：最近一次互動的時間距離

計算使用者最後一次有意義的互動到現在的天數。「有意義的互動」取決於業務定義 — 電商是最後一次購買，SaaS 是最後一次登入，媒體是最後一次內容消費。

Recency 的價值在於「最近互動的使用者比很久沒來的使用者更可能再次互動」。Recency 高（最近才來）的使用者是活躍群體，Recency 低（很久沒來）的使用者是流失風險群體。

Frequency：互動的頻率

計算使用者在特定時間窗口內的互動次數。時間窗口取決於業務節奏 — 日用品電商看近 90 天的購買次數，SaaS 看近 30 天的登入次數。

Frequency 區分「偶爾來的使用者」和「常客」。高頻使用者是產品的核心用戶群，他們的行為和需求代表產品的核心價值。

Monetary：互動的價值

計算使用者在特定時間窗口內貢獻的總金額。適用於有直接收入的業務（電商、訂閱服務）。

沒有直接收入的產品可以用替代指標：內容平台用消費的內容數量，社群平台用產生的內容數量，工具類產品用使用的功能數量。替代指標的選擇依據是「哪個行為最能代表使用者的投入程度」。

RFM 分數計算

每個維度獨立評分，通常用 1-5 分。評分方式有兩種：

等距分割

把每個維度的值域等分成 5 段。Recency 0-6 天 = 5 分、7-13 天 = 4 分、依此類推。

優點是簡單直覺；缺點是不考慮使用者分佈 — 如果大部分使用者的 Recency 在 0-6 天，5 分的群體佔大多數，分群的鑑別度低。

等量分割（分位數）

用分位數確保每個分數段的使用者數量大致相等。前 20% 的 Recency = 5 分、次 20% = 4 分。

優點是每個分數段有足夠的使用者數量做分析；缺點是分數的業務意義不固定 — 5 分代表的天數取決於使用者分佈，不是固定的閾值。

RFM 群體定義

三個維度各 5 分，組合出 125 種 RFM profile（5 × 5 × 5）。實務上不需要 125 種策略，通常歸納成 5-8 個有業務意義的群體：

工程實作

RFM 計算的輸入是使用者的行為事件。從 collector 的 JSONL 資料計算 RFM：

1. 擷取：篩選目標事件（購買、登入、使用功能），按 user_id 分群
2. 計算 R：每個 user_id 的最新事件時間到現在的天數
3. 計算 F：每個 user_id 在時間窗口內的事件數量
4. 計算 M：每個 user_id 在時間窗口內的 monetary 屬性加總
5. 評分：對 R/F/M 各自用分位數或等距分割評分
6. 分群：根據 RFM 分數組合定義群體

這個計算可以用 SQL（如果資料在資料庫）或 Python pandas（如果資料在 JSONL 檔案）完成。定期重算（每天或每週），產出使用者群體標籤。

RFM 分群需要的資料可以從自架 collector 提取 — 從 collector 資料做基礎 funnel 分析展示了 grep + jq 在自架環境中的分析能力和邊界。RFM 分出的群體還可以用 Cohort analysis 追蹤留存趨勢，兩種分析互補。分群和分析的前提是正確的行為事件設計 — 事件的屬性決定了 R/F/M 能否被計算。

定義 funnel 步驟

Funnel 分析的第一步是列出每一步和對應的事件名稱。以一個透過 WebSocket 連接遠端終端機的 app 連線流程為例：

SQLite 層：每步事件計數

SQLite backend 能做的 funnel 是「每步有多少事件觸發」— 單表 GROUP BY，不需要跨事件 JOIN。

1SELECT name, COUNT(*) as count
2FROM events
3WHERE name IN ('terminal.connect.start', 'auth.biometric.success',
4               'terminal.connect.done', 'terminal.input.submit')
5  AND ts >= datetime('now', '-7 days')
6GROUP BY name;

步驟 N 的轉換率 = 步驟 N 的事件數 / 步驟 N-1 的事件數。流失率 = 1 - 轉換率。

能做的

• 每步事件計數（單表 GROUP BY）
• 按 source.version 或 source.platform 分群（加 WHERE 條件）
• 按天/按週看趨勢（strftime 分桶 + GROUP BY）

做不到的

• Session 級轉換率：「同一個 session 完成步驟 1 到步驟 4 的比例」需要 JOIN 同 session 的多個事件、跨所有 session 聚合。SQLite 能做這個 JOIN，但在大量 session 時效能不足。
• 步驟間耗時：「使用者在步驟 1 和步驟 2 之間等了多久」需要 self-join on session_id + timestamp 差值計算。
• 漏斗順序驗證：確認使用者是按 1→2→3→4 順序完成、不是跳步。

PostgreSQL 層：Session 級 funnel

PostgreSQL backend 提供 window function 和高效 JOIN，能做完整的 session 級 funnel 分析。

 1WITH session_steps AS (
 2  SELECT session_id, name,
 3         ROW_NUMBER() OVER (PARTITION BY session_id ORDER BY ts) as step_order
 4  FROM events
 5  WHERE name IN ('terminal.connect.start', 'auth.biometric.success',
 6                 'terminal.connect.done', 'terminal.input.submit')
 7    AND ts >= NOW() - INTERVAL '7 days'
 8),
 9session_max_step AS (
10  SELECT session_id, MAX(step_order) as reached
11  FROM session_steps
12  GROUP BY session_id
13)
14SELECT reached, COUNT(*) as sessions
15FROM session_max_step
16GROUP BY reached
17ORDER BY reached;

新增能力

• Session 級轉換率：每個 session 到達了哪一步、在哪一步流失
• 步驟間耗時：LAG window function 計算相鄰步驟的 timestamp 差值
• 漏斗順序驗證：用 ROW_NUMBER + CASE 確認步驟順序
• Cohort 分群的 funnel：按使用者註冊日期 / 版本 / 平台分群看不同 cohort 的 funnel 差異

JSONL 匯出後的臨時分析

Collector 的 monitor export --format=jsonl 可以匯出事件為 JSONL 格式。匯出後用 grep + jq 做一次性的臨時分析：

1for step in terminal.connect.start auth.biometric.success terminal.connect.done terminal.input.submit; do
2  count=$(grep "\"name\":\"$step\"" exported-events.jsonl | wc -l)
3  echo "$step: $count"
4done

JSONL 臨時分析適合「快速看一眼大概數字」的場景。持續性的 funnel 監控應該用 SQLite 或 PostgreSQL 的 SQL 查詢，結果穩定且可重現。

自架 vs 商業方案

自用工具場景下，SQLite 層的每步事件計數通常足夠。商業產品需要 session 級分析時，PostgreSQL 層的 SQL 能力和商業方案的分析能力在功能上對等，差異在 UI 和設定便利性。

下一步路由

• Funnel 分析的完整方法論 → Funnel analysis
• 事件設計如何影響分析品質 → 行為事件設計
• 功能分層定義 → 功能分層與 Backend 選擇
• 去識別化是分析的入場條件 → 模組七 資安與隱私