イベント分析のためのマルチテナント ID モデリング

製品や運用に関する質問では、人、アカウント、ワークスペース、セッション、リクエスト、デバイス、匿名の訪問者など、複数の ID を同時に使用することがよくあります。これらの値を交換可能なものとして扱うと、ファネルの肥大化、保持コホートの崩壊、安全でないデータの露出が生じます。

SQL で使用する前に、各識別子の粒度と所有権を定義します。

個別の ID レベル

個別のエンティティには個別のフィールドを使用します。

メールアドレスは入れないでください user_id。内部の仮名識別子を優先し、個人データを既に所有しているシステム内で ID 検索を維持します。

テナント境界を定義する

すべてのマルチテナント イベントには、承認と分析に必要なテナント識別子が含まれている必要があります。正規のアカウント レベル フィールドを 1 つ選択し、それをサービス間で一貫して使用します。イベントがワークスペースに属している場合は、両方を含めます account_id そして workspace_id 1 つのフィールドをオーバーロードするのではなく。

内部トラフィック、テナントのテスト、削除されたテナント、アカウントの結合をどのように表現するかを決定します。実稼働顧客と従業員および自動テストを黙って混合するダッシュボードでは、誤解を招くレートが生成されます。

匿名アクティビティと認証されたアクティビティを慎重にリンクする

匿名の訪問者が後で認証されたユーザーになる可能性があります。明示的なリンク イベントは、アプリケーションが関係を確立した後にのみ記録します。

{
  "event_name": "identity_linked",
  "anonymous_id": "anon_7b2",
  "user_id": "usr_42",
  "account_id": "acct_18",
  "link_reason": "registration_completed",
  "identity_policy_version": "v2"
}

歴史上の出来事を黙って書き換えないでください。リンク時間とポリシー バージョンを保持しておくと、イベント時にわかっていたこととその後の ID 解決をクエリで区別できるようになります。コンテキスト間で識別子を接続する前に、同意とプライバシーの要件を確認してください。

正しい分析グレインを選択してください

アカウントのアクティブ化と拡張のためにアカウントをカウントします。個別に採用するためにユーザーをカウントします。セッションエンゲージメントのために個別のセッションをカウントします。ジョブまたは Webhook 結果のターミナル ワークフロー ID をカウントします。

メトリクスの定義で粒度を指定します。

• 「毎週アクティブなアカウント」とは、個別のことを意味します account_id 適格なコアイベントの値。
• 「アクティブ化されたユーザー」とは、個別のユーザーを意味します user_id アクティベーションマイルストーンに到達した値。
• 「リクエスト失敗率」は、個別のユーザーではなく、対象となるリクエスト イベントを使用します。

の じょうご そして コホート維持率 ガイドでは、アイデンティティの選択により分母がどのように変化するかについて説明します。

ライフサイクルの変更を処理する

アカウントの結合、ユーザーの削除、ワークスペースの転送、メンバーシップの変更には明示的なポリシーが必要です。監査可能性が重要な場合は不変のイベント時識別子を保持し、質問で現在の所有権が求められる場合にのみ現在のディメンションに結合します。

削除リクエストの場合は、どの仮名識別子が引き続き必要か、どの識別子は不可逆的に変換できるか、どのイベントを削除する必要があるかを文書化します。フォローする データの保持と削除 そして 機密データの編集.

エッジケースで検証する

複数のワークスペース内の 1 人のユーザー、1 つのアカウント内の複数のユーザー、匿名から認証への移行、アカウントの結合、従業員テナント、および削除されたユーザーをテストします。アクティブ化、保持、および収益のクエリで対象のエンティティが 1 回だけカウントされていることを確認します。