事件追蹤計劃和治理
事件追蹤計劃是應用程式程式碼和使用遙測技術的人員之間的可審查合約。它解釋了一行的含義、事件存在的原因、允許哪些欄位、誰擁有更改以及如何驗證事件。如果沒有該合約，技術上有效的 JSON 有效負載仍然可能產生誤導性的價格、破損的漏斗、隱私風險或無人擁有的儀表板。
每個事件合約使用一行：
| 領域 | 範例 |
|---|---|
| 活動名稱 | checkout_completed |
| 穀物 | 所有內部嘗試後的一次邏輯檢查 |
| 決定 | 識別終端故障較多的結帳步驟 |
| 業主 | 支付工程 |
| 觸發 | 成功或最終失敗 |
| 必填欄位 | event_id、status、checkout_step、duration_ms、timestamp_utc |
| 可選欄位 | account_id、plan、release、error_type |
| 禁止內容 | 付款詳細資訊、電子郵件、請求正文、原始錯誤訊息 |
| 保留率 | 產品認可的操作視窗 |
| 架構版本 | 1 |
| 消費者 | 檢查可靠性儀表板和終端故障警示 |
| 驗證 | 綜合成功、失敗、超時、重試和重複賽程 |
在欄位之前定義含義
從決定和穀物開始。 “結帳事件”含糊不清。 “在所有內部嘗試之後進行一次邏輯檢查”告訴審閱者 COUNT(*) 代表什麼以及重試是否應該建立額外的行。
寫出最終結果和排除情況。如果無法觀察到放棄的結帳，請說明該限制。如果在非同步履行步驟之前發出成功事件，請勿將其標記為 checkout_completed。
對每個領域進行分類
對於每個欄位，記錄：
- 型別和單位
- 必需、可選或有條件必需的狀態
- 允許值或最大長度
- 真理的來源
- 無論是個人的、假名的、敏感的還是不受限制的
- 目的：過濾、分組、連線、計算、關聯或除錯
- 當值不可用時的行為
對 status、error_type、feature 和其他分組維度使用受控分類法。僅當批准的調查或聯接使用高基數識別符號時才保留它們。禁止任意巢狀有效負載和無界字串。
記錄下遊依賴關係
列出取決於事件的已儲存查詢、儀表板、警示、匯出、實驗和報告。在這些使用者被更新或有意版本控制之前，欄位重新命名是不完整的。
對於每個操作查詢，記錄其分母、時區、遲到政策、重試處理、最小數量和預期固定結果。該計劃應連結到查詢或相關的 SQL配方，而不是重述未記錄的指標名稱。
在合約變更時審查變更
新增可選欄位通常比更改現有含義更安全。當型別、單位、粒度或類別含義發生變化時，使用新的欄位或架構版本。推出期間：
- 更新追蹤計劃並獲得所需的審查。
- 新增或更新確定性裝置。
- 部署具有向後相容欄位的生產者。
- 檢查架構和空率。
- 更新消費者。
- 僅在歷史和部署視窗允許後才刪除相容性邏輯。
在準備好每個執行時並記錄回退計劃之前，切勿強制執行新引入的設定值。
指定操作節奏
按計劃和事件發生後審查關鍵計劃。查詢未使用的欄位、無主儀表板、類別爆炸、空值率上升、意外的模式版本以及不再具有合理用途的識別符號。刪除或縮短不再帶來成本和風險的資料保留時間。