ブログに戻る

ブログ

サーバーサイドタギングの前に置く Cookie バナー:変わることと、変わらないこと

公開 · 読了 6 分

質問は 2 つの形で届きます。「タグがファーストパーティになった今、バナーはまだ必要ですか?」— 必要です。「タグがファーストパーティになった今、バナーはまだ機能しますか?」— たいていは機能しますが、機能しなくなる仕方が静かなので、20 分かけて確かめる価値があります。これは法的助言ではなく仕組みの説明です。顧問が指示することを、設定が実際に実行するように。

サーバーサイドタギングが同意について変えること:何もない

ファーストパーティのホスト名はリクエストの技術的な属性であって、許可ではありません。昨日アナリティクス Cookie の設定に同意が必要だったなら、今日も必要です。Cookie を設定するのが google-analytics.com ではなく metrics.yoursite.com になったことは、そこに一切関係しません。規制当局の問いは「何を、なぜ収集するのか」であって、パケットが途中でどのサーバーを経由したかではありません。

変わるのは、ブロックされたリクエストの行き先です。広告ブロッカーやブラウザのプライバシー機能はホスト名と URL パターンでブロックし、googletagmanager.com をブロックします。あなた自身のドメインはブロックしません。そのため、同意したにもかかわらずフィルタリストに黙って落とされていた訪問者が、今度は数えられます。それが利点のすべてであり、同意した訪問者に対してのみ利点なのです。

Consent Mode を 1 段落で

Google のタグは、名前付きの権限 — analytics_storage、ad_storage、ad_user_data、ad_personalization — からなる同意状態を読み取り、送信内容を調整します。訪問者が決める前に同意管理ツールがデフォルトの denied をプッシュし、訪問者が選択すると更新をプッシュします。denied の状態でも Google タグは発火しますが、Cookie なしの ping を送るだけです。クライアント ID も Cookie もなく、ページが閲覧されたという信号だけです。analytics_storage が granted になると完全なヒットを送信します。サーバーコンテナは送信されたものをそのまま受け取り、同意シグナルはヒットとともに運ばれるので、サーバー側の GA4 タグも同じように振る舞います。

順序が重要で、SignalHost のタグは独自の条件を追加しない

同意管理ツールは Google タグより先に読み込まれなければなりません。タグが最初に評価する時点でデフォルト値が置かれているようにするためです。多くの同意管理ツールはまさにこのために wait_for_update の値を用意しています。タグが denied とみなす前に同意状態を待つ、数百ミリ秒の猶予です。

SignalHost がコンテナに作成するエンティティには同意条件がありません。意図的です。Google 自身のタグが Consent Mode を尊重するからで、Google タグにだけ手動で同意チェックを付け、その下の GA4 イベントタグには付けない — これが以下の 2 つのミスの 1 つ目です。

ミスその 1:Google タグだけを制御し、イベントタグを制御しない

Google タグは計測をサーバーコンテナ経由にする役割を担います。GA4 イベントタグ — たとえば purchase のタグ — は単独でも送信できます。Google タグが同意を待ち、イベントタグが待たない場合、イベントタグは同意前に発火して Google に直接送信します。しかもバナーがまだ開いているページからです。ヒットがコンテナを通らないので、コンテナページには何の異常も現れません。

手動では何も制御せず Consent Mode に任せるか、送信できるすべてのタグを制御するか。一貫性のある中間はありません。

ミスその 2:あなた自身のローダーを認識しないブロック型の同意管理ツール

同意管理ツールの中には、同意が得られるまでスクリプトをブロックする方式のものがあります。script タグを URL で捕捉し、保留するのです。そのリストは googletagmanager.com を知っています。しかし exxz2gdaz1jz.yoursite.com は知りません。誰のリストにも載りようがないからです。ローダーのホスト名とファイル名はあなたのコンテナ固有のものです。したがってブロックモードではローダーが無条件に通される可能性があり、Consent Mode ではなくブロックに頼っているなら、それは同意前に発火するタグです。

対処は 2 通りです。ローダーの URL を、アナリティクスが属するカテゴリで同意管理ツールのブロックルールに手動で追加する。あるいは — Cookie なしの ping も正しく扱えるのでこちらが望ましい — Google のタグには Consent Mode を使い、ブロックは Consent Mode に対応しないスクリプトにだけ使う。私たち自身のサイトは、同意管理ツールを自動ブロックモードで動かしつつ Consent Mode を併用しています。Google タグは同意管理ツールのスクリプトの後に置かれ、順序を入れ替えるとリポジトリのテストが失敗します。

サーバー側と、その他の送信先

同意状態は各ヒットの中に含まれてサーバーコンテナに届き、サーバー側の GA4 タグはブラウザ側と同じようにそれを読み取ります。私たちの側で同意を付与したり拡張したりすることはありません。Cookie なしの ping は Cookie なしの ping のままです。

Meta や TikTok の送信先を接続すると、同じヒットがそれらにも供給されます。訪問者がマーケティング同意を拒否した場合にその転送を止めるべきかどうかは、同意管理ツールが表現する決定です。ローダーをどのカテゴリに置くか、そして Consent Mode の ad_storage を設定が尊重するかによります。ここで挙げた他のすべてと同じ方法で確認してください。バナーに答えないままサイトを開き、ネットワークタブを見て、何が出ていくかを確かめるのです。

チェックリスト

  • 同意管理ツールのスクリプトが、ページ内で Google タグより上にある。
  • タグの読み込み前に、wait_for_update 付きでデフォルトの同意状態 denied がプッシュされている。
  • コンテナ内のどのタグにも手動で追加した同意条件がない — あるいは、送信できるすべてのタグに条件がある。
  • バナーに答えていない状態で、ネットワークタブに Cookie なしの ping(リクエスト内に gcs=G100)が表示され、完全なヒットは表示されない。
  • 同意後、同じページに完全なヒットが表示され、コンテナページがそれをカウントする。
  • 同意管理ツールが URL でブロックする方式なら、ローダーの URL がそのルールに含まれている。

広告ブロッカーにデータを奪われ続けない

毎月 1 万リクエストを無期限で無料。役に立つかどうかは 4 分でわかります。