Show Menu
トピック×

開始時のベストプラクティス

Adobe Dynamic Tag Management(DTM)を初めて使用する場合、DTMへの移行の準備やDTMのブラッシングの準備をする前に、このガイドを参考にしてください。
最終更新日: 2017年1月31日
Dynamic Tag Management には、マーケターによる迅速で手軽なタグ管理を実現する機能と、複数のデジタルマーケティングシステムを横断的にサポートする革新的なデータ収集および配布ツールが備わっています。また、変化の激しい今日のデジタル市場での発展を追求する会社に対して、ユーザー固有のコンテンツを迅速に配信し、卓越した俊敏性を提供します。
このベストプラクティスガイドに加えて、Dynamic Tag Managementを最大限に活用するために次のリソースを利用できます。
リソース 詳細
Dynamic Tag Management 製品ドキュメント
Dynamic Tag Managementの使用方法に関する詳しい情報と手順を説明します。
Dynamic Tag Managementを使用する開始方法に関する情報です。

初回ユーザーの基本事項

Dynamic Tag Management(DTM)ユーザーインターフェイスの概要を説明します。
このコンテンツは、Search Discovery と連携して構築されました。

ダッシュボード

ナビゲーション: ホーム/ダッシュボード
DTMにログインした後の最初のページはダッシュボードです。 ダッシュボードには、アクセス権を持つすべての会社のリストが含まれます。

会社の概要

ナビゲーション: ホーム/ダッシュボード/会社の概要
ダッシュボードから会社をクリックすると、会社の概要ページに移動します。
1つの会社のみにアクセスできる場合は、ログイン時にダッシュボードではなく、会社の概要ページに誘導されます。
DTMでは、会社はWebプロパティの集まりです。 Webプロパティは、ツール、ルールおよびデータ要素の集まりです。
会社内のすべてのWebプロパティは、会社の概要ページからアクセスします。
管理者レベルのユーザーは、「プロパティ」をクリックして、会社の概要ページから新しいWebプロパティを追加追加できます。 Webプロパティを設定する際に必要なフィールドは、「名前」と「URL」のみです。これは、必要に応じて後で変更できます。
管理者レベルのユーザーは、会社の概要ページの「ユーザーとグループ」タブから、ユーザーの管理とプロビジョニングを行うこともできます。

プロパティの概要

ナビゲーション: 会社の概要/プロパティの概要
会社の概要ページで任意のプロパティをクリックすると、プロパティの概要ページに移動します。
プロパティの概要ページでは、プロパティ設定の概要を簡単に示し、主要なプロパティコンポーネントへのゲートウェイとして機能します。 ツール、ルール、データ要素、発行ワークフロー、およびプロパティ埋め込みコード。
ナビゲーション: プロパティの概要/インストールされているツール
DTMツールは、ソリューションをサイトに迅速にデプロイできる組み込み統合です。
現在、Google AnalyticsおよびNielsenと同様に、アドビソリューション用のDTMオファーツール統合が行われています。 これらの統合はそれぞれ、特定のソリューションの設定と導入を容易にするように独自に設計されています。
ネイティブ統合を行っていないサードパーティのツールまたはタグは、
JavaScript /サードパーティタグの節を以下に説明します。

ルール

ナビゲーション: プロパティの概要/ルール
プロパティの概要ページで「ルール」タブをクリックすると、プロパティルールが表示されます。
DTMのルールは、ツール、タグ、スクリプト、HTMLを条件付きで実行するために使用されます。
タイプに関係なく、DTMのルールには2つの主なコンポーネントがあります。 条件とトリガー。 条件はルールが起動するシナリオを示し、トリガーはルールが起動したときに実行される項目を示します。
DTMには、次の3つのタイプのルールがあります。
  • イベントベース: ​イベントベースのルールはインタラクション主導です。例えば、ユーザーがいつ特定のボタンをクリックしたかを追跡する場合、イベントベースのルールを使用します。
  • ページ型: ​ページ型ルールは、ページ型ルールに紐付けられます。例えば、サイトで特定のページを読み込む際に特定のコードブロックを追加する場合は、ページ型ルールを使用します。
  • ダイレクト型: ​ダイレクト型ルールは、DTM が DOM でイベントを検出できない場合に使用されます。例えば、DOM で検出できない AJAX イベントを追跡する場合は、ダイレクト呼び出しルールを使用します。
