どうもカッツプロダクション代表のカッツです、今回はモヤっとしたまま終わる記録です！！ 先に言っておくとこの記事の対策、効いてるか検証できてません。

Meta広告を回してるLPで、サンクスページ（CVページ）がランディングページとして計測されるという現象が起きてまして。いわゆるセッションが切れてるやつです。

で、対策を入れて数字も改善した！ と思ってたんですが、、、後から調べ直したらそもそも見てたパラメータが違うっぽいことに気づきまして。その顛末を正直に書きます(笑)。

サンクスページ（thankyou.html）がLPとして計測される現象

GA4のランディングページレポートを見ると、/lp/xxxxx/thankyou.htmlつまりサンクスページがランディングページとして上位に出てくるんですよ。

ユーザーがいきなりサンクスページに着地するわけないじゃないですか。これはLP→フォーム→サンクスページの流れの途中でセッションが切れてるという典型的なやつです。

「あれ、なんでサンクスページがLPに？」と思ってUA（ユーザーエージェント）を見てみたら、Safariで起きてることがわかりまして。ITP（Intelligent Tracking Prevention）の存在自体は知ってたので、原因はすぐにピンときました。

ちなみにこれ、HubSpotフォームとかいわゆるSaaS系では起きたことがなくて、今回が初めての遭遇だったんですよね。SaaS側が勝手に吸収してくれてたということなんでしょうね。

検索が下手なのか有力な情報がでてこなくて必殺Geminiさん

そもそもこの症状、ネット上に情報がかなり薄い気がするんですよね。SaaSのフォームを使ってれば起きない問題なので、自前実装してる人しかぶつからない。母数が少ないから記事も少ない、という構図なんだと思います。

で、自力で検索してもいい情報にたどり着けなかったので、Geminiさんに相談してみました。Geminiは検索も一緒に混ぜて回答してくれるので、こういう情報が薄いテーマでも比較的マシな答えが返ってくる印象があります。「ハルシネーションなしで」と念押ししつつ投げてみました(笑)。

返ってきた回答で刺さったのが「GETパラメータで自力でパラメータを付与してもGA4は正規のリンカーパラメータとして認識しない」という指摘です。GA4のリンカーパラメータは、単純にCookieの値をURLにくっつければいいわけじゃなくて、タイムスタンプやフィンガープリントがハッシュ化された特殊な構造になってるんですよね。

ここまでは正しい情報だったんですが、、、自分がこの指摘をちゃんと理解できてなかったんですよね。後述します(涙)。

入れた対策（※真似しない方がいいです）

ここはPHP工房さんのフォームを使ってる案件だったので、ちょちょいと仕組みを入れました（ヴァイブコーディングw）。

PHP — サンクスページへのリダイレクト時にパラメータを付与
$ga_cookie = $_COOKIE['_ga'] ?? '';
$redirectUrl = $thanksPage;
if ($ga_cookie !== '') {
    $redirectUrl .= (strpos($thanksPage, '?') !== false ? '&' : '?') . '_ga=' . urlencode($ga_cookie);
}
header("Location: ".$redirectUrl);

まー単純ですよね。Cookieの中身をほじくり出してURLにむりくり付与させて、あとは`header`の`Location`でサンクスページにリダイレクトするだけ。

正直やってる最中も「こんなので本当に効果あるのかいな？？」と半信半疑でした。この違和感、正しかったです(笑)。

フォーム周りをいじるときは送信テストを絶対に忘れないでください。問い合わせが丸ごと飛ばなくなったらシャレになりません、、、

対策を入れたのが7月22日です。

数字は良くなった、ように見えた

6月ブラウザ別 GA4のランディングページレポート
7月ブラウザ別 GA4のランディングページレポート
8月ブラウザ別 GA4のランディングページレポート

まず、サンクスページがランディングページとして計測されたセッション数をブラウザ別に並べるとこうなります。

月SafariSafari(in-app)Chrome合計
6月（対策前）451147
7月（7/22から対策）171018
8月（対策後）3115
一目瞭然ですが、圧倒的にSafariで起きてます。6月なんて47件中45件がSafari。ITPが原因という読みは、この時点では正しそうに見えますよね。

ただし発生率で見ないと意味がない

件数だけ見ると45→3で激減なんですが、そもそもLP全体のSafariセッション数自体も同時期に落ちてるんですよ。広告の出稿量が変わってたりするので、ここは外的要因ですね。

