Data Layer
よみ: ディーエーティーエーエルエーワイイーアール
GTMでサイトとタグの間でデータを受け渡すための仮想領域です。JavaScript / JSオブジェクトの形式で、ユーザー属性・閲覧商品情報・購入金額などを定義しておくと、各種タグから参照できます。ECサイトや動的サイトでの高度な計測実装に必須です。
担当者が押さえておくべき役割分担
Data Layer に直接コードを書いて実装するのはエンジニア(業者)の領域ですが、「どんなデータを乗せるか」の設計図を作るのは Web 担当者の役割です。
実務での進め方(設計のコツ)
まずは「後でどんな分析をしたいか(ビジネス指標)」を言語化し、それに必要な情報を要件として整理して業者に渡します。
【例】EC サイトの「カート追加」の場合
カートボタンが押されたら、「商品 ID」「価格」「カテゴリ」「会員区分」のデータを Data Layer にプッシュ(書き込む)してください、と依頼する。
実務での落とし穴(よくある失敗例)
- 設計の業者への丸投げ：Data Layer の設計を業者任せにしてしまい、いざ分析しようとした時に「あの数字(カテゴリごとの売上など)も取っておけばよかった」と後悔するケース。
- 後からの追加開発：運用が始まってから「このデータも追加して」と頼むと、余計な開発コストと時間がかかってしまいます。導入時に「分析軸にしたい情報」を網羅的に定義しておくことが、結果的に最も効率的です。
言葉をよく利用する人
- Web 担当者(発注側)
- アクセス解析担当
- コーダー / フロントエンドエンジニア
- バックエンドエンジニア
会話上での使用例
広告運用者からカテゴリ別の効果計測を頼まれる場面
-
広告運用者
商品カテゴリごとのCV数を出したいんですが、できますか。
-
Web担当者(発注側)
それにはData Layerに商品カテゴリの情報を乗せる設計が要ります。どんなデータを乗せたいかをこちらで整理して、業者に要件として渡しますね。
アクセス解析担当と計測要件の洗い出しを相談する場面
-
アクセス解析担当
計測したい項目が、後からどんどん増えてしまって。
-
Web担当者(発注側)
一度Data Layerの設計を棚卸ししましょう。後で分析軸にしたい項目を先に網羅して発注すれば、追加開発を頼む手戻りが減りますよ。
-
アクセス解析担当
最初に出し切っておくほうが結局ラクなんですね。