ルールのタイプに関係なく、条件が満たされた場合にトリガーが実行されます。
すべてのルールタイプには、JavaScript /サードパーティタグモーダルを使用して、サードパーティベンダータグやその他のカスタムJavaScriptまたはHTMLをトリガーするオプションがあります。
ツールがプロパティに追加された場合、ルール内で他のトリガモデルが有効になります。 例えば、プロパティにAdobe AnalyticsツールとGoogle Universal Analyticsツールが含まれる場合、プロパティルールにはこれらのツールのオプションのトリガーモデルが含まれます。
各ツールモーダルオファーを使用すると、特定のツールのトリガーを簡単にカスタマイズできます。

データ要素

ナビゲーション: プロパティの概要/ルール/データ要素
「ルール」タブ内の「データ要素」タブをクリックすると、データ要素の概要ページが表示されます。
データ要素は、DTMでデータマッピングを作成するために使用されます。 共通のデータポイントをデータ要素として定義すると、これらのデータポイントをDTMのルールやツール内で簡単に取り込んで利用できます。

ワークフロー

DTMの重要な概念は、ステージング用ライブラリと実稼働用ライブラリの両方を持つ単一のWebプロパティの考え方です。
ステージング用ライブラリには、Webプロパティで設定されたすべてのルール、ツールおよびデータ要素が含まれています。 実稼働用ライブラリには、承認され発行されたルール、ツールおよびデータ要素のみが含まれています。
ナビゲーション: プロパティの概要/「承認」タブ
プロパティ内でルール、ツールまたはデータ要素を追加または変更すると、承認が自動的に生成されます。
ナビゲーション: プロパティの概要/「履歴」タブ
承認されたアイテムは、「履歴」タブの未発行の変更キュー0で使用可能になります。 項目が公開されると、実稼働用ライブラリで項目を使用できるようになります。
ライブラリと関連ワークフローが分離され、実稼働に影響を与えることなく、ステージングでのテストをより効果的に行うことができます。

インストール

ナビゲーション: プロパティの概要/「埋め込み」タブ
「埋め込み」タブをクリックすると、DTMのインストールページが表示されます。
このタブには、使用可能な各種のライブラリホスティングオプションが含まれています。 デフォルトでは、このプロパティはAkamaiホスティングを利用します。 この方法は、通常、ほとんどの組織で使用できます。 ただし、必要に応じてDTMライブラリの提供を制御するには、2つの自己ホスティングオプションが必要です。
「埋め込み」タブの「ヘッダーコード」セクションを展開すると、そのプロパティのステージングおよび実稼動用の埋め込みコードが表示されます。
ステージング用と実稼動用の埋め込みコードが1つあることに注意してください。 上述のステージングライブラリと実稼働ライブラリをDTMで区別する方法を次に示します。 ステージング用埋め込みコードがインストールされると、ステージング用ライブラリが読み込まれます。 実稼働用の埋め込みコードがインストールされると、実稼働用ライブラリが読み込まれます。
ヘッダーおよびフッターの埋め込みコードがサイトに適切にインストールされると、関連付けられたDTMライブラリが各ページの読み込み時に自動的に読み込まれます。
WebコンソールでDTM Switchプラグインをテストします。 これにより、DTMがページ上で何を実行しているかを把握し、ステージング用ライブラリにローカルに切り替えて、より効果的なテストを行うことができます。 詳しくは、 Dynamic Tag Management製品ドキュメントの「Search Discoveryプラグイン 」を参照してください **。

DTMの技術アーキテクチャとホスティング

Dynamic Tag Management(DTM)の技術的アーキテクチャとそのホスティングオプションに関する情報です。
このコンテンツは、Search Discovery と連携して構築されました。
このセクションでは、以下について説明します。

アーキテクチャ

DTM技術アーキテクチャの主なコンポーネントは、Web管理アプリケーション、ステージングおよび実稼働用のJavaScriptライブラリ、埋め込みコードです。
Web管理アプリケーションは、ログインしてDTM実装を管理するためのオンラインインターフェイスです。 ここでは、ツール、ルール、データ要素を作成および設定し、これらの設定のサイトへの導入を管理します。
DTMのWebプロパティは、ツール、ルール、データ要素の設定を集めたものです。
各Webプロパティは、1つのステージング用JavaScriptライブラリと1つの実稼働用JavaScriptライブラリに関連付けられています。 これらのライブラリはWebアプリケーションによって生成され、そのWebプロパティに固有の設定のセットが含まれます。
ステージング用JavaScriptライブラリには、Webプロパティに最新のツール、ルール、データ要素の設定がすべて含まれています。 このライブラリはプロパティの変更に伴って自動的に更新され、ステージング環境でのテストや、DTM Switchプラグインを使用したローカルの実稼働テストを目的としています。
DTM Switchプラグインについて詳しくは、Dynamic Tag Management製品ドキュメントの Search Discoveryプラグイン (英語のみ)を参照してください。
実稼働用のJavaScriptライブラリには、Webプロパティワークフローを通じて承認および発行されたツール、ルールおよびデータ要素設定のみが含まれています。 このライブラリは、実稼働環境向けです。

ホスティング

以下の方法で、ステージング用と実稼働用のJavaScriptライブラリをホストできます。
  • Akamai のサーバーでホストされる Akamai ​ライブラリを介した外部ホスティング
  • SFTP または​ ライブラリダウンロード ​経由での自己ホスト:サーバーでホストされるライブラリ
ホスティングオプションの選択は、ビジネスで必要となる決定です。 この判断を容易にするために、次のオプションの比較と使用例を確認してください。
メリット デメリット
Akamai
外部ホスティング
  • 標準的な導入方法
  • 設定は不要
  • ITへの依存度が最小
  • ファイルの自動更新
  • グローバルな分散Akamaiネットワークを介した信頼性とスピーディなファイル配信
  • ファイル配信に対する制御が不足している
  • サードパーティインフラストラクチャへの依存(Akamaiが使用できない場合、ライブラリも使用できる)
SFTP
自己ホスティング
  • ファイル配信の完全な制御
  • より安全なオプション: SSHファイル転送
  • ファイルの自動更新
  • 事前構成が必要です
  • ITへの依存度の向上
ライブラリのダウンロード
自己ホスティング
  • ファイル配信の完全な制御
  • 最も安全なホスティングオプション: AES 256バンドルの暗号化
  • 事前構成が必要です
  • ITへの依存度の向上
  • ファイルの自動更新に必要な追加設定
