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 天）、以及最小群組大小（群組太小時統計不顯著）。分群維度的選擇決定了分析能揭露什麼 — 按「註冊來源」分群能看到獲客通路的品質差異，按「使用的功能」分群能看到功能黏著度差異。

行為分析 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 商業的判斷決策表
• 行為分析的方法論 → 模組八 行為資料的商業利用
• 四類事件在商業方案中的對應 → 模組一 商業方案事件類型對應

中台 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 步驟的操作來源 → 畫面狀態矩陣