用於事件分析的多租戶身分建模
產品和運營問題通常同時使用多個身分：人員、帳戶、工作區、會話、請求、裝置或匿名存取者。將這些值視為可互換的會導致漏斗膨脹、保留佇列被破壞以及資料暴露不安全。
在 SQL 中使用每個識別符號之前定義其粒度和所有權。
不同的身分級別
對不同的實體使用不同的欄位：
| 領域 | 含義 | 使用範例 |
|---|---|---|
account_id |
穩定的客戶或計費帳戶 | 收入、計劃和帳戶保留 |
workspace_id |
帳戶內的產品工作區 | 協作和工作區活動 |
user_id |
穩定的內部人員識別符號 | 使用者啟用和功能採用 |
anonymous_id |
預認證瀏覽器或裝置識別符號 | 登入到註冊歸因 |
session_id |
有界互動期 | 旅程和會話分析 |
request_id |
一次請求或處理嘗試 | 操作相關性 |
請勿將電子郵件地址輸入 user_id。首選內部假名識別符號，並將身分查詢保留在已擁有個人資料的系統中。
定義租戶邊界
每個多租戶事件都應包含授權和分析所需的租戶識別符號。選擇一個規範的帳戶級欄位並在各個服務中一致地使用它。如果事件屬於工作區，請同時包含 account_id 和 workspace_id，而不是過載一個欄位。
決定如何表示內部流量、測試租戶、刪除的租戶和帳戶合併。默默地將生產客戶與員工和自動化測試混合在一起的儀表板將產生誤導性的比率。
仔細連結匿名活動和經過身分驗證的活動
匿名存取者稍後可能成為經過身分驗證的使用者。僅在應用程式建立關係後才記錄顯式連結事件：
{
"event_name": "identity_linked",
"anonymous_id": "anon_7b2",
"user_id": "usr_42",
"account_id": "acct_18",
"link_reason": "registration_completed",
"identity_policy_version": "v2"
}
不要默默改寫歷史事件。保留連結時間和策略版本，以便查詢可以區分事件時已知的內容和後來的身分解析。在跨上下文連線識別符號之前，請檢查同意和隱私要求。
選擇正確的分析顆粒
計算帳戶數量以進行帳戶啟用和擴充套件。計算個人採用的使用者數量。計算會話參與度的不同會話。計算作業或 Webhook 結果的終端工作流程 ID。
說明度量定義中的粒度：
- “每週活躍帳戶”是指具有合格核心活動的獨特
account_id值； - “啟用使用者”是指達到啟用里程碑的不同
user_id值； - “請求失敗率”使用符合條件的請求事件，而不是不同的使用者。
處理生命週期變更
帳戶合併、使用者刪除、工作區轉移和成員資格更改需要明確的策略。當可審查性很重要時，保留不可變的事件時間識別符號，並且僅當問題要求當前所有權時才加入當前維度。
對於刪除請求，記錄哪些假名識別符號仍然是必要的，哪些可以不可逆地轉換，以及哪些事件必須刪除。關注 資料保留和刪除 和 敏感資料脫敏。
使用邊緣情況進行驗證
測試多個工作區中的一名使用者、一個帳戶中的多個使用者、匿名到身分驗證的轉換、帳戶合併、員工租戶和已刪除的使用者。確認啟用、保留和收入查詢將目標實體精確計數一次。