使用例
シナリオ
ソリューション
IT部門にはできるだけ関与しないで、独自のサイトインフラストラクチャの外部で信頼性の高いファイルホスティング方法が必要です。
すべての環境でAkamaiホスティングを利用できます。
実稼働環境のファイル配信を完全に制御したい。 しかし、ステージング環境では、ファイル制御よりも速度と俊敏性の方が重要です。
ステージング環境でAkamaiホスティングを利用し、実稼動環境でFTP配信を行います。
サイトの一部のセクションでは、極めて機密性の高い情報を扱っています。 セキュリティはこれらのページで最も重要な要素ですが、サイトの他のページでは必ずしも重要ではありません。
セキュリティで保護されたページでのライブラリのダウンロードホスティングと、セキュリティで保護されていないページでのAkamaiホスティングを活用します。
すべてのホスティングオプションを、DTMプロパティの Embed タブで有効にして設定できます。
選択したホスティングオプションに関係なく、JavaScriptライブラリは、インストールされた埋め込みコードを介してサイトに提供されます。 各ホスティングオプションは、そのホスティングオプションに設定された該当するファイルの場所を参照する一意の埋め込みコードのセットを提供します。
埋め込みコードは、次の2つのコードスニペットで構成されます。 ヘッダーとフッターのコード。
  • ヘッダーコード
    ヘッダーコードは、関連付けられたJavaScriptライブラリをホストの場所から呼び出し、サイトで提供する役割を持ちます。 このコードスニペットは、サイトコードのheadセクションの開始タグのできる限り近くに配置する必要があります。
  • フッターコード
    フッターコードは、タイミング制御のためにページの終わりを識別します。 このコードスニペットは、サイトコードのbodyセクションのできる限り終了タグの近くに配置する必要があります。
ヘッダーとフッターの埋め込みコードスニペットの適切な配置は、DTM JavaScriptライブラリを効果的に展開するうえで重要です。
複数のホスティングオプションを使用できますが、特定のページには、1つの埋め込みコード参照のみを含める必要があります。 埋め込みコードを重複させたり不適切に配置したりすると、予期しないライブラリの動作が発生する可能性があります。
次の図は、説明したDTMアーキテクチャのコンポーネントが連携して、サイト上のツール、タグ、スクリプトを効果的にデプロイおよび管理する仕組みを示しています。
For more information on hosting options, see Embed Code and Hosting Options in the Dynamic Tag Management Product Documentation .

DTMへの移行の計画

実装を正しく開始するために役立つ、 Dynamic Tag Management (DTM)への移行を計画する際に考慮する必要のある情報とベストプラクティスです。
このコンテンツは、Search Discovery と連携して構築されました。
このセクションでは、以下について説明します。

DTMの設定の計画: コンポーネントの概要

ここでは、DTMの設定計画に関する決定に備えるための、基本的なDTM会社構造の概要を簡単に説明します。
DTMでは、会社はWebプロパティのグループです。
Webプロパティは、データを収集し、サイトにタグやスクリプトを導入するために設定されたツール、ルール、データ要素のグループです。
各Webプロパティは、サイトに特定のプロパティ設定を読み込む役割を持つ1つの埋め込みコードに関連付けられています。
ユーザーは会社レベルで管理されますが、管理者ロールを除き、各プロパティに対する権限を付与することができます。 管理者ロールはグローバルで、会社内のすべてのプロパティに対するフル権限を持ちます。
For more information on user roles, see Create and Manage Groups in the Dynamic Tag Management Product Documentation .

DTMの設定の計画: 判断ポイント

基本的なDTM会社構造を念頭に置き、DTMの設定を計画する際に関連する決定ポイントについて説明します。
必要な会社数
ほとんどの場合、1人の会社がビジネス・ニーズを満たすのが最適です。
複数の会社を持つ主な理由は、ユーザーとWebプロパティの完全な分離を達成することです。
このタイプの設定は、様々な事業部門が運営する多数のWebエンティティを持つ大規模企業に最も一般的です。
ドメインとサブドメインをWebプロパティにどのように配布する必要がありますか。
Webプロパティは、ドメインに対して1対1または1対多として設定できます。
どの変数が貴社のビジネスに最適かを判断するには、クロスドメインの類似点と次の変数の違いを考慮します。
  • データ収集方法とソース
  • 導入されたツールとタグ
  • サイトのコード構造
  • DTMユーザーワークフロー
ほとんどの場合、上記の変数の1つまたは多くに相当な違いがあるので、1つのドメインにつき1つのWebプロパティがビジネスニーズを満たすのに最適です。
この種のセットアップは、各ドメインのニーズに最も効果的に対応できる一方で、「コピー」機能を使って、クロスドメイン定数を簡単に複製できます。
ただし、これらの変数がドメイン間で同じまたは非常に類似している場合は、1つのWebプロパティ内に複数のドメインがあるとより意味があります。 この場合、この設定により、プロパティ間の不要な重複を減らすことができます。
この同じ推論は、サブドメインの配分にも使用できます。
使用例
シナリオ
ソリューション
私の事業部門は複数のドメインを管理しています。 Adobe Analyticsはすべてのドメインにデプロイしていますが、各ドメインには独自のレポートスイートと追跡のニーズがあります。
各ドメインに1つのプロパティを使用します。
私の事業部門は複数のドメインを管理しています。 Adobe Analyticsをすべてのドメインにデプロイし、1つのグローバルレポートスイートを使用してすべてのデータを収集しています。 サイトのコード構造が異なるので、ドメイン間のデータソースは大きく異なります。
各ドメインに1つのプロパティを使用します。
私の事業部門は複数のドメインを管理しています。 Adobe Analyticsは、すべてのドメインにデプロイし、グローバルレポートスイートとグローバルデータレイヤーを使用して、すべてのデータを収集します。 アドビのツールとタグの残りの部分は、ドメイン間でほとんど一貫しており、同じユーザーが発行ワークフローを管理する予定です。
すべてのドメインに対して1つのプロパティを使用します。

移行のベストプラクティス

最適な会社とプロパティの配布を決定した後、DTMの移行を開始する際は、次のベストプラクティスを検討します。
プロセスワークフロー: ​既存のページコードを DTM に移行するための体系的なプロセスを開発し、スムーズな移行を実現します。
一般に、このプロセスを低レベルのステージング環境で開始し、ページごとまたはサイトセクションごとにコードを移行することをお勧めします。
これにより、既存のページコードを削除する前にDTM設定を十分に調べ、導入を中断するリスクを軽減できます。
IT の活用: ​現在のプロセスとデプロイメントサイクルを決定するには、IT チームと事前に連携することが重要です。
これにより、埋め込みコードを適切かつ適時に配置し、効果的に移行されたページコードを調整して削除することができます。
ユーザーワークフローとガバナンス: ​もう 1 つの重要な概念は、ユーザーワークフローを確立することです。ユーザーの役割を慎重に割り当てることで、DTM ワークフローにガバナンスを提供します。
ユーザの役割
ルールの作成
ルールの編集
ルールのテスト
ルールの承認
ルールの発行
ユーザーの作成/編集
プロパティの作成
ユーザー
承認者
発行者
承認者と発行者
Admin
これにより、すべての品目が適切なチームメンバーによって完全にベットされ、実稼動に移されます。
詳しくは、Dynamic Tag Management製品ドキュメントの 「Dynamic Tag Managementへの 移行 」を参照してください

DTMへの移行: Adobe Analyticsの詳細

現在の Adobe Analytics 実装がページ上の方法でデプロイされているか、別のタグ管理システムでデプロイされているかにかかわらず、DTMに移行する際のオプションについて説明します。

フェーズ1: クイック値の追加

コードの移行は長いプロセスになる場合があるので、DTMオファーは、既存の Adobe Analytics​Analytics 実装を中断することなく拡張できる機能を備えています。
このコンテンツは、Search Discovery と連携して構築されました。
この機能は呼び出され Page Code is Already Present 、DTMプロパティのAnalyticsツール設定にあります。
この機能にアクセスするには、ツール設定の「ライブラリ管理」セクションを展開します。
この機能を有効にすると、DTMは、既存の実装を利用して、イベントベースのルールおよびダイレクト型ルールを介して追加の s.t() / s.tl() 呼び出しを送信できます。
この機能により、DTMを使用してAdobe Analyticsの実装を拡張してコードを移行する前に、開始を簡単に行うことができます。
ただし、この方法では、次の制限事項に注意する必要があります。
  • DTM Adobe Analyticsツールで設定された変数と設定は有効になりません。
  • ページ型ルールで設定されたAdobe Analytics変数は有効になりません。
