タグアーカイブ Kanslieri Cookie Consent

Bricks Builderのカスタムコードで同意管理プラグインが効かない時の直し方

Bricks Builderのカスタムコードで同意管理プラグインが効かない時の直し方

Kanslieri Cookie ConsentでGoogle AnalyticsやMicrosoft Clarityを自動ブロックする設定にしているのに、シークレットウィンドウで計測タグが動いてしまう原因は、Bricks Builderのカスタムコード欄に直書きしたスクリプトを、同意管理プラグインが認識できない仕組みにある。スクリプトを手動ブロック用の属性に書き換えるか、WordPress標準のエンキュー方式に差し替えれば、同意前の計測を確実に止められる。

なぜBricksカスタムコードの計測タグがブロックされないのか

なぜBricksカスタムコードの計測タグがブロックされないのか

Kanslieri Cookie Consentをはじめ、多くのCookie同意管理プラグインは、WordPressの標準機能であるwp_enqueue_scriptで読み込まれたスクリプトをフックして制御する設計になっている。スクリプトのハンドル名を解析し、同意が得られるまで実行を自動的に保留する仕組みだ。

一方、Bricks Builderの「Settings → Custom Code → Header Scripts」に貼り付けたコードは、テーマがwp_headアクションを通じてページのソースにそのまま埋め込む。プラグイン側からは「PHPで読み込まれたスクリプト」として認識されず、単なるインラインHTML扱いになる。その結果、管理画面のScript Blockingページに「Google Analyticsは自動ブロック対象」と表示されていても、実際にはブロックが効かない。

Google Analyticsの_ga_gidといったCookieがシークレットウィンドウで生成され、/g/collectへのリクエストが送信され、page_viewscrollイベントが記録されるのはこのためだ。Microsoft Clarityも同様に、カスタムコード欄経由では自動ブロックの対象外になる。

同意前のトラッキングを防ぐ具体的な修正手順

同意前のトラッキングを防ぐ具体的な修正手順

Kanslieri Cookie Consentの自動ブロックが効かない場合でも、手動ブロックの仕組みを利用すれば計測を止められる。修正方法は大きく2つある。すでにカスタムコードを使っているなら、スクリプトタグに手動ブロック用の属性を追加するのが最も手早い。

手動ブロック用のtype属性に書き換える方法

Kanslieri Cookie Consentは、スクリプトタグのtype属性をtext/plainに書き換えることで、同意があるまでスクリプトの実行を止める仕組みを持っている。同意が得られた時点で、プラグインがtypetext/javascriptに戻して実行する。Bricksのカスタムコード欄に貼ってあるGoogle AnalyticsとMicrosoft Clarityのコードを、次のように修正する。

修正前
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>
修正後
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX" type="text/plain" data-cookiecategory="analytics"></script>
<script type="text/plain" data-cookiecategory="analytics">
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>
修正前(自動ブロック非対応)  修正後(手動ブロック対応)

ポイントは各<script>タグにtype="text/plain"data-cookiecategory="analytics"を追加することだ。data-cookiecategoryの値は、Kanslieri Cookie Consentの設定で該当スクリプトを割り当てたいカテゴリ名と一致させる。Google Analyticsならanalytics、Microsoft Clarityも同じ分析カテゴリで構わない。複数カテゴリにまたがる場合はdata-cookiecategory="analytics, marketing"のようにカンマ区切りで指定できる。

WordPressのエンキュー方式に切り替える方法

より根本的な解決策として、カスタムコード欄ではなく子テーマのfunctions.phpからwp_enqueue_scriptでスクリプトを読み込む方法もある。この方法なら、Kanslieri Cookie Consentの自動ブロック機能が確実に働く。

function my_google_analytics_script() {
    wp_enqueue_script(
        'google-analytics',
        'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX',
        array(),
        null,
        false
    );
    wp_add_inline_script(
        'google-analytics',
        "window.dataLayer = window.dataLayer || [];
        function gtag(){dataLayer.push(arguments);}
        gtag('js', new Date());
        gtag('config', 'G-XXXXXXXXXX');"
    );
}
add_action('wp_enqueue_scripts', 'my_google_analytics_script');

