GTMを使用しているがページはめ込みのデータレイヤーを使用しない拡張eコマース

Question

私はページソースにアクセスできないプロジェクトに取り組んでいるわけでもなく、クライアントのITチームにページ内/タグの前にdataLayerがあります。 dataLayer.pushを使用して拡張eコマーストラッキングをリモートで実装できるかどうかDataLayerをビルドしますか？私はdataLayer.pushの知識はほとんど持っていません（これは私が読み始めています）。質問は：

• 正しい方法は正しいですか？誰でもこの前に をやったことがありますか？
• 私が直面する可能性のある問題「カートに追加」イベント、カートを削除するか、 カテゴリページを使用していますか？私はまだここにワークフロー の明確なビューを持っていない。
• 今後のサイト設計更新時に「スタイル/ CSS」ベースの トリガーの下にこのようにすることの欠点は何ですか？

ありがとうございます。

Answer 1

あなたの主な問題は、どこかからデータを取得する必要があることです。通常dataLayerを使用しない場合、これはDOMをスクレープし、スクラップしたデータをカスタムjavascript関数のdataLayerにアセンブルすることを意味します。

• 実装が強く
• データが不足している可能性があり、または
• （HTMLまたは無関係なテキストと混合した場合）クリーニングが必要なページレイアウトに結合されています。欠点は、あなたのstle/CSSベースのトリガーと同じです潜在的に高価な失敗の新しいポイントを紹介javascriptのカスタム（つまり、あなたは何の副作用がないことを保証するために厳密に十分にテストすることができます）

クライアントのCPU時間のあなたはworkaを行う場合あなたのクライアントのITの欠点を回避するためには、あなたが所有していることを覚えておいてください。回避策が壊れたり、副作用があったり、新しい機能を考慮して修正する必要がある場合は、あなたがそのリスクを非常にうまく補っていることを確かめてください（そして、今私が経験したことを個人的には私はこれを全くしません）。

Answer 2

データレイヤーはこの情報を格納する単なる方法であり、ページからデータをプッシュすることができるため、この情報が使用されていることを認識することが重要です。

コードをサイト自体に書き込めない場合は、データレイヤーに情報をプッシュしないでください。あなた自身のために、GTMの変数でその情報を保持してください。あなたは大きな頭痛や計算のビットを救うでしょう。

DOMスクレイピングは、情報を保持するのに完全に合理的な方法ですが、いくつかの障壁にぶつかります。

• 必要なデータを取得するには、多くのJavaScriptを作成する必要があります。
• いくつかのボタンは、サイトへの変更は、潜在的にあなたのコードを台無しにする
• など、あなたのトリガでカバーする必要がありますいくつかの要素で構成されるようになるかもしれません。
• 特にデータの確認（取引の報告前に購入が完了したかどうかの確認はおそらく不可能）をすべて利用できるわけではありません。