これらの制限は、DTMがAppMeasurementコードを提供し、sオブジェクトをインスタンス化するために、既存の実装に完全に依存しているために発生します。

第2段階: 完全な移行

DTMの統合 Adobe Analytics 機能を最大限に活用するには、コードの完全な移行をお勧めし Analytics ます。
このコンテンツは、Search Discovery と連携して構築されました。
この移行には、ページコード内のすべてのsオブジェクト参照と、DTMがAdobe Analyticsを導入するページに含まれるスクリプトを含める必要があります。
詳しくは以下のセクションで説明されています。
グローバルコードの移行
移行の最初の手順は、DTMプロパティのAdobe Analyticsツール設定でグローバルコードを設定することです。
は、「コード AppMeasurement code / s_code の設定」の下にあるツール設定の「ライブラリ管理」セクションで設定します。
フェーズ1の「ページコードが既に存在する」が現在使用されている場合は、このオプションをオフにして、コード設定のオプションを表示する必要があります。 この変更はステージングでのみ有効なので、移行したコードを完全に設定して調査した後で、実稼動環境にプッシュすることができます。
「カスタム設定」オプションは、追加のツール設定を必要とせずに既存の設定をそのまま参照できるので、通常、初期移行アプローチ AppMeasurement / s_code としてお勧めします。
  • カスタム - DTM でホスト: ​既存のコードをエディターに貼り付けます。
  • カスタム - URL でホスト: URL の場所にある既存のコードを参照します。
この Managed by Adobe オプションを選択すると、DTMは、選択したAppMeasurementベースコードバージョンを自動的に提供し、ホストします。 この方法を使用すると、コードのバージョンを簡単に更新でき、長期的なオプションになります。
「コード設定」オプションに関係なく、AppMeasurementコードに含まれていない項目は、提供されたインターフェイスフィールドまたはページコードのカスタマイズエディターを使用して、ツール設定で設定できます。
提供されるインターフェイスフィールドは、グローバル設定と変数を設定するための長期的なオプションです。カスタムコードの代わりにこれらのフィールドを利用することで、導入全体の複雑さを軽減できます。
構文を使用して任意のフィールドのデータ要素を直接利用することで、変数にデータをダイナミックに埋め込み %dataElement% ます。
#エディタは、プラグインや条件の設定など、コードを必要とする項目の便利な代替ツールです。 ここに配置したコードは、ホストするコードと連携して動作し AppMeasurement code / s_code ます。
ページレベルコードの移行
移行の次の手順は、DTMルールで非グローバルコードを設定することです。
ここでは、各ルールタイプの概要と、Adobe Analyticsトリガーを設定する際の一般的な使用方法を示します。
ルールタイプ 詳細
ページ型ルール
すべてのまたは特定のページのデフォルトのページ表示ビーコンに変数を追加する場合に使用します。 使用例: プロモーションページの読み込み時に特定のeVarを送信する
イベント型ルール
特定のユーザーインタラクションに対して s.t() または s.tl() ビーコンをトリガーする場合に使用します。 使用例: ポーバーが有効な場合に、カスタムページ表示ビーコンを特定のイベントと共に送信する。
ダイレクト型ルール
DOMイベントが検出できない場合に、シナリオで s.t() または s.tl() ビーコンをトリガーするために使用します。 使用例: ビデオが視聴されたときに特定のイベントを含む s.tl() ビーコンを送信する。
前の節で説明したように、Adobe Analyticsコードを移行する際は、次のベストプラクティスを覚えておくことが重要です。
  • 体系的なプロセスを開発する
  • 移行を完全に綿密に調べるための低レベルのステージング環境での開始
  • 早い段階でITと連携してコード削除を調整
