GA4のタグ設計表は、コードに触れる前に書く：イベント・パラメータ・同意の決め方

GA4が記録するもの、そして設計表が必要になる理由

立ち上げから18か月がたったネットショップ（仮の例）のGoogleタグマネージャーのコンテナに、フォーム送信で発火するタグが3つ入っています。formSubmit、form_submit、Form Submit。1つは広告代理店、1つは社内の開発者、1つは消し忘れたテストの名残です。GA4では3つが別々のイベントとして並び、2つがキーイベントにチェックされ、どのレポートが何に依存しているか分からないので、誰も削除できません。場当たり的な運用のツケは、経営層の最初の質問（「先月の問い合わせは何件？」）に3通りの答えが返ってくる形で現れます。

タグ設計表は、この事態を避けるための取り決めです。経営上の問いを立てる人、ページ上に情報を出す開発者、GA4で読む分析担当者という、ふだん同じ言葉を話さない3者をつなぎます。表は、判断から出発するKPIの選び方で述べた指標ツリーから直接導かれます。表の各行はツリーのどれかの指標を支えているべきで、そうでなければ存在する理由がありません。

イベント、パラメータ、プロパティ

GA4のモデルはすべてイベント型です。ページビューもスクロールも購入もイベントで、それぞれが文脈を表すパラメータ（購入なら currency や value など）を持てます。これに加えて、行動ではなく人を表すユーザープロパティがあります。Googleアナリティクスのドキュメントによれば、イベントはいくつかの種類に分かれます。収集時に自動で発生するもの、拡張計測機能によるもの（スクロール、離脱クリック、サイト内検索、ファイルのダウンロード、動画、フォームの操作など。設定による）、Googleが名称とパラメータを定めて推奨する推奨イベント、そして自分で名前をつけるカスタムイベントです。

したがって優先順位は次のとおりです。自動収集や拡張計測機能で必要が満たせて、しかも信頼できるなら、それを使います。そうでなければ対応する推奨イベント（purchase、add_to_cart、begin_checkout、generate_lead、sign_up、view_item など）を探します。レポートやGoogleの機能が解釈できるのは、こうした名称とパラメータだからです。カスタムイベントは最後の手段で、上のどれにも当てはまらない自社固有の行動に限ります。

ドキュメントが前面に出さない3つの特性

1つめ。カスタムパラメータは、自動的にレポートや探索で使えるわけではありません。カスタムディメンションまたはカスタム指標として登録する必要があり、ドキュメントによれば、この登録はすでに収集したデータにさかのぼっては効きません。したがって設計表は、最初からディメンションを見込んでおく必要があります。3月から送っていたパラメータを分析したかったと9月に気づけば、使えるデータは9月以降の分だけです。

2つめはカーディナリティ。値が二度と重ならないパラメータ（セッションID、クエリ付きの完全なURLなど）は、ディメンションとして使えません。ドキュメントには、超過した値がレポート上で「(other)」の行にまとめられることがあると書かれています。そこで設計表では、パラメータごとに、想定する値の一覧か、管理された形式を指定します。

3つめ。GA4には制限（名前の長さ、1イベントあたりのパラメータ数、カスタムディメンション数など）があり、プロパティの種類によって異なり、変更されることもあります。野心的な設計を始める前に、Googleの公式ヘルプにある収集の制限のページを確認してください。

KPIから表の1行へ

設計表の作成は、次の7ステップをこの順に進めます。

1. 判断から始める。指標シートに戻り、第2・第3階層のうち、ブラウザでの計測に依存するものを洗い出す。
2. 対応するユーザー行動を列挙する。たいていのサイトでは5〜15個で足ります。
3. 優先順位に従ってイベントを選ぶ。自動収集、推奨、カスタムの順。
4. パラメータを定義する。判断に本当に必要なものだけに絞り、形式も決める。
5. トリガーを「成功の状態」で書く。「支払い完了後に注文確認ページが表示された」は検証できます。「支払うボタンのクリック」は検証できません。クリックのあとに決済が失敗することがあるからです。
6. キーイベントを指定する。GA4では一部のイベントをキーイベント（旧「コンバージョン」）にできます。この指定は事業にとって価値のある行動に限り、3〜5個にとどめます。
7. 同意の扱い、担当者、バージョンを記入する。イベントが壊れたとき誰が対応するか。表はいつ承認されたか。

