可預期突發

事前知道流量會增加，有時間準備。

可預期突發的應對核心是容量預備 — 活動前擴容、活動後縮回。

預備清單

不可預期突發

事前不知道流量會增加，只能靠架構設計吸收。

不可預期突發的應對核心是降級 — 系統在超載時自動犧牲非核心功能，保住核心功能。

監控系統的 error storm

Error storm 是監控系統特有的突發場景：被監控的 app 出了 bug，每個受影響的使用者都在送 error 事件。如果有 10 萬使用者同時遇到同一個 bug，collector 瞬間收到 10 萬筆 error 事件。

Error storm 的矛盾：error 事件是 debug 最需要的資料，但 storm 時的大量 error 可能打垮 collector。處理策略是保留前 N 筆完整 error（含 stack trace）、後續的 error 只計數不存原始資料。第一筆 error 的 stack trace 足夠 debug，後續的 10 萬筆只是確認影響範圍。

下一步路由

• 突發時的降級策略 → 降級策略
• Queue 做 burst 緩衝 → Queue 緩衝
• 不同規模的應對方案 → 規模分級應對表

歸因模型

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

三個維度

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 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 / 個資法）