概念位置

Funnel analysis 位在行為資料收集之後、產品決策之前。它的輸入是 event 類監控事件（使用者操作記錄），輸出是每步的轉換率。Funnel analysis 的前提是去識別化（redaction）已完成 — 分析行為資料前必須確保資料不含可識別個人的敏感欄位。

可觀察訊號與例子

產品需要 funnel analysis 的訊號是「使用者在某個流程中的完成率低於預期，但不知道卡在哪一步」。註冊流程的轉換率從填寫 email 到完成驗證只有 30%，funnel analysis 揭露 60% 的使用者在「等待驗證信」步驟流失。

設計責任

Funnel analysis 要定義步驟順序、步驟之間的時間窗口（使用者在多久內完成下一步才算轉換）、以及分群維度（按平台、來源、使用者類型拆分 funnel）。步驟定義需要和事件命名規範對齊 — funnel 的每一步對應一個具體的事件名稱。

事件命名

行為事件的命名遵循 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

概念位置

Cohort analysis 位在 funnel analysis 之後、策略制定之前。Funnel analysis 回答「使用者在哪一步流失」，cohort analysis 回答「哪種使用者流失率高」。兩者搭配使用：funnel 找到流失步驟，cohort 找到流失群組，策略針對特定群組的流失步驟設計。

可觀察訊號與例子

產品需要 cohort analysis 的訊號是「整體留存率或轉換率的平均值遮蔽了群組差異」。整體 30 天留存率 40%，但按註冊來源拆分後發現自然搜尋來的使用者留存 60%、廣告來的使用者留存 20% — 平均值沒有揭露這個差異。

設計責任

Cohort analysis 要定義分群維度（按什麼特徵分）、觀察指標（留存率、活躍度、付費率）、觀察時間窗口（7 天、30 天、90 天）、以及最小群組大小（群組太小時統計不顯著）。分群維度的選擇決定了分析能揭露什麼 — 按「註冊來源」分群能看到獲客通路的品質差異，按「使用的功能」分群能看到功能黏著度差異。

Crashlytics

Firebase Crashlytics 專注在 crash 報告 — fatal crash（app 當機）和 non-fatal exception（被捕獲但值得記錄的錯誤）。

自動 crash 報告

Crashlytics SDK 在 app crash 時自動收集 crash 資訊（stack trace、device info、OS version），在下次 app 啟動時上傳。不需要開發者寫程式碼 — SDK 初始化後自動運作。

Issue 分群

和 Sentry 類似，Crashlytics 用 stack trace 自動把 crash 分群成 issue。每個 issue 有影響的使用者數、趨勢、crash-free session 比率。

和 Analytics 的關聯

Crashlytics 可以在 crash 報告中附加 Analytics 的使用者屬性和自訂 key。但兩者的 dashboard 獨立 — crash 資料在 Crashlytics console，行為資料在 Analytics console。要從「crash」追蹤到「crash 前使用者做了什麼」需要在兩個 console 之間切換。

Analytics（GA4）

Firebase Analytics 是 Google Analytics 4（GA4）的 mobile SDK 版本。記錄使用者操作事件（screen view、button click、purchase）和使用者屬性。

自動收集事件

GA4 SDK 自動收集一組預定義事件：first_open、session_start、screen_view、user_engagement。開發者不需要手動埋點就能得到基礎的使用統計。

自訂事件

開發者用 logEvent(name, parameters) 記錄自訂事件。事件名稱和參數的命名有限制（名稱 40 字元、參數 25 個、參數值 100 字元）。

和四類事件的對應

GA4 主要處理 Event 類和 Lifecycle 類事件（模組一）。Error 類由 Crashlytics 處理。Metric 類沒有原生支援 — 需要把 metric 包裝成 event 的 parameter。

Remote Config

Firebase Remote Config 讓開發者在不更新 app 的情況下修改 app 的行為 — 功能旗標（feature flag）、UI 文案、數值參數。

和 A/B test 的整合

Remote Config 和 Firebase A/B Testing 整合：定義實驗（variant A: 舊 UI / variant B: 新 UI），Remote Config 自動分配使用者到 variant，Analytics 收集兩組使用者的行為數據，A/B Testing console 顯示統計結果。

這個整合是 Firebase 生態的獨特優勢 — config 分發、使用者分群、行為收集、統計分析在同一個平台完成，不需要整合多個工具。

Firebase 的取捨

Firebase 的設計取捨是「拆分但整合」— 每個產品獨立運作（可以只用 Crashlytics 不用 Analytics），但組合使用時有整合優勢（Crashlytics + Analytics 的 user ID 共享）。

下一步路由

• Datadog 的全棧 APM → Datadog RUM
• 行為分析專用方案 → Mixpanel / Amplitude
• 自架 vs 商業的判斷 → 自架 vs 商業的判斷決策表

歸因模型

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

概念位置

RFM 位在行為資料累積到一定量之後。它需要每個使用者的 session 歷史（計算 Recency 和 Frequency）和交易歷史（計算 Monetary）。免費產品可以用替代指標取代 Monetary — 產生的內容數量、邀請的使用者數、完成的關鍵操作數。RFM 的前提和 cohort analysis 相同：去識別化（redaction）已完成。

可觀察訊號與例子

產品需要 RFM 的訊號是「需要對不同行為模式的使用者採取不同策略」。高 R 高 F 高 M 的忠實客戶需要維護關係，低 R 高 F 高 M 的潛在流失客戶需要挽留，高 R 低 F 低 M 的新使用者需要引導降低入門門檻。

設計責任

RFM 要定義每個維度的計算方式（Recency 用天數還是週數、Frequency 的時間窗口多長、Monetary 用什麼指標）、分位數（五等分還是三等分）、群組歸納（125 種 profile 歸納成幾個可操作群組）、以及重新計算的頻率（每週還是每月）。分群結果是動態的 — 使用者行為改變時群組會變。

假設檢定

虛無假設和對立假設

虛無假設（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 分群
• 行為事件設計 → 行為事件設計

行為分析 vs 通用監控

通用監控方案（Sentry、Crashlytics、Datadog）的主要產出是 error 報告和 performance 數據 — 工程團隊用來修復 bug 和優化效能。

行為分析方案的主要產出是 funnel 和 cohort 數據 — 產品團隊用來決定功能優先順序、評估改版效果、優化使用者體驗。

兩類需求可以共存。工程團隊需要 error tracking，產品團隊需要行為分析。一些團隊同時使用 Sentry + Mixpanel，各自服務不同的消費者。

核心功能

Funnel analysis

定義使用者操作的步驟序列，計算每步的轉換率和流失率。Mixpanel 和 Amplitude 的 funnel 分析支援：步驟之間的時間窗口限制（步驟 1 到步驟 2 在 24 小時內完成才算轉換）、按使用者屬性分群（新使用者 vs 老使用者的轉換率差異）、步驟之間的路徑分析（流失的使用者去了哪裡）。

自架方案能做基礎的 funnel 計數（模組八 自架 funnel），但不支援時間窗口、分群和路徑分析。

Cohort analysis

按使用者屬性或行為把使用者分成群組，比較不同群組的行為差異。例：「從 Google 廣告來的使用者」vs「從社群分享來的使用者」，兩組的留存率和付費率差異。

Retention analysis

追蹤使用者在初次使用後的回訪率。Day 1 / Day 7 / Day 30 retention — 多少使用者在首次使用後 1 天 / 7 天 / 30 天內回來。

Retention 是產品健康度的核心指標。行為分析方案提供 retention curve（留存曲線）和 retention by cohort（不同群組的留存差異），這些在自架方案中需要大量的 SQL 查詢和手動計算。

Mixpanel vs Amplitude 的差異

兩者的功能高度重疊，差異主要在定價和資料模型：

選擇依據通常是團隊的既有工具鏈和定價模型偏好。

什麼時候需要行為分析方案

行為分析方案的投資在以下條件下有回報：

有產品團隊消費數據：如果只有工程團隊，error tracking + 自架 log 通常足夠。行為分析方案的 dashboard 需要產品團隊定期查看和基於數據做決策。

使用者數量足夠產生統計意義：Funnel 和 cohort 分析需要足夠的樣本量。DAU < 100 的產品，分析結果的統計信度低。

有明確的優化目標：「提高註冊轉換率」「降低 Day 7 流失率」— 有具體的 metric 目標，行為分析方案能提供追蹤和歸因。

自用工具場景下不需要行為分析方案 — 使用者就是開發者本人，行為數據沒有分析價值。

下一步路由

• 自架 vs 商業的判斷 → 自架 vs 商業的判斷決策表
• 行為分析的方法論 → 模組八 行為資料的商業利用
• 四類事件在商業方案中的對應 → 模組一 商業方案事件類型對應

Debug 動機

Debug 動機驅動的事件收集目標是「問題發生時、開發者能從事件記錄中重建 context 並定位根因」。

要偵測的行為

• 多步驟流程的每一步完成或失敗（連線 → 認證 → 資料交換）
• 系統狀態轉換（前景/背景、連線/斷線、登入/登出）
• 非預期例外（uncaught exception、network error、timeout）
• 使用者最近的操作序列（問題發生前做了什麼）

事件表

查詢場景

Session 回放：按 session_id 過濾、按時間排序，還原「使用者做了什麼 → 系統發生了什麼 → 問題在哪裡出現」。

Error 根因定位：按 error name GROUP BY，找出最常出現的錯誤。單筆 error 的 stack_trace + 同 session 的 lifecycle 事件組合，判斷失敗發生在流程的哪一步。

最近 N 個操作：error 發生前的 10-20 個 event/lifecycle 事件，等同 Sentry 的 breadcrumb trail。

生命週期階段

開發期起全開。Debug 事件是最早需要的 — 實機測試階段就依賴這些事件定位問題。error 類和 lifecycle 類不做取樣（量低且每筆都可能是線索）。

商業動機

商業動機驅動的事件收集目標是「回答產品決策的問題 — 使用者在哪裡流失、不同群組行為有什麼差異、哪些功能被使用」。

要偵測的行為

• 漏斗步驟完成（註冊 → 啟用 → 付費 → 續約的每一步）
• 功能使用頻率（哪些功能被頻繁使用、哪些從未被觸發）
• Session 長度和頻率（使用者多常用、每次用多久）
• 關鍵轉換事件（首次付費、邀請好友、升級方案）

事件表

查詢場景

Funnel 轉換率：每步的完成數 / 上一步的完成數。SQLite 層做每步計數，PostgreSQL 層做 session 級 JOIN 的精確轉換率（見 功能分層與 Backend 選擇）。

Cohort 留存：按「首次使用週」分群，計算每週的回訪率。需要 session.start 事件 + 使用者首次出現的時間戳。

功能使用率：feature.*.used 事件按 name GROUP BY COUNT，排序找出最常/最少使用的功能。

生命週期階段

上線後啟用。開發期不需要商業事件（沒有真實使用者）。測試期可以用模擬流量驗證 funnel 事件的觸發正確性，但不做分析。

資安動機

資安動機驅動的事件收集目標是「偵測非預期的存取模式、追蹤敏感操作、提供事後稽核的 audit trail」。

要偵測的行為

• 認證失敗（密碼錯誤、biometric 失敗、token 過期）
• 權限越界嘗試（嘗試存取非自己的資源、呼叫無權限的 API）
• 敏感資料存取（查看個資、匯出資料、修改權限設定）
• 異常存取模式（短時間大量請求、非常規時段存取、來源 IP 變化）

事件表

查詢場景

認證失敗監控：auth.*.failed 事件的 count by session_id，短時間內同一 session 多次失敗 → 暴力破解嫌疑。Rule engine 設閾值告警。

Audit trail：sensitive.* 和 admin.* 事件按時間排列，回答「誰在什麼時候存取/修改了什麼」。合規審計的必要紀錄。

異常 pattern 偵測：auth 成功後的操作事件頻率和模式分析。正常使用者每 session 操作 10-50 次；自動化腳本可能操作數千次。

生命週期階段

開發期起全開。安全事件不能延後 — 「先不收安全事件、上線後再加」等於安全審計的空白期。認證相關事件是 auto-intercept 的一部分（見 自動攔截機制），不需要手動埋點。

和 redaction 的關係

資安事件本身可能包含敏感資訊（失敗的密碼、被存取的個資欄位名稱）。事件的 data schema 設計時標記需要 redaction 的欄位 — auth.failed 記錄失敗原因但不記錄輸入的密碼、sensitive.accessed 記錄資源類型但不記錄資源內容。

效能動機

效能動機驅動的事件收集目標是「發現效能退化趨勢、定位效能瓶頸、為容量規劃提供數據」。

要偵測的行為

• 操作回應時間（API 呼叫、頁面載入、動畫轉場）
• 渲染效能（frame rate、長任務、佈局重排）
• 資源使用（記憶體、CPU、網路流量）
• 外部依賴延遲（第三方 API、CDN、資料庫查詢）

事件表

查詢場景

P95 趨勢：{operation}.duration 事件按天聚合、計算 percentile_cont(0.95)，觀察回應時間是否隨版本增加。

容量規劃：resource.memory 事件的趨勢圖，判斷記憶體是否隨使用時間穩定增長（memory leak 訊號）。

依賴健康度：dependency.*.latency 事件按 dependency_name GROUP BY，比較各依賴的平均延遲和失敗率。

生命週期階段

測試期起啟用。開發期不需要效能事件（本地環境的效能數據不代表 production）。測試期啟用用於建立效能 baseline。上線後持續收集用於趨勢監控。

效能事件量通常最大（每 30 秒一筆 resource.memory × 活躍使用者數），取樣率需要控制 — 自用場景全收、商業產品取樣 10-50%（見 前端感測器設計 的取樣策略段）。

A/B 測試動機

A/B 測試動機驅動的事件是商業動機的延伸 — 實驗期間收集實驗分組和轉換事件，實驗結束後關閉。

事件表

生命週期階段

實驗期間啟用，實驗結束後關閉（從 SDK config 或 feature flag 移除）。實驗事件的保留期限跟著實驗週期走 — 實驗結束 + 分析完成後可清除。A/B test 的統計分析見 A/B test 的統計基礎。

完整對照總表

下一步路由

• 四類事件的基礎定義 → 四類事件的完整定義
• 事件枚舉的方法論 → 事件枚舉與補齊檢查
• 前端感測器的具體設計 → 前端感測器設計
• 感測器的生命週期控制 → 感測器生命週期管理
• 查詢消費模式的完整展開 → 查詢消費模式

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 選擇
• 去識別化是分析的入場條件 → 模組七 資安與隱私

待寫章節

• 行為事件設計（事件命名規範 / 屬性設計 / funnel 定義）
• Funnel analysis（使用者在哪一步流失）
• Cohort analysis（不同族群的留存率差異）
• Attribution（使用者從哪來、哪個廣告帶來轉換）
• A/B test 的統計基礎（假設檢定 / 樣本量 / 多重比較）
• 推薦系統概論（collaborative filtering / content-based / 混合）
• RFM 分群（Recency / Frequency / Monetary 的工程實作）
• 從 collector 資料做基礎 funnel 分析（自架方案能做到哪裡）

跨分類引用

• ← monitoring 模組七 資安：去識別化是入場條件
• ← monitoring 模組一 心智模型：event 類事件是行為分析的原料
• ← ux-design 模組一 畫面狀態機：狀態轉換事件 → funnel 分析
• 待建連結 → data-engineering/（資料管線設計）
• 待建連結 → statistics/（A/B test 統計基礎）
• 待建連結 → machine-learning/（推薦系統架構）
• 待建連結 → compliance/（GDPR / CCPA / 個資法）

中台 dashboard 的所有深入分析視圖都需要 PostgreSQL 層（功能分層與 Backend 選擇），因為它們依賴跨 session 的 JOIN 和大規模聚合查詢。SQLite 層只能提供基礎的事件計數。

日常監控視圖

DAU / MAU

每日活躍使用者數（DAU）和每月活躍使用者數（MAU）的趨勢折線圖。活躍使用者的定義是「該時間段內至少有一筆 session.start 事件的唯一 session」。

DAU / MAU 比值（粘性指數）是產品健康的基本訊號 — 比值越高代表使用者回訪越頻繁。一般 SaaS 產品的 DAU/MAU 在 10-20% 為正常範圍，社交類產品期望 50% 以上。

1-- PostgreSQL
2SELECT date_trunc('day', ts) as day,
3       COUNT(DISTINCT session_id) as dau
4FROM events
5WHERE type = 'lifecycle' AND name = 'session.start'
6  AND ts >= NOW() - INTERVAL '30 days'
7GROUP BY day
8ORDER BY day;

核心漏斗

主要業務流程的每步轉換率。漏斗的步驟從 動機驅動的事件設計 的商業動機段定義。

日常視圖顯示最近 7 天的整體轉換率 — 營運人員每天看「昨天的漏斗有沒有異常」。轉換率突然下降是產品問題的早期訊號（UI 改版影響操作流程、第三方服務異常阻擋流程）。

功能使用排行

按 event.name 計數的排行榜。營運用它判斷「哪些功能有人用、哪些沒人用」— 功能投資的 ROI 判斷依據。

1-- SQLite 層可用（基礎計數）
2SELECT name, COUNT(*) as usage_count
3FROM events
4WHERE type = 'event'
5  AND ts >= datetime('now', '-7 days')
6GROUP BY name
7ORDER BY usage_count DESC
8LIMIT 20;

功能使用排行是 SQLite 層就能提供的視圖 — 單表 GROUP BY。

分析深入視圖

日常視圖發現異常後，營運人員進入分析視圖深入探究。所有分析視圖都需要 PostgreSQL 層。

Funnel 漏斗圖

互動式漏斗圖：選擇步驟 → 看每步轉換率 → 點擊某步看流失使用者的行為。

Funnel 需要 session 級 JOIN — 「同一個 session 完成了步驟 1 到步驟 N 中的哪些步驟」。完整的 SQL 查詢見 從 collector 資料做基礎 funnel 分析。

Cohort 留存表

按「使用者首次出現日期」分群的留存率矩陣。行是 cohort（第 N 週註冊的使用者），列是「第 1/2/3/…週的回訪率」。

需要的事件：user.first_seen（cohort 分群依據）+ session.start（回訪判定）。

user.first_seen 是 collector 端計算的衍生事件 — 當某個 session_id 或 user identifier 在系統中第一次出現時記錄。和 SDK 端送來的原始事件不同，它的產生者是 collector 的計算邏輯。

A/B 測試結果

實驗的 variant 間轉換率比較 + 統計顯著性指標（p-value、信賴區間）。

需要的事件：experiment.{name}.assigned（分組）+ experiment.{name}.converted（轉換）。這些事件在 動機驅動的事件設計 的 A/B 測試段定義。統計分析的方法見 A/B test 的統計基礎。

RFM 分群散佈圖

三維度（Recency / Frequency / Monetary）的使用者分群。每個使用者計算 R/F/M 分數，按分數分群後在散佈圖上顯示。

需要的事件：event 類的購買/使用事件 + lifecycle 的 session 事件。計算方法見 RFM 分群。

通路歸因

使用者從哪裡來（哪個廣告、哪個推薦連結、自然流量），每個通路帶來多少轉換。

需要的事件：attribution.install_source（SDK 首次啟動時從 referrer / UTM 參數 / deep link 取得安裝來源）+ conversion.{type}（轉換事件）。

attribution.install_source 只在 SDK 首次啟動時送一次。來源資訊的取得方式依平台不同 — Web 從 URL 的 UTM 參數取、mobile app 從 deferred deep link 或 install referrer API 取。

需要的缺口事件

中台 dashboard 暴露了三個目前事件表未覆蓋的事件：

這三個事件的共同特徵：前兩個是「只發生一次」的事件（首次出現、首次安裝），第三個是 collector 端的即時計算結果。操作盤點和四類補齊檢查聚焦在「反覆發生的使用者操作」，容易遺漏「只發生一次」的生命週期轉折點和 collector 端的衍生計算。

中台的權限隔離

營運和行銷人員看行為資料，但不需要也不應該看到 stack trace、raw error message、session 級別的原始事件明細。權限隔離在 collector 的查詢 API 層實作 — 不同的 API scope 回傳不同粒度的資料。

Scope 的實作可以是 API key 分級（不同 key 有不同 scope）、或 HTTP header 帶 role。Day-one 可以跳過（自用場景只有 developer 一個角色），tripwire 是「第一個非開發者要看 dashboard 時加入 scope 機制」。

下一步路由

• DevOps dashboard 設計 → DevOps Dashboard 設計
• Developer dashboard 設計 → Developer Dashboard 設計
• Funnel 分析的完整方法 → Funnel analysis
• 功能分層與 Backend 選擇 → 功能分層與 Backend 選擇
• 去識別化是中台 dashboard 的入場條件 → 模組七 資安與隱私
• 畫面狀態矩陣定義了 funnel 步驟的操作來源 → 畫面狀態矩陣