概念位置

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

可觀察訊號與例子

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

設計責任

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

概念位置

Redaction 位在 SDK 端的事件產生和 collector 端的事件接收之間。它是監控資料安全的第一道防線 — 在資料離開使用者裝置之前處理，比 collector 端的 access control 更早介入。Redaction 和 transport 加密（HTTPS）互補：redaction 保護欄位內容，transport 加密保護傳輸過程。與 error fingerprint 相比，兩者都在資料落地前處理，但 redaction 防止敏感內容外洩、fingerprint 防止同因錯誤重複灌爆列表。

可觀察訊號與例子

系統需要 redaction 的訊號是監控事件的 data 欄位可能包含使用者輸入。CLI 輸入可能含密碼（mysql -p'secret'）、API key（Authorization: Bearer sk-...）、連線字串（含帳密的 URL）。IME 個人化學習也是洩漏面 — 輸入框的內容被 IME 學習後跨 app 可見。

設計責任

Redaction 要定義預設規則（哪些欄位名稱自動 redact）、自訂 pattern（正則表達式比對敏感值）、執行時機（event 進入 buffer 前還是 flush 時）、以及 redaction 失敗的處理（丟棄整筆事件 vs 只移除敏感欄位）。這些規則只管得到網站自己 SDK 送出的事件；同一個頁面上的商業追蹤碼由 vendor 的 script 直接送出，遮蔽要用 vendor 提供的設定，見 Autocapture（自動事件收集）。

概念位置

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

可觀察訊號與例子

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

設計責任

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

概念位置

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 歸納成幾個可操作群組）、以及重新計算的頻率（每週還是每月）。分群結果是動態的 — 使用者行為改變時群組會變。

概念位置

Error fingerprint 位在 collector 收到 error 事件之後、寫入 storage 之前。它的輸入是通過 schema validation 的 error 事件，輸出是附加了 _fingerprint 欄位的事件和更新後的 error_groups 摘要表。Fingerprint 只作用於 type: "error" 的事件 — 其他三類事件（event / metric / lifecycle）不需要去重分群。與 redaction 同樣運作在事件寫入 storage 之前，但目的不同——redaction 處理欄位內容的隱私、fingerprint 處理事件的分群鍵。

可觀察訊號與例子

需要 fingerprint 的訊號是「dashboard 的 error 列表中，同一個 bug 因為 error message 包含動態值（user ID、timestamp、IP）而分裂成多個不同的行」。例如 "User 12345 not found" 和 "User 67890 not found" 是同一個 bug，但 name-based grouping（GROUP BY name）把它們歸為同一行時，丟失了 message 中的動態值資訊；而沒有 normalization 的 message-based grouping 會把它們分裂成兩行。

設計責任

Fingerprint 承擔的設計責任是「在 error 的精確識別和分群粒度之間找到平衡」。過粗的 fingerprint（只用 error type）把不同 bug 混在同一組；過細的 fingerprint（用完整 message 含動態值）把同因 error 分裂成多組。

自架 vs 商業方案

自架方案用規則做 fingerprint — regex normalize message（替換數字 / UUID / email / IP 等動態值）+ stack trace top N frames 做 hash。Sentry 在規則之上加了 in-app frame 過濾（忽略 framework / library frame）、source map 反解（minified JS → 原始碼位置）、和 ML-based grouping（語意相同但結構不同的 error 歸組）。差距主要在 minified / obfuscated 環境和 ML — 明文 stack trace 的場景下兩者效果相當。

完整章節

Fingerprint 演算法（基礎 / 進階 / Sentry / 自定義）、message normalization 的替換規則和風險、error_groups 表的 DDL 和 UPSERT 流程、dashboard 整合、自架方案的務實邊界 → Error Fingerprint 與去重分群。

概念位置

背壓位在 SDK 和 collector 之間的 HTTP 通訊層。觸發順序：collector 的寫入 channel 容量耗盡 → HTTP handler 無法送入事件 → 回 429 → SDK 收到 429 → SDK 降低取樣率（從 1.0 → 0.5 → 0.1）。背壓是全域的容量訊號 — 所有 SDK 同時收到，所有 SDK 同時降速。

可觀察訊號與例子

需要關注背壓的訊號是 collector 端的 collector.events.backpressure 計數器持續上升、或 SDK 端的 sdk.sampling.rate 低於 1.0。典型場景：行銷活動導致同時在線使用者暴增 → 所有 SDK 同時 flush → collector channel 瞬間填滿 → 全域 429 → 所有 SDK 動態降採樣。