ランニング用品のネットショップ（仮の例）に適用した結果が次の表です。

「同意設定の対象」の列を、すべて「はい」にするとは限りません。何を対象にするかは、自社が同意取得・オプトアウト・通知のどれを軸にするか（後述）で決まります。

数字を歪めずにイベントへ金額をつける

サービス業のサイトでは、generate_lead に自然な金額がありません。よくあるのは、推定の金額を割り当てる方法です。問い合わせの10件に1件が顧客になり、1契約で120,000円の粗利が出るなら、リード1件の価値は10% × 120,000円 = 12,000円と見積もれます。実際の成約率が8%なら、9,600円に下がります。この見積もりはチャネルの比較には役立ちますが、実際の売上と混ぜてはいけません。設計表に計算根拠と日付を記録し、成約率を計算し直すたびに見直します。そうしないと、GA4に表示された金額が実績データのような顔をして、誰も計算根拠を知らないものになります。

命名規則とGoogleタグマネージャーでの実装

個人情報を入れない規則は、念のための注意にとどまりません。Googleアナリティクスの利用規約は、個人を直接特定できる情報の送信を禁じています。GA4のリードをCRMの1行と突き合わせたいときは、ランダムな技術的IDを渡します。

開発者との契約：データレイヤー

HTMLからGoogleタグマネージャーに情報を抜き出させる方法は、テンプレートが変わると壊れやすくなります。代わりに、開発者に情報をデータレイヤー（dataLayer）へ送ってもらいます。注文が確定し、2,450円の商品2点と5,900円の商品1点が含まれるとします（仮の例）。送料と税は別のパラメータなので、value は 2 × 2,450円 + 5,900円 = 10,800円で、送信は次のようになります。

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'T-10458',
    value: 10800,
    currency: 'JPY',
    items: [
      { item_id: 'SKU-101', item_name: '機能性ソックス', price: 2450, quantity: 2 },
      { item_id: 'SKU-205', item_name: '軽量ウインドブレーカー', price: 5900, quantity: 1 }
    ]
  }
});

最初の ecommerce: null は前のオブジェクトを空にするためのもので、Googleのeコマース計測ガイドは、同じページで2つの注文が混ざるのを防ぐためにこれを推奨しています。transaction_id も飾りではありません。GA4はこれを使って購入の重複を抑えようとするので、顧客が注文確認ページを再読み込みしたときに意味を持ちます（正確な挙動は公式ヘルプで確認してください）。Googleタグマネージャー側では、カスタムイベント型のトリガーが purchase という名前を待ち受け、GA4イベントタグがそれをプロパティへ中継します。データレイヤーのeコマースデータを送るオプションを有効にします。

運用の習慣を3つ添えます。タグ名は読みやすく接頭辞をつける（GA4 - evt - purchase）。変更のたびにワークスペースとバージョンメモを作り、設計表の該当行を書く。プレビューモードを通さずに公開しない。プレビューモードなら、どのイベントでどのタグが発火したかが見えます。

注意すべき落とし穴があります。拡張計測機能は、フォーム関連のイベント（入力開始、送信）を自動検出します。AJAXで送信されるフォームや外部のフレームに埋め込まれたフォームは認識されないことがあり、バリデーションエラーで止まった送信が数えられてしまうこともあります。テストなしにこれをキーイベントにするのは、コンバージョンが計測されないときの診断で扱う数字のずれの典型的な原因です。

同意と通知は、設計表の1列

「同意設定の対象」列は、勘で埋められません。日本では、分析目的のCookieすべてに一律の事前同意（オプトイン）を求める規定があるわけではない、と整理されるのが一般的ですが、設計に影響する枠組みが少なくとも2つあります。以下の記述は一般的な整理であり、法的助言ではありません。

1つめは個人情報保護法です。個人情報保護委員会のガイドラインは、Cookieなどの端末識別子に紐づく閲覧履歴等を「個人関連情報」として整理しており、提供先で個人データとして取得されることが想定される場合には、提供元が本人の同意取得を確認する必要がある、としています（2022年4月施行の改正による枠組み）。さらに、計測データを会員IDやメールアドレスと突合する設計にすれば、そのデータは個人情報に当たり得ます。設計表で個人情報を入れない規則を置く理由の一つがここにあります。