月LPのSafariセッションサンクスLP化(Safari)発生率
6月1,537452.93%
7月904171.88%
8月45830.65%

なので件数じゃなくて発生率で見る必要があります。そこで見ると2.93%→0.65%なので、一応改善はしてるように見えるんですよね。

とはいえ8月の3件って絶対数が少なすぎて、統計的にはかなり不安定な数字です。1件増えただけで発生率が0.87%に跳ね上がる規模。これを根拠に「効果あり」と結論づけるのは無理があると思ってます。

Chromeでも毎月1件ずつ起きてる件

あともうひとつ見逃せないのが、Chromeでも6月・8月に1件ずつ発生してることです。

ChromeはITPの影響を受けないので、これは明らかにITP以外の要因ですよね。ブックマークからの直接アクセスとか、URLが共有されたとか。この話は後でもう少し掘り下げます。

で、後から気づいた致命的な勘違い

記事を書きながら改めて調べ直してたら、そもそもアプローチ自体が的外れだったことに気づきました。

自分が付与してた`_ga`というパラメータ、GA4がドメイン間でセッションを引き継ぐときに使うのは`_ga`ではなく`_gl`が本体でした。しかもその`_gl`は、クライアントID・セッション識別子・整合性ハッシュをまとめてエンコードした構造で、手動で正しく生成する公式な方法自体が用意されてないそうです。

つまり「正規の形式でパラメータを付与しよう」と思っても、原理的に無理だったわけですね。

そもそも、ドメインをまたいでないんですよ

で、もっと根本的な話なんですが、、、今回のケースって同じドメイン内のLP→サンクスページなんですよ。

通常なら同一ドメイン内でCookieはそのまま引き継がれるはずで、ドメイン間でセッションを渡す仕組みを持ち出すこと自体がズレてたわけです(お間抜け。。。)

問題の本質は「パラメータの付け方」じゃなくて、「ITPによってCookieそのものが短命化・分断されてる」という別の話だった可能性が高いです。だとすると対策の方向性は、サーバーサイドでのファーストパーティCookie管理あたりになってきます。

じゃあ自分が付けた`_ga`は完全に無意味だったのか？

ここが微妙なところで、調べてると`_ga`パラメータもURLに現れるケースがあるらしいんですよ。ただしそれは`_gl`とセットで、GA4が自動生成するときの話。

自分がやったのは`_gl`なしで`_ga`だけ、しかもCookieの生の値をそのまま付与という状態です。これをGA4が「なるほどクライアントIDね」と解釈してくれるのかどうか、、、

正直なところ、この実装が効いてるのか効いてないのか、自分では検証しきれていません。`_gl`が正規の仕組みなのは間違いないんですが、`_ga`単独で機能するかは公式ドキュメントにも記載がなくて。

セキュリティ設計の思想から考えると、「誰でも書き換えられる生のID」を無条件で信用する作りにはしないはずなので、機能してない可能性の方が高いとは思ってます。でも「絶対に効果ゼロ」とも言い切れない、というのが正直な状態です。

じゃあ数字が良くなったのは何だったのか

これも因果関係は証明できてないです。

発生率で見れば2.93%→0.65%と改善してるので、何かしらは効いてるのかもしれない。でも同時期に広告の配信内容が変わってる可能性もあるし、出稿量が変わればトラフィックの質そのものも変わります。季節変動やSafari側の仕様変更だってありえます。

何よりChromeでも毎月1件出てることを考えると、残った数件は対策とは無関係な「純粋な直接アクセス」かもしれないわけで。

「対策を入れた」「数字が良くなった」の2つが並んでると、つい因果関係があるように見えちゃうんですよね。これデータ分析の初歩的な罠で、自分でも何度も気をつけてるつもりだったんですが、まんまとハマりました。

そもそも切り分けが難しい問題

対策の話に入る前に、この問題のややこしさについて触れておきます。

ITP、ITPと言ってますが、データを見るとわかる通りSafariでもうまくいってるケースの方が圧倒的に多いんですよ。6月ですら発生率2.93%、つまり97%以上は正常に計測できてるわけです。

「Safariだから全部ダメ」ならわかりやすいんですが、大半は正常で一部だけこぼれ落ちる。しかもChromeでも毎月1件は出てる。だから切り分けが本当に難しいんですよね。ITP以外の要因（アプリ内ブラウザ、プライベートブラウズ、直接アクセス、URL共有など）も混ざってくるので、どれがどの原因なのか特定しきれない。

