プラン

ユーザーのエクスポート

この機能は、アカウントのアカウント管理権限と、すべてのプロファイルのユーザー管理権限が必要です。ファイルには、現在ログインしているユーザーがユーザー管理権限を持つプロファイルのユーザーとレガシーユーザー権限のみが含まれます。権限の強制がオンになっている場合、このボタンは表示されません。

ユーザーのエクスポート機能を使用すると、アカウントのユーザー、プロファイル、各プロファイルのレガシーユーザー権限を含むカンマ区切りの値（CSV）ファイルをダウンロードできます。これにより、ユーザーとその権限を監査し、プラットフォーム権限システムで権限グループを作成し、管理者ロールを割り当てることが容易になります。

1. クライアント側の管理メニューで、ユーザー管理をクリックします。テーブルには、アカウント上のユーザーの一覧とその一般的な権限が表示されます。
2. ユーザーのエクスポートをクリックします。
   • レガシー権限: 管理メニューで、ユーザー管理をクリックします。ユーザー管理ダイアログが表示されたら、ユーザーのエクスポートをクリックします。
   • プラットフォーム権限: 管理メニューで、権限管理をクリックし、次にユーザータブをクリックします。ユーザーテーブルが表示されたら、ユーザーのエクスポートをクリックします。

CSVファイルでは、権限の値をTRUEまたはFALSEでリストします。

以下のスクリーンショットは、ダウンロードしたCSVファイルをGoogleシートにインポートし、行1の微調整とTRUEとFALSEのエントリーを読みやすさのためにYとNに変更した例を示しています：

エクスポートされたデータにはManage Site Scansが表示されます。これはレガシー機能であり、移行の目的では必要ありません。

この例では、user3がUser列に3回表示されます。他のユーザーとは異なり、アカウント上のすべてのプロファイルで同じ権限を持つuser3は、Website A、Website B、Website Cのプロファイルで異なる権限を持っています。そのため、スプレッドシートの別の行にuser3のプロファイル権限が含まれています。

クライアント側とサーバー側のユーザーと権限の手動インベントリ

自動エクスポートを使用できない場合や、手動でインベントリを作成することを選択した場合、クライアント側の各ユーザーの権限を手動で収集する必要があります。

クライアント側

クライアント側の各ユーザーの権限をエクスポートするには、以下の手順を実行します：

1. クライアント側の管理メニューで、ユーザー管理をクリックします。テーブルには、アカウント上のユーザーの一覧とその一般的な権限が表示されます。
2. スプレッドシートを作成し、最初の列にユーザーとラベルを付けます。
3. スプレッドシートに、ユーザーリストを最初の列に追加します。
4. スプレッドシートで、2番目の列にプロファイルとラベルを付けます。
5. 最初のアカウントをクリックします。
6. ユーザー構成の編集/表示をクリックします。ダイアログボックスには、アカウントと各プロファイルのユーザーの権限（フル、部分、なし）が表示されます。
7. スプレッドシートに、この情報を含む3つの新しい列を作成し、後でアカウント管理とユーザー管理の管理者ロールを構成するときに使用する列名をメモします：
   • アカウント
   • プロファイル
   • JavaScriptコード
8. 閉じるをクリックします。
9. ユーザー権限の編集/表示をクリックします。ダイアログボックスには、アカウント、プロファイル、JavaScriptの権限が表示されます（この情報はすでに持っています）。
10. 次へをクリックします。
11. 現在割り当てられているプロファイルから選択を選択します。
12. ドロップダウンボックスから各プロファイルを選択し、次へをクリックします。ダイアログボックスには、各プロファイルのユーザーの権限が表示されます。
13. ユーザーがすべてのプロファイルで同じ権限を持っている場合は、スプレッドシートのプロファイル列にすべてを入力し、ユーザーの権限をメモします。ユーザーがプロファイルごとに異なる権限を持っている場合は、スプレッドシートのユーザーの行を複製して、各行が異なるプロファイルを表すようにし、プロファイル列にプロファイル名を入力し、以下のタイトルの列にその権限をメモします：
    • ユーザー管理
    • リソースロックの管理
    • Dev/Custom環境への公開
    • QA環境への公開
    • Prod環境への公開
    • タグテンプレートの管理
    • 既存のバージョンの保存
    • 新しいバージョンとして保存
    • Dev/Custom環境への昇格
    • QA環境への昇格
    • Prod環境への昇格
14. キャンセルをクリックします。
15. このプロセスを各ユーザーに対して繰り返します。

これで、クライアント側のユーザー権限がすべて揃いました。

サーバー側

サーバー側の各ユーザーの権限をエクスポートするには、以下の手順を実行します：

