探索検索で作成されたコンテンツ

sdi-color-horizontal scaled

Adobe DTM への移行の計画

この記事では、DTM への移行の計画として考慮すべき項目と、実装を成功させるための関連するベストプラクティスについて説明します。

DTM 設定の計画

コンポーネントの概要

ここでは、DTM 設定の計画に関連する決定を準備するための基本的な DTM 会社の構造について説明します。

DTM では、会社は Web プロパティのグループです。

Web プロパティは、データを収集して、サイト上のタグ/スクリプトをデプロイするために設定されたツール、ルール、およびデータ要素のグループです。

Picture1

各 Web プロパティは、サイト上の特定のプロパティ設定を読み込むために必要な 1 つの埋め込みコードに関連付けられています。

ユーザーは、会社レベルで管理されますが、管理者ロールを除き、各プロパティで権限を与えることができます。管理者役割はグローバルであり、会社内のすべてのプロパティに対する完全な権限があります。

Picture2

ユーザーの役割について詳しくは、次の URL を参照してください。https://marketing.adobe.com/resources/help/ja_JP/dtm/groups.html

DTM 設定の計画

決定ポイント

基本的な DTM の会社構造を考慮して、DTM の設定を計画する際に関連する決定ポイントを検討してください。

どのくらいの数の会社が必要になりますか?

ほとんどの場合、会社は 1 つあればビジネスニーズに最適です。

複数の会社を持つ主な理由は、ユーザーおよび Web プロパティを完全に分離するためです。

このタイプの設定は、様々なビジネス区分によって実行される多数の Web エンティティを持つ大規模企業にとって最も一般的です。

Picture3

ドメインとサブドメインを Web プロパティに配布するにはどうすればよいですか?

Web プロパティは、ドメインを使用すると 1 対 1 または 1 対多のように設定できます。

ビジネスに最適なものを決定するには、次の変数のクロスドメインとの相違点を考慮してください。

  • データ収集メソッドとソース
  • デプロイされたツールとタグ
  • サイトコードの構造
  • DTM のユーザーワークフロー

ほとんどの場合、1 つのドメインにつき 1 つの Web プロパティを使用すると、上記の変数の 1 対多ではかなりの相違点があるため、ビジネスニーズが最適になります。

このタイプの設定は、「コピー」機能を使用してクロスドメイン定数を引き続き簡単に複製できるため、各ドメインのニーズに最も効果的に対応します。

Picture4

ただし、これらの変数は、1 つの Web プロパティ内に複数のドメインを持たせるほうが合理的によい可能性があるドメイン間で同じまたは類似している場合があります。このような場合、この設定では、プロパティ間の不要な重複を減らすことができます。

この同じ論理がサブドメインの配布に使用できます。

ユースケースの例

シナリオ - 自社のビジネス区分が複数のドメインを管理します。すべてのドメイン間に Analytics をデプロイしていますが、ドメインごとに独自のレポートスイートとトラッキングニーズがあります。

ソリューション - ドメインごとに 1 つのプロパティを使用します。

 

シナリオ - 自社のビジネス区分が複数のドメインを管理します。すべてのドメイン間に Analytics をデプロイしており、1 つのグローバルレポートスイートを使用してすべてのデータを収集します。サイトコード構造のバリエーションのため、ドメイン間のデータソースは非常に異なります。

ソリューション - ドメインごとに 1 つのプロパティを使用します。

 

シナリオ - 自社のビジネス区分が複数のドメインを管理します。すべてのドメイン間に Analytics をデプロイしており、グローバルレポートスイートとグローバルデータレイヤーを使用してすべてのデータを収集します。他のツールとタグはドメイン間でほとんど一貫性があり、同じユーザーに発行ワークフローを管理させることを計画しています。

ソリューション - すべてのドメインに 1 つのプロパティを使用します。

移行ベストプラクティス

最適な会社およびプロパティの配布を決定した後、DTM 移行を開始する際に、次のベストプラクティスを考慮してください。

 

プロセスワークフロー

既存のページコードを DTM に移行するための組織的なプロセスをデプロイすると、円滑な移行を実現することができます。

通常は、このプロセスを低レベルのステージング環境で開始し、ページごとまたはサイトセクションごとに基づいてコードを移行することをお勧めします。

これにより、実装の混乱のリスクを減らす既存のページコードを削除する前に、DTM 設定を完全に検査できます。

 

IT との作業

現在のプロセスおよびデプロイメントサイクルを決定するには、事前に IT チームと作業することが重要です。

これにより、埋め込みコードの適切かつタイムリーな配置と、効率的に移行したページコードの連携削除が可能になります。

 

ユーザーのワークフローとガバナンス

もう 1 つの重要な概念は、ユーザーのワークフローを確立することです。ユーザーの役割を慎重に割り当てると、DTM ワークフローにガバナンスが提供されます。

Picture5

これにより、すべての項目がチームの正しいメンバーによって完全に検査されてから実稼動環境にプッシュされます。

DTM への移行について詳しくは、次の URL を参照してください。https://marketing.adobe.com/resources/help/ja_JP/dtm/migration.html

次に 5 つのパートから構成されるシリーズの、はじめに:Adobe DTM への移行 - Adobe Analytics の詳説(英語)を参照してください。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー