# メンバーと権限管理
通常、1 つのプロジェクト内で、異なる機能の役割のメンバーが参加して、データ分析価値の最大化を実現する必要がある。プロジェクト管理者はメンバーをプロジェクトに追加し、柔軟でカスタマイズされた機能とデータ権限を割り当てて、メンバーの TA での旅を適切に管理できます。
TA は【プロジェクトロール】でメンバーのプロジェクトでの機能権限を制御し、【データ権限】でメンバーのプロジェクトでのデータ権限を制御する。
この章には、主に次のものが含まれます。
# 一、プロジェクトメンバー管理
# 1.1 メンバーの追加
プロジェクト管理者またはオーバーチューブは[プロジェクト管理]に入り、左側のナビゲーションから[メンバー管理]を選択して、メンバー管理ページに入ります。
プロジェクトメンバーを追加するには、次の 3 つの方法があります
① 新規メンバーの作成
- アカウント名は 50 文字以下で、数字、大文字と小文字、上下線、および.@()などの特殊文字
② 既存メンバーの追加
- 追加するメンバーがシステム内の他のプロジェクトに既に存在する場合は、[既存のメンバーを追加]を選択します。システムに保存されているアカウントから追加するメンバーアカウントを選択し、プロジェクトの役割とデータ権限を割り当てた後、[OK]をクリックして追加
③ メンバーのインポート
- システム内の他のプロジェクトからメンバーを一括インポートすると、プロジェクト下のメンバーとロールが同時にインポートされ
追加が完了すると、メンバーはログインしてプロジェクトを表示できます。
# 1.2 メンバーグループの作成
TA の日常的な使用では、かんばん共有などの操作を行う場合、メンバーごとに共有すると、複数のかんばんに共有を設定するのは面倒な作業になり、プロジェクト内にメンバーが追加された場合、追加メンバーのためにかんばんの共有状態を絶えず変更する必要がある。
メンバーグループはこのようなシーンの問題を解決する。同じ機能のメンバーを製品グループ、運営グループなどのメンバーグループに追加することができ、グループ内のメンバー向けに迅速に共有を作成できます。プロジェクトにメンバーを追加する場合は、メンバーを作成したメンバーグループに追加するだけで、メンバーグループに共有されているプロジェクト資産を表示できます。
- 1 人のメンバーは複数のメンバーグループ
- メンバーグループはプロジェクトでのみ作成でき、システムレベルのメンバーグループ
- メンバーグループのプロジェクト作成上限は 50 個
作成が完了したら、カンバンを共有するときに、[メンバーグループで共有を追加]を選択します。共有すると、メンバーグループのメンバーはカンバンを見ることができます。
# 1.3 管理プロジェクト内のメンバー
# 1.3.1 システム管理におけるメンバー管理
TA オーバーチューブは[システム管理]→[権限管理]に入り、システム内のすべてのメンバー、メンバーが所属する項目などの情報を見て、管理操作を行うことができる。メンバープロジェクトの詳細、パスワードのリセット、メンバーの凍結、メンバー操作の削除が含まれます。
- メンバープロジェクトの詳細:メンバーが所属するプロジェクト、プロジェクトの下の役割とデータ権限情報
- パスワードリセット:パスワードを忘れたメンバーにログインパスワード
- メンバーの凍結:メンバーのアクセスを一時停止する必要がある場合に使用します。凍結後、メンバーは TA システムにログインできません。凍結したメンバーを解凍でき
- メンバーの削除:メンバーをシステムから削除すると、メンバーがすべてのプロジェクトで作成したプロジェクト資産
注意
システムでメンバーを削除すると、そのメンバーの下のすべての資産がクリアされます。プロジェクト資産を移管するには、メンバーのプロジェクトに行き、[プロジェクト管理]で資産移管先を選択し、メンバーを削除します。
# 1.3.2 プロジェクト管理におけるメンバー管理
TA オーバーチューブまたはプロジェクト管理者は[プロジェクト管理]→[メンバー管理]に入り、プロジェクト内のすべてのメンバーと権限情報を確認し、メンバー管理操作を実行できます。
| キャラクター | 操作 |
|---|---|
| TAスーパーチューブ | メンバーの表示名、プロジェクトの権限を変更し、メンバーのパスワードをリセットし、メンバーをプロジェクトから削除 |
| プロジェクト管理者 | 管理者以下のメンバーのプロジェクトロールとデータ権限を変更し、管理者以下のメンバーをプロジェクトから削除 |
ヒント
メンバーを削除する場合、プロジェクトのデータが失われないように、メンバーの資産をプロジェクトの他のメンバーに引き渡してから削除します。
# 二、プロジェクトの役割管理
役割は[機能操作権限]の集合で、機能操作権限はメンバーが使用できる TA 機能モジュールを制御する。例えば「TA オーバーチューブ」の役割だけが[システム管理]の機能にアクセスできる「TA オーバーチューブ」とプロジェクト「管理者」だけが[プロジェクト管理]機能モジュールの構成を行うことができる。
TA は、オーバーチューブ、管理者、アナリスト、一般メンバーの 4 つの役割タイプをプリセットし、ユーザーが使用状況に応じて役割をカスタマイズし、システムユーザーに適切な機能権限を割り当てることをサポートします。
1 人のユーザーは単一のプロジェクトで 1 人の役割しか対応できない。
# 2.1 プリセットキャラクター
TA システムデフォルトプリセットハイパーチューブ、管理者、アナリスト、一般メンバーの 4 種類の役割タイプ:
| キャラクター | キャラクター説明 |
|---|---|
| TAスーパーチューブ | すべての機能権限を持つ |
| 管理者 | プロジェクトレベルの全機能権限を持つ |
| アナリスト | プロジェクトの基礎モデル分析、看板使用などの機能を持つ権限 |
| 一般メンバー | かんばんなどの機能のみの表示と使用権限 |
各プリセットロールの機能の詳細は、オーバーチューブと管理者メンバーは[システム管理]または[プロジェクト管理]でロール名をクリックして表示できます。
# 2.2 カスタムキャラクター
TA オーバーチューブは、[システム管理]→[権限管理]→[システムロール管理]でシステムレベルのロールを作成することができます。
プロジェクト管理者または TA オーバーチューブは、[プロジェクト管理]→[ロール管理]でプロジェクトレベルのロールを作成できます。
システムレベルのロール作成上限数は 20、プロジェクトごとのプロジェクトレベルのロール作成上限数は 30。
# 2.2.1 作成キャラクター
[ロールの作成]をクリックし、[ロールの作成]ページに移動して、[アナリスト]または[一般メンバー]に基づいてロールをカスタマイズする]を選択します
アナリストベース:アナリストのデフォルト権限に基づいて、役割にグループ/ラベルの作成、警告管理、埋め込みポイント管理などの高次機能の使用権限
一般メンバーに基づく:一般メンバーのデフォルト権限に基づいて、役割分析モデルの使用やカンバンの新設/編集などの機能権限
作成が完了すると、プロジェクトにメンバーを追加するときにメンバーにロールを割り当てることができます。
# 2.2.2 マネージメントの役割
[ロール管理]ページの左側のロールリストで、システムロールやプロジェクト内ロールなど、現在のプロジェクトで使用できるすべてのロールを確認できます
- システムロール:システムプリセットロールとオーバーチューブがシステム管理で作成したシステムカスタムロール
- プロジェクト内ロール:プロジェクトの下で作成されたロール
マウスをプロジェクト内のロール名に移動し、右側の編集エントリをクリックして、ロールの編集またはロールの削除を選択します
- 作成したカスタムロールを削除すると、そのロールの下にあるすべてのユーザーが、ロールベースのシステムプリセットロール
# 三、データ権限管理
データ権限メンバーがプロジェクトでアクセスできるデータを制御し、アナリストや一般メンバー、その他のカスタムロールに異なるデータ権限を割り当てることができます。
データ権限の構成には、次の 3 つの部分があります
- 表示設定:イベント、イベントプロパティ、またはユーザープロパティを表示するかどうか
- データ範囲:属性ルールに基づいて使用可能なデータ範囲をフィルタリングし、フィルタリング条件を満たすデータのみ
- データ脱感作:イベントやユーザーリスト、ユーザー行動シーケンスにドリルダウンした敏感な属性を脱感作展示
# 3.1 データ作成権限
(1)可視設定
可視イベント、イベントプロパティ、またはユーザープロパティを設定できます。選択したイベントまたはプロパティのみが、分析で分析結果を使用または表示できます
- 個人がクエリを開始し、分析するイベントまたはプロパティ
- 他の人が共有しているクエリが正常に表示されるかどうか(クエリが不可視のイベントや属性を使用している場合、表示権限がないことがプロンプトされます)
設定バーの左側に、新しいイベントまたはプロパティがデフォルトで表示されるかどうかを設定します。デフォルトは「新しいイベント(または属性)がデフォルトで表示される」、つまり表示権限を設定した後に入庫した新しいイベントまたは属性にデフォルトで表示権限がある。
新しいイベントまたはプロパティの可視性を制御する必要がある場合は、この状態をオフにします。閉じると、このデータ権限の下にあるユーザーは、プロジェクト内の新しいイベントや属性をデフォルトで使用できなくなります。
（2）データ範囲
イベント属性またはユーザー属性に基づいて、メンバーがプロジェクトでアクセスできるデータ範囲を制限することができます。設定後、メンバーは次のようなフィルター条件を満たすデータ範囲にのみアクセスできます
- 個人がクエリを開始し、結果のデータ範囲を
- 他の人が共有するクエリを表示し、結果のデータ範囲を
設定プロパティに応じて、データ範囲の有効化ルールは次のとおりです
| フィルターのプロパティ | データ範囲 | 例 |
|---|---|---|
| イベントプロパティ | フィルター条件を満たすイベントデータのみにアクセスできます | フィルタイベント属性[サーバID=1]のように、サーバIDが1のイベントデータにしかアクセス |
| ユーザープロパティ | フィルタリング条件を満たすユーザーとそのイベントデータのみ | ユーザー属性[ソースチャネル=Huawei Application Mall]を選別すると、Huawei Application Mallからのユーザーとこの部分のユーザーが生成したイベントデータ |
データ範囲を設定すると、同じカンバンやレポートは、異なるデータ権限のメンバーに対して、データ範囲によって異なる計算結果を示す。プロジェクト内のメンバーがデータ計算口径を明確に知ることを保証するために、「個人センター」→「プロジェクト権限」でアカウントのデータ権限と機能権限の配置を見ることができる。
（3）データ脱感作
感度を下げる必要があるイベント属性とユーザー属性フィールドを選択できます。脱感作フィールドは、ドリルダウンリスト(イベントリストとユーザーリストを含む)、ユーザーの行動シーケンスなど、詳細情報にのみ作用する。設定された減感フィールドは、特殊文字(*)で無効化処理される。
作成が完了すると、[メンバー管理]で管理者以下のメンバーに適切なデータ権限を割り当てることができます。
# 3.2 データ権限の管理
作成が完了すると、プロジェクトで作成されたデータ権限情報を[データ権限]リストに表示できます。
- マウスで「データコンテンツ」バーに移動し、データ権限の設定内容の概要
- 作成したデータ権限を編集、名前を付けて保存、削除できます。削除時に、メンバーがデータパーミッションに属している場合は、メンバーを別のデータパーミッション
# 3.3 データ範囲の応用説明
分析モデルでは、メンバーは構成されたデータ権限に従ってデータを使用するか、計算結果を表示します。以下の機能モジュールでは、属性フィルタリングによる[データ範囲]制限の役割規則が異なります。
（1）ラベル
TA タグはユーザーの行動データを使用し、柔軟な構成でユーザーの特徴を探索します。作成したラベルは、分析モデルで再度選別またはグループ分析することができる。
ラベルの異なるメンバーへの可用性を保証するために、ほとんどの場面でユーザーの完全な行動データからユーザーのラベルの特徴を計算する必要があることを考慮する。一部のデータ権限を持つメンバーがラベルを作成する場合、作成時に[すべてのデータ]でラベル結果を計算します。しかし、一部のデータ権限を持つメンバーがラベルリストに入ってラベルの詳細を見ると、データ権限を持つ一部のユーザーのラベルの詳細しか見ることができない。
- 例:
メンバー a のプロジェクト A でのデータ権限は「ソースチャネルが華為応用商城のユーザーデータにしかアクセスできない」で、メンバー a がラベルを作成するデータ権限を持っていれば、メンバー a がラベルを作成するとき、全量のデータからラベル値を計算するが、メンバー a はラベルの明細を見たり、看板でラベルデータを見たりするとき、ソースチャネルが華為応用商城のユーザーに対応するラベルデータと明細しか見ることができない。
TIP
結果グループを除く他のユーザーグループ(条件グループ、ID グループ)の権限論理はユーザーラベルと
（2）早期警告
警報配置では、作成者は指標表現の特徴に基づいて警報トリガールールを作成する必要があるため、警報データの計算範囲はユーザーが分析モデルでデータ範囲を照会して、作成者が適切な警報ルールを設定できるようにする必要があるまた、プロジェクトの下で作成されたすべての警報は警報管理モジュールで統一的に維持され、プロジェクトの下で他人が作成した警報と警報条件を見ることができる。つまり、異なるメンバーの警告条件に対する理解が一致していることを保証する必要がある。
そのため、一部のデータ権限を持つメンバーが警告を作成した場合、自動的にデータ範囲条件に持ち込まれ、データ計算範囲の一貫性と異なるメンバーの警告トリガー条件に対する認識の統一を保証する。
（3）SQL クエリ
一般的に、SQL クエリの計算ロジックはイベント分析などの他の分析モデルと同じで、作成者はデータ権限を持つフィールドに基づいて SQL レポートのみを作成でき、レポートビューアーは自分のデータ権限に基づいて SQL レポートの計算結果にアクセスします。
プロジェクト間のクエリでレポートを保存する場合、ビューアーがクエリに関連するすべてのプロジェクトのプロジェクト権限を持っている必要があるかどうかを設定できます。オプションで閉じる。オン/オフ時のアクセス許可の変更例:
あるプロジェクト間クエリレポートがプロジェクト A とプロジェクト B に関係している場合、共有メンバー a はプロジェクト A のプロジェクト権限しか持っていない(つまり、メンバー a のアカウントはプロジェクト B に参加していない)。「クエリに関連するすべてのプロジェクト権限が必要」をオンにすると、メンバー a はレポートを見る権限がありませんこのオプションをオフにすると、メンバー a はレポートを見ることができ、メンバー a はプロジェクト B に属していないため、データ権限の構成を取得できず、デフォルトでプロジェクト B の「すべてのデータ」でデータ結果を計算して表示します。
# 3.4 ベストプラクティス
シナリオ 1:可視設定
ユーザー属性にコスト、属性などのフィールドが報告されている場合、プロジェクトのメンバーにはその属性を表示する権限がありません。データ権限を作成でき、可視設定でこの部分属性を不可視に設定し、作成したデータ権限をこのメンバーに指定すればよい。
シナリオ 2:データ範囲
複数の第三者によるゲーム配信など、インターモーダル輸送に関わる業務については、チャネル A の発行者を希望する場合は、チャネル A の下のユーザーデータのみを見ることができる。データの分離は、データパーミッションを作成し、フィルタリング（ソースチャネル=A）などのユーザーフィルタリングを設定し、パブリッシャーメンバーにデータパーミッションを指定することで実現できます。
シナリオ 3:データ範囲
に対して、管理者はデータ使用権限を徐々に開放したい。例えば、最近の 30 日間のデータ使用権限を開放したいだけで、イベントフィルタリングを設定できます(イベント時間は現在の日付に対して-30 日から 0 日の間)。データ照会範囲の制御を実現できます。
