これはほとんど哲学的な問題です。
GTM の統合と拡張 e コマース トラッキングの実装を検討していますが、見れば見るほどこの 2 つが対立しているように感じます。
GTM は、アプリが一般的なデータ ポイントをデータ レイヤーに公開し、「Markerter」または同様のものがそれらの変数を使用して GTM でタグを設定する Web アプリからの懸念の分離を促進するようです。
ただし、拡張 e コマースを実装するための推奨される方法は、非常に具体的なデータをデータレイヤーに直接追加し、GTM でボックスにチェックを入れることです。これは、データ層がもはや一般的ではないことを意味し、GTM が自ら宣伝するのを好むため、バックエンドに変更を加えたり、「IT 部門のサポートなしに」拡張 e コマースを実装したりすることはできません。
何か足りないのでしょうか、それともグーグルはここで独自のドッグフードを食べていませんか??
質問の最初の文を削除する必要があると思います。
哲学的ではありませんが、コードが GTM でどのように構成されているかの問題として: IT 部門の助けを借りずに GTM を実装できるという考えは、ずっと BS でした。どこかからデータを取得する必要があります。これを行うための唯一の安定した方法は、遅かれ早かれ失敗する Web サイトのより一時的な側面 (DOM、URL など) にトラッキングを結合したくない場合を除き、dataLayer です。
強化された E コマース トラッキングに特定のデータ層が必要であるということは、ほとんど実際的な決定のようです。そうしないと、e コマース トラッキングを使用する予定がある場合に、Google アナリティクス タグ用に大量の入力フィールドと変数が必要になります。
また、dataLayer を使用する必要はありません。拡張 e コマース トラッキングの入力を GTM 変数に設定することもできます。この変数自体が、データレイヤー以外の手段 (DOM スクレイピング、グローバル変数、ajax 呼び出しなど) を介してデータを取得する関数である可能性があります。これは必ずしも良い考えではありません (サーバーがより高速で信頼性の高いことをブラウザーで実行することは一般的にそうではありません) が、完全に可能です。
そのため、Google はドッグフードを食べることも維持することもできます。これは、ユーザーがどのようにやりたいかを選択できるようにするためです。