コンテナ内には何十ものタグがあります。二重に発火するもの、誰にも使われなくなったもの、そして「test2-final」という変数が報告収益を決めているケースもあります。何も変わらない限り、ウェブサイトは計測を続けます。しかし最初の変更が発生すると、公開に承認を出したい人は誰もいません。
この記事の初版には、当時のGoogle Analytics、AdWords、Sklik、Facebook、その他すでに終了したツール向けの具体的な設定が 19 個含まれていました。当時は実用的でしたが、今古いタグをコピーすると技術的負債になります。より重要なのは、新しいインターフェースやプラットフォームへの置き換えにも耐えられる仕組みです。
GTMはデータを作らず、その経路だけを管理する
Google Tag Managerは、次の3つの基本要素で動作します。
- タグは、特定のサービス向けにデータを送信または処理します。
- トリガーは、どのイベントで、どの条件の下でタグを有効にするかを決めます。
- 変数は、取引ID、価格、ページタイプなどの値を提供します。
GTM自体は、注文が支払い済みかどうかを知りません。その情報はウェブサイトまたはバックエンドが提供する必要があります。元のシグナルが間違っていれば、どれほど正しく設定されたタグでも、その誤りをより速く、より多くのシステムへ送るだけです。
データレイヤーはウェブサイトとマーケティングの合意事項
データレイヤーは、ウェブサイトがイベントや値をタグへ渡すための構造化された層です。特定のHTML要素から価格を読み取る代わりに、購入完了時にアプリケーションが安定したフィールドを持つイベントを送信します。
window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: 'purchase', ecommerce: { transaction_id: 'OBJ-12345', value: 2490, currency: 'CZK', items: [] } });これは原則を示す簡略化した例であり、完全なeコマース実装ではありません。具体的な構造は、対象プラットフォームの現行推奨事項に合わせてください。重要なのは、名前、型、イベントのタイミングについて合意し、テストできることです。
ウェブサイトが実際のビジネスイベントを提供できるなら、サンクスページのURLやボタンの文言には依存しないほうがよいと考えています。デザイン変更で文言やURLは変わります。データレイヤーの合意事項は安定しているべきです。
まず計測計画、次にコンテナ
すべてのビジネス上のステップについて、次の事項を書き出します。
- イベント名
- イベントが発生する正確な条件
- 必須パラメータとその形式
- 信頼できる情報源
- 送信先となり得るシステム
- 必要な同意状態
- 担当者とテスト方法
問い合わせでは、フォーム送信と有望なリードを区別します。オンラインストアでは、注文開始と購入確定を区別します。これにより、広告アルゴリズムが簡単だが商業的価値の低いアクションに最適化されるのを防げます。
名前は複数のツールに耐えられるものにする
一貫した小文字のイベント名と、明確に説明されたパラメータを使います。GA4がgenerate_lead、add_to_cart、purchaseのような推奨イベントを提供している場合は、公式の名前とパラメータに従うのが合理的です。互換性の高いレポートが得られ、変換レイヤーも少なくて済みます。
他のプラットフォームでは独自の名前が必要になる場合があります。変換はタグ内だけで行います。ウェブサイトが送るべきなのは、提供元のロゴごとにほぼ同じシグナルを5つ送ることではなく、理解しやすい1つのビジネスイベントです。
同意をアーキテクチャの一部にする
CookieバナーとGTMを別々の世界として動かしてはいけません。デフォルトの同意状態はタグより前に利用でき、ユーザーの選択後には正しく更新される必要があります。Googleはタグ向けに、基本モードと高度なモードを含むConsent Modeを説明しています。
Consent Modeはバナーでも法的評価でもありません。企業は必要な場合に同意を取得し、その状態を渡し、Google以外のタグも含めてすべてのタグが選択を尊重するようにする必要があります。Googleタグの同意管理にCustom HTMLという近道は適切ではありません。サポートされている仕組みとテンプレートを使ってください。
無作為なスクリプトよりネイティブテンプレートを優先する
Googleタグ、Google Ads、その他のサポート対象サービスには、ネイティブまたは信頼できる承認済みテンプレートを使います。Custom HTMLは、安全に解決できない状況のために取っておきます。サードパーティースクリプトを追加するたびに、パフォーマンス、セキュリティ、保守のリスクが増えます。
四半期に一度、コンテナを見直し、企業が使わなくなったサービスのタグを削除します。使われていないマーケティングツールが、忘れられていたというだけの理由で訪問者にアクセスできてはいけません。
テストではデータ、順序、発火しない場合も検証する
プレビューとTag Assistantでは、どのタグが、どの順序で、どのデータを使って発火したかを確認できます。「Fired」と表示されるだけでは不十分です。私が確認するのは次の点です。
- タグが正確に1回だけ発火したか
- 間違ったステップで発火していないか
- 値、通貨、取引ID、商品項目
- 対象サービスへのネットワークリクエストとレスポンス
- プラットフォームのリアルタイムモードまたはテストモードでの状態
- 同意が許可された場合と拒否された場合の両方
- モバイル、リダイレクト、決済失敗、再読み込み
購入については、結果をバックエンドと比較します。GTMが1件の取引を報告し、注文システムが別の件数を報告している場合、Tag Assistantが会計上の現実を決めるわけではありません。
公開にはバージョンと復旧経路が必要
変更前に、複数人でコンテナを扱う場合は別のワークスペースを使います。公開には「バージョン 37」ではなく成果に基づく名前を付け、変更したイベントを記述します。Google Tag Managerは公開時にコンテナのバージョンを保存するため、履歴を追跡でき、エラーが発生した場合は以前の状態に戻せます。
ただし、ロールバックはテストの代わりにはなりません。ウェブサイトとデータレイヤーが同時に変更された場合、古いコンテナは現在のコードで動かない可能性があります。ウェブサイトと計測のバージョンは連携して展開してください。
健全なコンテナの12項目
- ウェブサイトには正しいコンテナが1つだけあり、その配置はインストール手順に従っている。
- すべての主要イベントに計測計画と担当者がある。
- ウェブサイトは壊れやすいページ読み取りではなく、安定したデータレイヤーを送信している。
- 名前とパラメータに一貫性があり、文書化されている。
- 適法で承認された理由なく、個人データをデータレイヤーへ送信していない。
- 関連するタグが発火する前に同意が設定されている。
- Googleタグと広告タグには、存在する場合はサポート対象テンプレートを使っている。
- すべてのタグに、限定された理解しやすいトリガーがある。
- 購入とリードが誤って二重送信されることがない。
- テストには否定的なシナリオと同意拒否も含まれている。
- 公開には名前、説明、既知の復旧経路がある。
- 使われていないタグ、変数、アクセス権を定期的に削除している。
GA4、Meta、広告システムの位置づけ
GTMは交通の交差点です。Google Analytics 4は、イベントの意味とレポートを扱います。Conversions APIに関する記事では、Metaへイベントをサーバー側から送る経路を説明しています。MetaからGA4へ費用を直接インポートする目的は別であり、GA4とMeta Adsを接続するガイドで説明しています。
すべての層を1つのタグで解決しようとしないでください。まずイベントを定義し、次に同意、転送、検証、そして最後にレポートを考えます。
GTMが不要な場合
サポート対象の分析タグが1つだけの非常にシンプルなウェブサイトなら、Googleタグを直接導入したほうが明快な場合があります。より多くのイベント、サービス、条件、そして管理された変更プロセスが必要なときにGTMが意味を持ちます。GTMは、成熟したマーケティングに必須の勲章ではありません。
コンテナが何年もかけて大きくなり、もう誰も公開したがらない状態なら、別のタグを追加することから始めるべきではありません。まず棚卸しを行い、データレイヤーからレポートまでのテスト経路を1つ作ります。現在の状況については、お問い合わせからご相談いただけます。