今回残った5件も、本当にITPなのか、それとも単にサンクスページのURLをブックマークして後から開いた人なのか、SNSでURLが共有されたのか、、、正直わかりません。この数字は完全にゼロにはならないということでもあります。

ネクストアクションを考えたけど、良い手がない

それでも一応、対策案はいくつか考えました。そのたびに調べ直したんですが、、、ことごとくダメでした。供養も兼ねて書いておきます。

案1：JavaScriptでリダイレクトさせる

`header(“Location: “)`をやめて、こういう形でJSリダイレクトさせればどうかと考えました。

PHP — JSリダイレクトに変更するイメージ
echo '<script>location.href="' . $thankspage . '"</script>';

`header`だとサーバーサイドで即リダイレクトが走るので、ブラウザ側のGA4タグが動く余地がない。JSならいったんHTMLがブラウザに渡るので、その間にGA4のタグが動けるのでは、という発想です。

調べたら公式に否定されてました。GA4のリンカーは「ユーザーのクリックイベント」に反応して動く仕組みなので、JavaScriptでナビゲーションをトリガーした場合は正しく動作しないとドキュメントに明記されてます。

案2：Refererを保持して引き継ぐ

リダイレクト時にRefererを付与すれば参照元情報が途切れないのでは(少ないCPUとメモリを駆使して迷走中)

これも技術的に成立しません。`Referer`はブラウザがサーバーに送るリクエストヘッダーであって、サーバーがレスポンスに付けてもブラウザは解釈しません。そもそもGA4がセッションを切ってる原因はCookieであってRefererではないので、的外れでした。

案3：広告の`fbclid`パラメータを引き継ぐ

Meta広告から来たときに付く`?fbclid=xxxxx`を保存して、サンクスページに引き継げば何か効くのでは、とも考えました。

これもダメです。`fbclid`はMeta側の計測用パラメータで、GA4のセッション判定には一切関係ない。むしろサンクスページのURLにパラメータが増えると、GA4上で別ページとして集計されるという新たな問題を生むだけでした。

結論としては

正直に言うと、現状これといった良い手がないです。

そもそも`_gl`パラメータを手動で正しく生成する公式な方法が存在しないので、自前実装でどうにかするのは筋が悪い。理論上残ってるのはGTMのサーバーサイドコンテナ導入やMeasurement Protocolでのサーバーサイド計測くらいですが、、、

どちらも初期構築コストとランニング費用がそれなりにかかります。月に数件のズレを直すためにやるには、明らかにオーバースペックなんですよね。費用対効果が全く釣り合わない。

というわけで今回は深追いしないという判断にしました。実務的にはこれが正解な気がしてます。

ただですね、、、CVって母数が少ない上に、施策判断に関わるクリティカルな数字じゃないですか。だからこそ精度を高めたいというジレンマはあるんですよね(涙)。「全体の数%だから誤差」で済ませられない領域でもあるので、ここは正直モヤっとしたまま終わります。

ちなみに自分のところでは、お問い合わせの分析においてGA4はあくまで参考値という立ち位置にしてます。フォームからのメール送信時に簡易CRMへ登録するロジックを入れておいて、そこに溜まったデータを一次情報として使うという運用ですね。

実装はGAS（Google Apps Script）でやってます。Zapierとかのツールを使う手もありますが、GASなら無料ですしスプレッドシートとの相性も抜群なので。

GA4の計測はどうしてもブラウザ側の事情に振り回されるので、確実に取りたい数字はサーバーサイドで別に押さえておく。今回みたいな問題に悩まされないためにも、この二段構えはおすすめかもです。
ま〜Hubspotとかいれれば関係ないですが(いろいろあるんです 涙)

こうやって検証しきれてない状態を文章にすると、自分の理解の浅さが浮き彫りになります。。。 恥ずかしいですが、同じところでモヤモヤしてる人の参考になればということで残しておきます。

PS
AIさんと一緒に盛大に対策間違ってる！と気づいたのが今回なんですが、まだ間違ってる箇所あるかもしれません。ツッコミありましたらぜひお願いします！ AIの進展でWebマーケのマニアックなネタってどんどん消えてる気がするんですよね。ググっても出てくる情報がかなり薄くなってて、今回は匙を投げましたもう無理です(涙)。

参考になれば幸いです！ツッコミどころあれば連絡くださいね。