和 DevOps 背壓的關係

運行期維運 流量管控討論通用的背壓概念（TCP flow control、message queue consumer lag、circuit breaker）。本系列聚焦 SDK ↔ collector 之間的具體實作 — HTTP 429 是訊號、動態取樣是回應、Go channel 容量是觸發條件。通用概念在 運維模組，監控場景的具體機制在本系列。

完整章節

背壓在四層防線中的位置（第二層 collector 單機防護）→ Ingestion Scaling。背壓造成的資料損失和控制策略 → 端到端資料完整性。

概念位置

Sampling 位在管線最上游（SDK 產生事件的階段），比 backpressure 早一步 — backpressure 是下游滿載後回傳的訊號，動態取樣正是 SDK 收到這個訊號後的回應動作。靜態取樣則跟 rate limiting 一樣是主動設定的固定策略，差別在取樣發生在事件產生端、rate limiting 發生在 collector 接收端。

兩種取樣

靜態取樣：SDK config 中設定固定比例（例如 metric 類 0.1 = 每 10 筆只收 1 筆），在 SDK 整個生命週期保持不變。適合已知高頻但單筆 debug 價值低的事件（render.frame_time、scroll.position）。

動態取樣：SDK 在收到 collector 的 HTTP 429 後自動降低取樣率，collector 恢復正常後逐步回升。動態取樣在正常情況下不生效（取樣率 = 1.0），只在 collector 過載時啟用。和靜態取樣互補 — 靜態控制基線負載，動態應對突發。

可觀察訊號與例子

分析時用取樣率還原原始量級。取樣率 0.1 時收到 100 筆事件，推估原始量為 100 / 0.1 = 1000 筆。SDK 端的 sdk.sampling.rate 指標記錄當前取樣率，讓下游分析知道如何校正。

判讀方式

取樣校正對 funnel 和 cohort 分析有效（趨勢和比例不變），對個別事件追蹤無效（被丟棄的事件無法回復）。取樣承擔的設計責任是「在可觀測性覆蓋率和系統負載之間找到平衡」。Error 類事件不做取樣（每筆都可能是需要修的 bug），metric 類事件適合高比例取樣（丟幾筆不影響趨勢），event 類和 lifecycle 類取決於分析需求。

完整章節

靜態取樣率的設定 → 感測器生命週期管理。動態取樣在四層防線中的位置 → Ingestion Scaling。取樣造成的損失量化和控制 → 端到端資料完整性。

概念位置

Rate limiting 和 backpressure 都限制流量，但保護的維度不同。Rate limiting 是 per-client 的配額機制 — 每個 API key 有獨立的速率上限，一個 client 超限不影響其他 client。Backpressure 是全域的容量訊號 — collector 的寫入 channel 滿時對所有 client 回 429，不區分來源。一個 client 的失控用 rate limiting 處理（隔離問題源），全域流量過大用 backpressure 處理（全體降速）。

可觀察訊號與例子

Rate limiting 觸發的訊號是 collector 端對特定 API key 回 429 的次數上升、而其他 key 正常。典型場景：某個 SDK 版本有 bug 導致每秒產生 1000 筆事件 → per-key rate limiter 超過閾值 → 該 key 的後續 request 被回 429 → 其他 SDK 不受影響。

判讀方式

Rate limiting 承擔的設計責任是「在公平性和可用性之間取得平衡」。閾值設太低，正常的 burst flush（攢批後一次送出）會被誤觸；閾值設太高，失控的 SDK 要送很多筆才被擋。合理的閾值需高於正常 burst 的事件速率。

完整章節

Per-SDK rate limiting 的實作 → Ingestion Scaling。Rate limiting 在 collector access control 中的角色 → Collector Access Control 實作。偽造流量場景下 rate limiting 和其他防護層的配合 → Client-side SDK 認證。

概念位置

第一方 cookie 是追蹤碼在第三方 cookie 被瀏覽器限制之後保存識別碼的位置。第三方 cookie 由 vendor 的網域直接讀寫，第一方 cookie 寫在網站網域上，瀏覽器送往 vendor 網域的請求不會在 Cookie 標頭裡帶上網站網域的 cookie，所以追蹤碼在瀏覽器裡讀出它的值，放進事件請求的參數送出：在預設設定下（使用者沒有透過同意機制拒絕、追蹤碼的第一方 cookie 設定沒有關掉），Meta Pixel 的每一筆事件都帶 fbp 參數，值就是 _fbp 的內容；GA4 的 collect 請求帶 cid，與 _ga 值以點分隔的最後兩段數字相同。網站自己沒有呼叫的自動事件也帶著這些參數送出。