1. サーバー側の管理メニューで、ユーザー管理をクリックします。スプレッドシートにまだ存在しないサーバー側のユーザーがいる場合は、それを最初の列に追加します。
2. ユーザーアカウントをクリックします。
3. 次へをクリックします。ダイアログには、各プロファイルのユーザーの権限が表示されます。
4. ユーザーがすべてのプロファイルで同じ権限を持っている場合は、プロファイル列にすべてを入力し、スプレッドシートにユーザーの権限をメモします。ユーザーがプロファイルごとに異なる権限を持っている場合は、スプレッドシートのユーザーの行を複製して、各行が異なるプロファイルを表すようにし、プロファイル列にプロファイル名を入力し、適切な行に権限をメモします。
   • アクセスなし - プロファイルにアクセスできません。
   • リーダー - プロファイルへの読み取り専用アクセス。
   • エディター - プロファイルを編集し保存できますが、公開はできません。
   • パブリッシャー - エディターに加えて、プロファイルを保存し公開できます。また、すべてのサーバーサイドの製品と機能にフルアクセスがあります。
5. 閉じるをクリックします。
6. このプロセスを各ユーザーに対して繰り返します。

前述の例に基づいて、以下のスクリーンショットは、サーバーサイドのユーザーと権限で更新されたスプレッドシートを示しています：

この例では、user6、user7、user8はクライアント側には権限がなく、スプレッドシートに手動で追加する必要がありました。また、user7はサーバーサイドのプロファイルApp AとApp Bで異なる権限を持っているため、user7のプロファイル権限のためにスプレッドシートに別の行が作成されました。

これで、レガシー権限システムからクライアント側とサーバー側のプロファイルのすべてのユーザー権限を持つことができます。

スプレッドシートの監査

すべてのユーザーの権限がスプレッドシートにあるので、彼らが仕事を遂行するために必要なプロファイルへのアクセスが過剰または不足しているユーザーをチェックします。ユーザーは、プロファイルのリソースにアクセスするために、少なくとも1つの権限グループに所属している必要があります。彼らの実際のニーズを反映するようにスプレッドシートを更新します。

また、会社を退職したユーザーやアカウントへのアクセスが必要ないユーザーを削除することを忘れないでください。

個々のユーザーのニーズをスプレッドシートに追加

スプレッドシートに各ユーザーのプロファイル権限があるので、各ユーザーの最終的な製品とデータレベルのニーズをスプレッドシートに追加する必要があります：

• ユーザーが持つべきPIIデータへのアクセスレベル。
• 各ユーザーがアクセスできるべき製品と製品機能。
• 各ユーザーが各製品機能に対して持つべきアクセスレベル。

PIIデータのニーズ

PII権限は、誰がPIIデータを見ることができ、誰がPIIデータを識別する制限されたデータプロパティを編集できるかを制御します。PII権限はグループに1つだけ割り当てることができます。PII権限の3つのレベルは次のとおりです：

• No PII – ユーザーはPII属性を表示できますが、これらの属性の値を見ることはできません。PIIは、TraceやLive Eventsなど、表示される場所で隠されます。
• View – ユーザーはPII属性の値を表示できますが、PIIデータを編集または管理することはできません。
• Manage & View – ユーザーはPIIデータを表示、編集、管理することができます。

スプレッドシートに、ユーザーがアクセスなし、表示アクセス、または管理＆表示アクセスを持つべきかをメモします。

EAとEEAでは、PIIの許可はグループによって管理されていました。GAでは、PIIの許可管理がグループベースの管理からユーザーベースの管理に移行しました。EAとEEAでグループによって構成されたPIIの許可は、自動的にユーザーベースのPIIの許可に移行します。

製品と機能のニーズ

製品アクセス許可は、ユーザーがアクセスできるTealiumの製品と機能を指定します。

製品アクセス許可は機能許可に分けられ、グループに割り当てられた製品許可によって異なる場合があります。以下の表を参照してください。

表示 & 編集 または 表示、編集 & 削除 の許可を持つユーザーは、保存 の許可も持っています。

iQタグ管理

機能	利用可能な許可
JavaScript拡張機能	アクセスなし、表示、編集 & 削除
高度なJavaScript拡張機能 - Devへの昇格	アクセスなし、表示、編集 & 削除
高度なJavaScript拡張機能 - QAへの昇格	アクセスなし、表示、編集 & 削除
高度なJavaScript拡張機能 - Prodへの昇格	アクセスなし、表示、編集 & 削除
Dev/Customへの公開	アクセスなし、表示、編集 & 削除
QAへの公開	アクセスなし、表示、編集 & 削除
Prodへの公開	アクセスなし、表示、編集 & 削除
保存	アクセスなし、表示、編集 & 削除
公開構成	アクセスなし、表示、編集 & 削除
コード構成	アクセスなし、表示、編集 & 削除
リソースロック	アクセスなし、表示、編集 & 削除
クライアントサイドバージョン	アクセスなし、表示、表示 & 編集
タグテンプレート	アクセスなし、表示、表示 & 編集
タグ、拡張機能、ロードルール、データレイヤー	アクセスなし、表示、表示 & 編集、表示編集 & 削除