プログレッシブマイグレーションで考えられるアプローチは、まだ完全に移行されていないページを識別するためのフラグを決定することです。 次に、このフラグをツール設定のページコードのカスタマイズエディターで使用して、これらのページのデフォルトのDTMビーコンを条件付きでキャンセルできます。この場合、このフラグはを設定して使用 's.abort = true' します。
この方法はAnalyticsツールビーコンにのみ影響します。 Adobe Analyticsを実行するように設定されたルールは、ルール自体で条件を満たす必要があります。
実稼動環境で活用する前に、ステージング環境でこのアプローチを十分に検討してください。

タグ管理システムの利点: DTMに重点を置いています。

tag managementの基本に関する情報を紹介し、ビジネスに特に役立つ方法 Dynamic Tag Management を紹介します。
このコンテンツは、Search Discovery と連携して構築されました。
詳しくは以下のセクションで説明されています。

タグ管理システムとは

tag managementシステムは、コンテナタグを使用して、サイト上のマーケティングタグと解析タグを容易に実装および管理できるように設計されています。
コンテナタグは、サイトのマークアップに配置すると、サイト上で無数のタグをトリガできる単一のコードスニペットです。
このアプローチはITグループの負担を軽減し、マーケティング担当者の手に委ねます。

Why Dynamic Tag Management (DTM)

Dynamic Tag Managementは、上述のタグ管理アプローチを採用し、シナリオとタイミング制御を統合したシンプルで高機能な設計により、タグ管理を強化します。
Dynamic Tag Managementがお客様のビジネスに最適かどうかを判断する際は、以下の点を考慮してください。
  • サイトのパフォーマンスの向上
    Dynamic Tag Managementを使用すると、marketingタグとanalyticsタグはサイトのマークアップからDTMライブラリに移動されます。 DTMライブラリはファイル圧縮と速度に最適化されているので、ページの読み込み時間が短縮されます。
    ただし、DTMの条件付きコントロールと非同期オファーを使用することで、パフォーマンスがさらに向上します。
    条件付きコントロールを使用すると、タグが必要な場合にのみトリガーされ、不要なコードのデプロイメントを排除できます。
    非同期読み込みを使用すると、タグが強制的にページから離れてしまうので、ページレンダリングの負荷が大幅に軽減されます。
  • 制御の向上、リスクの軽減
    ITへの依存度が低くなれば、タグをウォッチポイントにデプロイして管理できるようになります。
    これは、ベンダータグの導入に伴う取り組みとリスクを軽減し、新しいツール/タグ機能に対応する俊敏性を向上させることを意味します。
    さらに、DTMには、データのプライバシーポリシーへのコンプライアンスを確保し、ベンダータグがサイトに干渉したり、サードパーティにデータが漏洩したりするのを防ぐ機能が組み込まれています。
  • より迅速かつ効率的に作業
    Dynamic Tag Managementは、行動中心のアプローチで、包括的な統合とデータ集中化を活用して、タグの導入を容易にします。
    行動中心アプローチでは、無数のツール/タグを、個々のタグを個別に導入する代わりに、ある行動に基づいて同時に導入できます。
    DTMに組み込まれた統合により、Adobe AnalyticsやGoogle Analyticsなどのツールの設定が容易になり、広範なカスタムコードを使用する必要がなくなります。
    データ要素は、共通のデータポイントを一元化し、コードの冗長性を低減し、データ参照時間を最適化します。
    これらの機能を組み合わせることで、時間とフラストレーションを節約でき、タグの導入に集中する手間を省き、ビジネスを進めることに集中できます。
  • Dynamic Tag Managementを無料で使用
    特に、Adobe Experience Cloudのお客様の場合は、Dynamic Tag Managementは無料です。
    詳しくは、アドビのアカウントマネージャーにお問い合わせください。