CookiePass と Google 同意モード：同意バナーはトラフィックに何をもたらすか

同意モードはタグのオン／オフスイッチではありません。導入後も Google タグはすべてのページで発火します。変わるのは各ヒットに付くフラグと、それによって Google がヒットをどう扱うかです。analytics_storage が拒否されている場合、タグは Cookie を設定せず、ページ間でクライアント ID を保持せず、Google が「Cookie なしの ping」と呼ぶヒットを送ります。GA4 はこれをレポートではなくモデリングに使います。

そのフラグは gcs というクエリパラメータで、2 文字と 2 桁の数字です。最初の数字が ad_storage、2 番目が analytics_storage を表し、1 が許可、0 が拒否です。

gcs=G100   ad_storage denied,  analytics_storage denied
gcs=G101   ad_storage denied,  analytics_storage granted
gcs=G110   ad_storage granted, analytics_storage denied
gcs=G111   both granted
(no gcs)   no Consent Mode on the page — treated as granted

見落とされがちなのは最後の行です。同意モードのないページは gcs を送らず、Google はそのヒットをすべて同意済みとして扱います。つまり同意モードを実装したバナーを追加しても送信量は減りません。送信について正直に伝え始めるだけです。

同意モード v2 が求めるのは設定ではなく順序です。デフォルト状態は Google タグが読み込まれる前に宣言されなければならず（まだ選択していない人には拒否）、訪問者が決めた瞬間に更新が続き、再訪問のたびに復元される必要があります。順序を誤ると、バナーが描画される前に各セッションの最初のページビューが同意済みとして送られます。

これが CookiePass 自身のスクリプトが生成するシーケンスで、Tag Manager コンテナには何も入りません：

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

// …the visitor accepts…
gtag('consent', 'update', {
  ad_storage: 'granted',
  analytics_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

統合はこれで全部です。Google のタグは同意状態を自動的に尊重し、SignalHost がウェブコンテナに公開するタグも同様です。サーバーコンテナに同意条件は不要です。手作業で追加すると、ゲートされた Google タグの隣にゲートされていないイベントタグが並び、データが Google へ直接送られることになります。

ヒットの経路は変わりません。ブラウザが自社ホスト名に送り、エッジがサーバーコンテナへ転送し、コンテナが GA4 へ送ります。違いはペイロードだけです。

• 選択前：すべてのヒットに gcs=G100、_ga Cookie なし、ページごとに新しいクライアント ID。GA4 は Cookie なしの ping を受け取り、コンテナはリクエストを 1 件数えます。
• 同意後：gcs=G111、Cookie が設定され、セッションがつながります。ここからがレポートを構成するヒットです。
• 拒否後：選択が続く限りすべてのページで gcs=G100。拡張計測のイベント（scroll、file_download など）も page_view と同じ規則に従います。

バナー導入後にコンテナページがイベントごとに 2 つの数字を示すのはこのためです。アナリティクスへの同意付きで送られたヒット（アナリティクスがユーザーとセッションとして報告するもの）と、スラッシュの後にコンテナが転送したすべてです。session_start と first_visit はどちらの列にも現れません。アナリティクスがイベントとして受け取るのではなく、最初の page_view のフラグから導き出すからです。

2 つの列は一致しないものと考えてください。その差こそがページで最も役立つ数字です。

• アナリティクスが報告するユーザーとセッションは、コンテナが数えるリクエストより少なくなります。差は拒否した、または回答しなかった訪問者の割合、つまり推測ではなく測定された同意率です。
• GA4 はプロパティが Google のしきい値を満たせば、行動モデリングでその差の一部を埋められます。モデル化されたデータはレポートには現れますが、送信されないためコンテナには決して現れません。
• ad_storage が拒否されていると、Google 広告のコンバージョン トラッキングには帰属先がなく、コンバージョン リンカーにはつなぐものがありません。サーバーコンテナはこれを変えませんし、変えるべきでもありません。ファーストパーティは同意不要という意味ではありません。
• バナーのデザインは計測上の判断になりました。同意率 60% と 85% はボタンが違うだけの同じサイトで、列の差がどちらなのかを教えてくれます。

• 同意スクリプトを Google タグより前に読み込む。最初のヒットの前にデフォルト状態が存在しなければなりません。
• バナー未回答のページを開き、ブラウザのネットワークパネルで /g/collect リクエストの gcs を読む。G100 のはずです。
• 同意して次のページでもう一度読む。G111 のはずです。
• サーバーコンテナ内のものに同意トリガーを追加しない。ウェブタグがすでに状態を運んでいます。
• 翌日コンテナページに戻り、page_view の数字のペアを読む。最初の数を 2 番目で割ったものが同意率です。

CookiePass を選んだのは、上記のシーケンスをそのまま実行し、当サイトでは午後のうちに稼働し、バナーにサイト自身の色を使えるからです。前のセクションの数字が、それが機能している証拠です。