AudienceStream

機能	利用可能な許可
ダッシュボード	アクセスなし、表示
ディスカバリー/サイジング	アクセスなし、表示
オーディエンス	アクセスなし、表示、表示 & 編集、表示編集 & 削除
オーディエンスコネクタ	アクセスなし、表示、表示 & 編集、表示編集 & 削除
ビジター/訪問属性	アクセスなし、表示、表示 & 編集、表示編集 & 削除

EventStream

機能	利用可能な許可
データソース	アクセスなし、表示、表示 & 編集、表示編集 & 削除
イベント属性	アクセスなし、表示、表示 & 編集、表示編集 & 削除
イベントコネクタ	アクセスなし、表示、表示 & 編集、表示編集 & 削除
イベント仕様	アクセスなし、表示、表示 & 編集、表示編集 & 削除
ライブイベント	アクセスなし、表示、表示 & 編集、表示編集 & 削除
オムニチャネル	アクセスなし、表示、表示 & 編集、表示編集 & 削除

DataAccess

機能	利用可能な許可
アクセスキー	アクセスなし、表示
Tealium Insights*	アクセスなし、表示
EventStore Legacy	アクセスなし、表示
AudienceDB	アクセスなし、表示、表示 & 編集、表示編集 & 削除
EventDB	アクセスなし、表示、表示 & 編集、表示編集 & 削除
AudienceStore	アクセスなし、表示、表示 & 編集、表示編集 & 削除
EventStore	アクセスなし、表示、表示 & 編集、表示編集 & 削除

* Tealium Insightsの許可は、ユーザー管理者が Insights > ユーザー管理 ページを通じて構成できます。詳細については、Tealium Insightsについてを参照してください。

Predict

機能	利用可能な許可
すべての機能	アクセスなし、表示、表示 & 編集、表示編集 & 削除

Functions

機能	利用可能な許可
資格情報/認証、グローバル変数	アクセスなし、表示、表示 & 編集、表示編集 & 削除

サーバーサイドツール

機能	利用可能な許可
ルール管理	アクセスなし、表示、表示 & 編集、表示編集 & 削除
ビジター削除	アクセスなし、表示、表示 & 編集、表示編集 & 削除
ビジタールックアップ	アクセスなし、表示、表示 & 編集、表示編集 & 削除
ビジタープロファイルサンプラー	アクセスなし、表示

サーバーサイド（その他）

機能	利用可能な許可
ラベル	アクセスなし、表示、表示 & 編集、表示編集 & 削除
トレース	アクセスなし、表示
バージョン	アクセスなし、表示

横断的な機能許可の問題

機能や製品へのアクセスを無効にする際は慎重に考えてください。ユーザーの機能へのアクセスを無効にすると、そのユーザーはそれに依存する他の機能でもその機能にアクセスできなくなります。例えば：

• ユーザーのAudienceStreamオーディエンスへのアクセスを無効にすると、そのユーザーはAudienceStreamコネクタでアクションを起こすためのオーディエンスを選択できません。
• ユーザーのサーバーサイドラベルへのアクセスを無効にすると、ユーザーはサーバーサイドでラベルを見ることができません。彼らはラベルが付いているコネクタや他の機能にアクセスできますが、ラベル自体を見たり編集したりすることはできません。
• EventStreamとAudienceStreamは一部の機能を共有しています。例えば、ルールやラベルなどです。ユーザーがEventStreamだけにアクセス権を持っていて、EventStreamとAudienceStreamで共有されているルールを編集すると、AudienceStreamのルールも変更されます。

スプレッドシートの更新

スプレッドシートに各製品と機能の列を作成し、ユーザーが各項目でどのレベルのアクセスを持つべきかをマークします。

おめでとうございます。これで、スプレッドシートにすべてのユーザーの個々のニーズが記録されました。

次のステップは、ユーザーをグループにまとめることです。

組織情報の追加

すべての組織には独自の構造、ニーズ、ワークフローがあります。許可を組織のワークフローに合わせて構成することで、各人がその職務に適したアクセスを持ち、プライバシー規制によりデータへのアクセスがないことを確認できます。そのため、ユーザーや組織についていくつかの質問をすることで、彼らをグループに分けるのに役立ちます。

以下にいくつかの提案をします：