cookie 期限的設定者與瀏覽器上限

cookie 的到期時間由寫入它的 script 設定，再受瀏覽器的規則截斷。Chrome 從 104 版起把任何 cookie 的到期時間上限訂為 400 天，要求更久的 cookie 會被改成 400 天。Safari 的 Intelligent Tracking Prevention（ITP）對追蹤碼常用的寫法另有三條限制，依 WebKit 的追蹤防護說明頁：由 JavaScript 寫入的 cookie 與其他 script 寫得到的儲存資料（例如 localStorage），在使用者 7 天沒有與這個網站互動之後刪除（WebKit 先前的說明以使用 Safari 的天數計，現行說明頁沒有寫單位），重新起算的條件是互動、不是單純的造訪；ITP 偵測到網址帶著點擊 ID 這類參數（link decoration）時，落地頁上由 JavaScript 寫入的 cookie 期限上限是 24 小時（WebKit 先前的說明寫明的條件是：把使用者導過來的網域被分類為追蹤者，而且網址帶查詢字串或片段）；回應來自偽裝成第一方、實際指向第三方的伺服器（CNAME 或第三方 IP 偽裝）時，那個 HTTP 回應寫入的 cookie 期限上限是 7 天。所以同一個追蹤碼在不同瀏覽器上的 cookie 壽命不同：GA4 代碼替 _ga 與 _ga_<評估 ID> 設的預設期限是兩年，在 Chromium 上實測看到的 400 天是瀏覽器的上限，不是 GA4 的設定；從 Meta 廣告帶著 fbclid 點進來的那一次，_fbc 與 _fbp 正好在落地頁上由 JavaScript 寫入，在 Safari 上可能只留一天。

可觀察訊號與例子

在開發者工具的 Application 面板（Chrome）或儲存空間面板（Firefox）查看網站網域底下的 cookie，看名稱、網域、到期時間與 HttpOnly 欄位；由 JavaScript 寫入的 cookie 不能設 HttpOnly，所以頁面上任何 script 都讀得到它。一次在 Chromium 上的實測裡，_fbp 與 _fbc 的到期時間是寫入起算 90 天，_ga 與 _ga_<評估 ID> 是 400 天，四個都不是 HttpOnly、SameSite 都是 Lax；_fbc 只有網址帶了廣告的點擊 ID（fbclid）時才寫入。各 cookie 的值怎麼對應到事件參數，以 用 Playwright 擷取追蹤碼請求 的結果檔為準。

判讀方式

一個 cookie 受哪些限制，取決於兩個屬性：它寫在哪個網域，以及它由 JavaScript 寫入還是由伺服器回應的 Set-Cookie 標頭寫入。寫入方式可以在 Network 面板分辨：某個回應的 Set-Cookie 標頭帶著這個名稱，就是伺服器寫的；所有回應都沒有、而它在 script 執行之後出現，就是 JavaScript 寫的。網域決定瀏覽器的第三方 cookie 封鎖管不管得到它，封鎖第三方 cookie 不影響第一方 cookie；寫入方式（連同回應來自誰的伺服器）決定 ITP 的哪一條限制管得到它，JavaScript 寫入的第一方 cookie 仍然受 ITP 限制，所以同一個人隔一週以上沒有互動、或從廣告點進來隔天才回來時，可能被追蹤碼當成另一個瀏覽器。用 Network 面板分辨寫入方式時，要用無痕視窗或先清掉這個網站的 cookie、在載入頁面之前就打開面板，否則前一次造訪留下的 cookie 會被誤判成 JavaScript 寫的。在歐盟 ePrivacy 指令下（第 5(3) 條，本站的解讀見配額、濫用防護、隱私與遷移訊號的〈隱私與 PII 邊界〉），判斷是否要取得使用者同意時，看的是「在使用者的裝置上儲存或讀取資訊」這個動作，第一方或第三方都在範圍內；把識別碼寫成第一方 cookie 改變的是瀏覽器的限制，改變不了這條同意的要求。

完整章節

