GTMのCookie変数とJavaScript変数の落とし穴｜HttpOnly属性で値が取れない理由｜未経験から100日後にGTMのプロになる話【Day 20】

ここまで、組み込み変数、データレイヤー変数、DOM要素変数、JavaScript変数と、いくつもの変数タイプを個別に扱ってきました。今日はもう1つ、Cookie変数を加えたうえで、「変数」というGTMの部品全体をどう組み合わせて設計するかを整理します。

ファーストパーティCookie変数

サイトが発行したCookieの値をGTMで取得したい場合、「ファーストパーティ Cookie」タイプの変数を使います。

1. 「変数」→「新規」→種類は「1st Party Cookie」
2. 「Cookie 名」に対象のCookie名（例：user_segment）を入力
3. 変数名を「Cookie - ユーザーセグメント」として保存

ここで必ず押さえておいてほしい制約があります。GTMのCookie変数は、ブラウザのdocument.cookieから値を読み取っています。ところがサーバー側で発行されるログイン・セッション系のCookieには、セキュリティ対策としてHttpOnly属性が付いていることが多く、この属性が付いたCookieはJavaScriptから一切参照できません。「Cookie変数を正しく設定したはずなのに、値が常に空になる」という相談を受けたとき、まず疑うべきはこのHttpOnly属性です。エンジニアに「そのCookieはHttpOnlyになっていないか」を確認してもらうのが早道です。

JavaScript変数のログイン判定も同じ理由でハマりやすい

Day13で扱ったJavaScript変数（例：window.userStatus）でログイン状態を判定する設定も、根っこは同じ話です。サーバーサイドでレンダリングされた値ではなく、クライアント側のJavaScriptオブジェクトとして値が公開されている必要があります。認証情報をそのままクライアントに露出させるのはセキュリティ上望ましくないため、実際には「ログイン済みかどうかの真偽値だけ」をwindowに出してもらう、という形で開発者と握るのが現実的な落としどころです。

組み合わせ方の考え方

変数はそれ単体では何もしません。トリガーの条件式に組み込んで「発火するかどうか」を左右するか、タグのパラメータに組み込んで「何を送るか」を決めるか、の2通りの使い道しかありません。設計に迷ったときは、「これは発火条件の話か、送信データの話か」を最初に切り分けると、どの変数をどこで使うべきかが整理しやすくなります。

今日のまとめ

Cookie変数もJavaScript変数も、「クライアント側から見える値しか取得できない」という共通の制約があります。HttpOnly属性や、サーバー側だけで完結する値は、GTM単体ではどうやっても取得できません。取得できないと分かったら、まず開発者にクライアント側へ値を出してもらえるか相談する、というのが正しい切り分け方です。次回は、Google広告のコンバージョンタグの設定に進みます。