このコードを子テーマのfunctions.phpに追加したら、Bricksのカスタムコード欄から該当のコードを削除する。Kanslieri Cookie ConsentのScript BlockingページでGoogle Analyticsが認識されるようになり、同意前のトラッキングが自動的にブロックされる。

手動ブロックが正しく動くか確認する手順

手動ブロックが正しく動くか確認する手順
STEP 1 ブラウザのシークレットウィンドウを開く(Cookieが初期化された状態)
STEP 2 サイトにアクセスし、Cookie同意バナーが表示されたら同意せずに待つ
STEP 3 Chrome DevToolsの「Application → Cookies」で_gaや_gidが生成されていないことを確認
STEP 4 「Network」タブでgoogle-analytics.comやclarity.msへのリクエストが発生していないことを確認

DevToolsのNetworkタブでは、フィルタにcollectclarityと入力すると該当リクエストを素早く見つけられる。同意前にこれらのリクエストが記録されていなければ、ブロックは正しく機能している。その状態でCookieバナーの「同意する」をクリックし、直後にリクエストが走り始めれば、同意後の計測も正常に動作していることになる。

Bricks Builderのキャッシュが有効になっている場合は、修正後にかならずキャッシュをクリアする。Bricksの管理画面から「Bricks → Settings → Performance」でキャッシュを削除したうえで、サーバー側のキャッシュやCDNがある場合も同時にパージする。キャッシュが残っていると修正前のスクリプトが配信され続けてしまうため、確認作業の前に忘れずに行う必要がある。

よくある質問

他のページビルダー(ElementorやDivi)でも同じ問題は起きるのか

起きる可能性が高い。Elementorのカスタムコード機能やDiviの統合設定から追加したスクリプトも、テーマ側で直接HTMLに出力されるため、同意管理プラグインの自動ブロック対象外になりやすい。同じ手動ブロックの手法が適用できる。ただし、Elementorの場合はwp_enqueue_script方式に切り替える方が推奨される場面が多い。カスタムコード欄にスクリプトを置く運用は、同意管理の観点からは避けるのが無難だ。

Kanslieri Cookie Consentの自動ブロックが効かないスクリプトを見分ける方法はあるか

管理画面の「Script Blocking」ページに一覧表示されるスクリプトは、プラグインが自動検出できたものだけだ。ここに表示されていないGoogle AnalyticsやClarityのスクリプトは自動ブロック対象外と判断してよい。また、シークレットウィンドウで実際にCookieが生成されるか、DevToolsでネットワークリクエストが発生するかを確認すれば、ブロックの可否を実動作で検証できる。

手動ブロックに書き換えたスクリプトが、同意後も動かない場合はどうするのか

Kanslieri Cookie Consentの設定で、data-cookiecategoryに指定したカテゴリが有効になっているか確認する。「Cookie Settings」画面で該当カテゴリのトグルがオンになっていること、同意バナーでユーザーがそのカテゴリを許可できる選択肢が表示されていることをチェックする。カテゴリ名にタイプミスがあると、プラグインがスクリプトをどのカテゴリに紐づけてよいか判断できず、同意後も実行されない。

Bricksのカスタムコードは使わず、Google Site KitプラグインでGA4を入れるとどうなるか

Site Kitはwp_enqueue_scriptを使ってGoogle Analyticsタグを読み込むため、Kanslieri Cookie Consentの自動ブロック機能が正常に働く。手動ブロックの書き換えは不要になる。すでにカスタムコードでGA4を入れている場合は、そのコードを削除してSite Kitに移行するだけで、同意管理の課題が解決する。Clarityも公式プラグインを使えば同様だ。

この記事のポイント

  • Bricks Builderのカスタムコード欄は同意管理プラグインの自動ブロック対象外になる
  • スクリプトタグにtype="text/plain"とdata-cookiecategoryを追加して手動ブロックに対応させる
  • wp_enqueue_scriptで読み込めば自動ブロックが有効になり修正不要
  • 修正後はシークレットウィンドウとDevToolsでCookieとリクエストを検証する
  • キャッシュクリアを忘れると修正が反映されない