追蹤碼寫下哪些 cookie、值怎麼對應到事件參數 → 用 Playwright 擷取追蹤碼請求。_fbp、_fbc 在伺服器端事件裡的用途與 ITP 造成的損失 → Meta Pixel 與 Conversions API。cookie 期限在儲存限制裡的位置 → GDPR 最小化原則的工程落地。

概念位置

無頭模式改變的是瀏覽器自己對外暴露的特徵，追蹤碼在訪客的瀏覽器裡、收資料的伺服器在 vendor 那一端，都可能依這些特徵決定事件送不送出、收不收下。最直接的特徵是 User-Agent（瀏覽器在每個請求裡附上的身分字串）：一次以 Playwright 預設無頭模式啟動 Chromium 的實測裡，User-Agent 帶 HeadlessChrome 字樣，有視窗模式下是一般的 Chrome。被程式驅動則另有自己的特徵，navigator.webdriver 在 Playwright、Puppeteer、Selenium 驅動的瀏覽器裡是 true，有沒有視窗都一樣。所以「擋無頭瀏覽器」與「擋自動化」是兩條不同的規則：比對 HeadlessChrome 字樣的規則換成有視窗模式就不命中，比對 navigator.webdriver 的規則兩種模式都命中。被攔下的事件裡也包括網站沒有呼叫的自動事件，它們走的是同一條送出路徑。

可觀察訊號與例子

本站用 Playwright 寫的擷取腳本（用 Playwright 擷取追蹤碼請求）在實測頁上載入本站測試用的一個 Meta Pixel。fbevents.js 載入後會向 Meta 取得這個 Pixel 的設定檔，設定檔指定要載入的模組（plugin）裡有一個 botblocking，它拿 navigator.userAgent 比對一份含 HeadlessChrome/ 的機器人規則清單。無頭模式下 fbevents.js 照樣載入、_fbp 照樣寫入，而 PageView、ViewContent、Purchase 一筆都沒有送出；腳本改用有視窗模式之後，三筆事件都送出了。這個模組只攔事件請求，script 的載入與第一方 cookie 的寫入不受影響，頁面上的狀態訊息在兩種模式下也相同，從頁面上看不出事件沒送。GA4 的 collect 請求在無頭模式下照樣送出並收到回應；GA4 在接收端預設排除已知機器人流量，依據是 Google 的研究與 IAB（Interactive Advertising Bureau，網路廣告業的產業組織）的機器人清單，被排除了多少不會顯示，所以從擷取結果判斷不出無頭模式的事件是否進了報表。

判讀方式

兩次擷取用同一個 Pixel、在相近的時間、做相同的操作、只切換有沒有視窗時，兩種模式的結果差異量的是追蹤碼對無頭特徵的反應：有視窗模式下送得出、無頭模式下送不出的事件，是被比對 User-Agent 這類無頭特徵的規則攔下的。兩次之間隔得久，Pixel 的設定檔可能已經改版，差異就不能只歸給無頭模式。有視窗模式的 Playwright 仍然是被程式驅動的瀏覽器（navigator.webdriver 為真），所以它的結果不等於真人訪客的結果；追蹤碼改成依 navigator.webdriver 判斷時，有視窗模式也會被攔。比對自建統計與商業追蹤碼的訪問數時，差額裡可能有一部分是無頭瀏覽器的訪問：自建統計的接收端收下並標成機器流量，Meta Pixel 在瀏覽器裡就丟掉。反過來，GA4 的代碼在無頭模式下照常送出事件，所以拿正式網站的評估 ID 或 Pixel ID 跑自動化測試，事件會送進正式的資源，進不進報表由 Google 的已知機器人排除判定，而排除了多少看不到；擷取與測試用測試專用的帳戶與 ID，做法見用 Playwright 擷取追蹤碼請求的〈擷取用的測試帳號〉。

完整章節

無頭與有視窗兩種模式下 Meta Pixel 實際送出的請求、botblocking 的機制與擷取紀錄要記下的模式 → 用 Playwright 擷取追蹤碼請求。自建統計怎麼用 User-Agent、navigator.webdriver 等訊號標記機器流量 → 辨識自動化流量。GA4 預設的已知機器人排除與主機名稱篩選器 → Client-side SDK 認證的根本限制。

概念位置