• 組織の異なる部分がこれらの製品を管理しているため、クライアントサイドとサーバーサイドのプロファイルに対して別々の許可グループを作りたいですか？
• 職責に基づいて許可グループを作成したいですか（開発者、QA、データマネージャー、エンジニア、コンプライアンスなど）？これにより、ユーザーを追加、移動、削除する際に、その職種に基づいて迅速に許可を割り当てることができます。
• プロファイルとユーザーが地理的なキャンペーンやサイトによって組織化されており、それぞれに異なるデータ保存とデータプライバシー法が適用されるため、地域ごとに許可グループを分けたいですか？
• 製品ごとに許可グループを分けたいですか（AudienceStream、EventStream、Customer Data Hubなど）？

Yesと答えた各項目について、スプレッドシートに別の列を追加し、その質問がユーザーの組織やワークフローとの関係にどのように影響するかについてその列にメモを追加します。

プロファイルの監査

主要なクライアントサイドプロファイルと主要なサーバーサイドプロファイルが1つずつしかない場合でも、ブランドと組織が複数の地域と責任構造に分かれている場合、このデータはアカウントに地域プロファイルを構成する将来のプロジェクトの一部として役立つ可能性があります。ただし、まずプラットフォームの許可システムで許可を構成し、テストすることをお勧めします。

ユーザーをグループに分ける

スプレッドシートにすべてのユーザーのニーズと組織との関係を記録したので、各列でユーザーを分類します。

これで、共通のニーズとアクセス権を持つユーザーをグループにまとめることができます：

• グループのユーザーがアクセスする必要があるプロファイル。
• 各プロファイルに対するグループメンバーのアクセスレベル。
• グループメンバーがクライアント側とサーバー側のプロファイルに対して公開権限を持つべきかどうか。サーバー側の公開権限を持つユーザーは、すべてのサーバー側の製品と機能に完全にアクセスできるため、どのグループにそれらの権限を付与するかは慎重に選ぶべきです。サーバー側のパブリッシャーのために、サーバー側の公開という専用のグループを作成することをお勧めします。
• 各グループがアクセスできるべき製品と製品の機能。
• 各グループが各製品の機能に対して持つべきアクセスレベル。
• ユーザーがPIIデータにアクセスできるべきかどうか。
• ユーザーがクライアント側、サーバー側、または両方でプロファイルを保存および/または公開できるべきかどうか。
  • 製品または機能に対する編集アクセスは、ユーザーがプロファイルに対して変更を保存する権限も付与します。
  • サーバー側の公開アクセスには、サーバー側の製品と機能への完全なアクセスが含まれます。

ユーザーを部門や職務機能による管理、地理的なグループ分けなど、組織の他のニーズに基づいてより小さなグループに分けることができます。

これらの最終的なユーザーグループが、作成する必要がある権限グループです。

管理者ロールの追加

グループの計画ができたら、次は管理者ロールの計画を立てることです。

スプレッドシートを見て、アカウント自体についていくつかの質問を自分自身に投げかけてみてください：

• 誰がアカウントへの完全なアクセス権を必要としていますか？
• 誰がアカウントのグループ内のユーザーとユーザーメンバーシップを管理していますか？
• 誰がアカウントの技術的な構成を管理していますか？
• 誰がアカウント上の個人識別情報（PII）データの権利を管理していますか？
• 誰がアカウントのプロファイルを管理していますか？

クライアント側のユーザー権限のインベントリからのAdminとProfilesの構成は、プラットフォームの権限システムでアカウントの管理者ロールを誰が得るべきかを決定するのに役立ちます：

• アカウント管理者 - このロールはアカウントへの完全なアクセス権を持っています（他のロールの権限を含む）。
• ユーザー管理者 - このロールは権限グループとユーザー権限を管理します。ユーザーの追加、編集、権限グループへの割り当てを担当する人は、このロールを持つべきです。
• 技術管理者 - このロールは、ファーストパーティドメインなどのアカウント構成機能を管理します。
• プライバシー管理者 - このロールはグループ内のPII権限レベルを管理します（ユーザー管理者ロールが必要）。データプライバシーとコンプライアンスを担当する人は、このロールの候補者となるべきです。
• プロファイル管理者 - このロールはプロファイルとライブラリへのアクセスを管理します。アカウント上でプロファイルを構築し、整理する人は、このロールを持つべきです。このロールにはプロファイルの編集や公開権限は含まれておらず、それらは権限グループ内の権利を通じて付与されます。

管理者ロールについての詳細は、管理者ロールを参照してください。

ユーザー管理者の管理者ロールは、移行プロセスに特に役立ちます。これらの人々は、ユーザーがプラットフォームの権限システムをテストするにつれて、権限グループを洗練させるのを助けることができます。

おめでとうございます。あなたは今、作成する必要がある権限グループと割り当てる必要がある管理者ロールを知っています。