2つめは、電気通信事業法の外部送信規律（2023年施行。同法第27条の12など）です。総務省の公表資料によれば、対象となる事業者が利用者のブラウザなどから情報を外部へ送信させる場合、送信される情報の内容、送信先、利用目的などを、通知または容易に知り得る状態に置く（公表する）ことなどが求められ、同意の取得やオプトアウト措置といった方法も選択肢として整理されています。アクセス解析や広告のタグを入れるサイトは、この規律が関係し得ます。ただし、対象となる事業者やサービスの範囲は限定されているため、自社が該当するかどうかは総務省の資料で確認する必要があります。

実務上は、同意管理プラットフォーム（CMP）が訪問者の選択を記録し、Googleの同意モード（Consent Mode）がその状態をGoogleタグに伝えます。EU・EEA・英国の訪問者が見込まれるサイトや、自社方針でオプトインを採るサイトでは、この仕組みが特に効きます。ドキュメントによれば、主要なシグナルは analytics_storage、ad_storage、ad_user_data、ad_personalization です。初期状態はタグが読み込まれる前に宣言し、訪問者が選択した時点で更新します。実装には2種類が説明されています。基本モードでは同意があるまでGoogleタグを読み込みません。拡張モードではタグを読み込み、拒否された場合でもCookieを使わないシグナルを送り、Googleがそれを使って欠けたコンバージョンの一部をモデル化します。拡張モードでは選択の前に通信が発生するため、それが自社の義務や方針に適合するかは、法務担当者や弁護士と詰める必要があります。基準となるのは個人情報保護委員会と総務省の資料です。

設計表には、ここから2つの具体的な帰結が出ます。1つは、各行に、どの同意状態でイベントが発火するかを書くこと。もう1つは、GA4の数字を全数調査ではなく、訪問者の一部集合の計測として読むことです。基幹システムとの比較は整合性の確認であり、一致を求めるものではありません。外部送信規律に基づく通知・公表に載せる項目（送信先、送られる情報、目的）は、この設計表の列とほぼ重なると考えられます。表を一元管理しておけば、通知文の更新漏れを減らせるでしょう（必要な項目の正確な範囲は、総務省の資料で確認してください）。

EU居住者を対象に含むサイトでは、GDPRも関係します。EU域外へのデータ移転については、欧州で動きがありました（2022年に欧州の複数のデータ保護当局がGoogle Analyticsに関する判断を示し、2023年に欧州委員会がEU・米国間のデータプライバシーフレームワークについて十分性認定を出しています）。法的状況は変わるため、この段落は法的分析の代わりにはなりません。

設計表の限界と、公開前の受け入れテスト

きちんと管理された設計表でも、データが正しいことは保証されません。保証されるのは、何を測りたかったかを把握しているため、ずれを検出できることです。そこで最後の工程は、1行ずつの受け入れテストになります。サイト上で各操作を実行し、Googleタグマネージャーのプレビューモードと、GA4のDebugViewで、名前、パラメータ、値、重複がないことを確認し、結果を設計表に記録します。流入元とキャンペーンのパラメータ（utm_source、utm_medium、utm_campaign）はイベントごとには宣言しませんが、その命名規則は設計表の一部です。流入元の読み方は、これに直接依存します。

もっとも、この方法には損益分岐点があります。5ページほどで、目的が問い合わせフォームだけのコーポレートサイトなら、6行の表で足ります。40イベントの設計表は保守の負債になります。設計表は古くもなります。Googleは推奨イベントの名称や画面上の表記、同意に関する選択肢を更新していくからです。見直しの日付と担当者を決めていなければ、1年で飾りの文書になります。

とはいえ、設計表がなければ計測できないわけではありません。GA4の自動収集だけでも、設定なしでページビュー、セッション、流入元は手に入ります。設計表が加えるのは、判断に関わる行動（購入、問い合わせ）の信頼性と、それを監査できることです。

設計表づくりから分析・改善までを通して学ぶなら、マーケティング分析・AI実践コースがあります。