自動事件收集決定的是「事件從哪裡來」，位置在事件產生的那一端，比管線上的取樣與遮蔽都早：事件的欄位由 vendor 的規則決定，網站要等它送出之後才看得到內容。它與本站自建 SDK 的自動攔截機制（auto-intercept）同樣不需要開發者為每個事件寫程式，分辨兩者的依據是送出規則由誰持有：自動攔截的規則寫在網站自己的 SDK 程式碼裡，自動事件收集的規則由 vendor 決定，網站的原始碼裡看不到。名稱各家不同：Meta 把這類事件叫自動事件（automatic events），GA4 叫自動收集的事件（automatically collected events），本站把兩者統稱為自動事件。兩家的範圍與開關也不同。

Meta Pixel 的自動事件由 Pixel 的設定檔指定的模組產生：fbevents.js 載入後會向 Meta 取得這個 Pixel 的設定檔，設定檔決定要載入哪些模組（plugin，見 Meta Pixel 與 Conversions API 的〈Meta Pixel 在瀏覽器裡做的事〉）。實測時每按一次頁面上的按鈕，fbevents.js 都在網站呼叫的事件之外多送一筆 SubscribedButtonClick，內容包含按鈕文字（cd[buttonText]）、按鈕的 DOM 特徵與頁面特徵；設定檔來自 Meta 的伺服器，所以送出哪些自動事件由 Meta 那一端的設定決定，網站的原始碼裡看不到。要關掉 Pixel 依按鈕點擊與頁面中繼資料自動送出的事件，Meta 的開發者文件給的做法是在 Pixel 基本碼裡、fbq('init', …) 之前加一行 fbq('set', 'autoConfig', false, '<Pixel ID>')，<Pixel ID> 換成自己的 Pixel ID。

GA4 的自動收集事件分成只要裝了 Google 代碼就會送的基本事件，例如 first_visit、session_start、user_engagement，以及由加強型評估（enhanced measurement）控制的事件。加強型評估是網頁資料串流（GA4 資源裡代表一個網站資料來源的設定單位）上的一組開關，涵蓋捲動、外連點擊、站內搜尋、影片互動、檔案下載與表單互動，其中檔案下載會帶連結文字（link_text）、表單送出會帶送出按鈕的文字。page_view 也列在加強型評估底下，而它是其中唯一關不掉的一項。這組開關在 GA4 管理介面的資料串流設定裡，需要編輯者以上的權限。

可觀察訊號與例子

自動事件在請求裡的樣子與網站自己呼叫的事件相同，差別只在網站的程式碼裡找不到對應的呼叫。Meta 的事件請求送到 www.facebook.com/tr/，事件名稱在 ev 參數；GA4 的事件請求送到 Google Analytics 網域下的 g/collect（在開發者工具的 Network 面板以 collect 篩選），事件名稱在 en 參數。一次 Meta Pixel 的實測裡，網站呼叫了 ViewContent 與 Purchase 各一次，擷取結果裡多出兩筆 SubscribedButtonClick，各自緊跟在一次按鈕點擊之後。

判讀方式

網站原始碼只列得出手動埋點的那一部分，網站實際送出的資料要從送出的請求裡數；按鈕文字、連結文字這類欄位也在送出範圍內，按鈕或連結上顯示了使用者的個人資料時，那段文字會一起送到 vendor。兩種埋點方式的取捨方向相反：手動埋點會漏掉沒有寫追蹤程式的互動，換到的是送出的欄位全部由開發者決定；自動收集不需要逐一標記，而涵蓋哪些互動、送出哪些欄位由 vendor 的規則決定、會隨 vendor 改版變動。vendor 改版不會通知網站，所以送出資料的盤點要定期重做；Meta Pixel 的 fbevents.js 版本可以在頁面的開發者工具 Console 輸入 fbq.version 讀出，但自動事件由每個 Pixel 的設定檔決定，設定檔或事件管理工具裡的設定改了，fbq.version 不會變，所以版本相同不代表送出的內容沒變，盤點仍要看實際送出的請求。

完整章節

Meta Pixel 自動加送的事件與它的欄位 → 用 Playwright 擷取追蹤碼請求的〈各次擷取的結果〉。以 data-track 屬性手動埋點的感測器設計，與它和自動收集的對照 → 前端感測器設計。設定檔指定的模組怎麼在網站沒呼叫時自己送事件 → Meta Pixel 與 Conversions API 的〈Meta Pixel 在瀏覽器裡做的事〉；同一類模組依 User-Agent 攔下事件的機制 → 用 Playwright 擷取追蹤碼請求的〈擷取方式〉。