FirefoxとBraveがUTMアトリビューションを壊している

あなたのUTMトラッキングは漏れている。原因はプライバシー重視のブラウザだ。FirefoxはStrictモードで、ページが読み込まれるより前に、既知のトラッキングパラメータをURLから削除する。Braveは違うルートで同じ結果にたどり着く。パラメータ自体はほとんどそのまま残すが、それを読み取るはずのアナリティクススクリプトをブロックする。どちらの場合も、UTMタグ付きのクリックはタグが消えた状態、あるいはそれを解析するスクリプトがブロックされた状態でランディングページに到着し、キャンペーンレポートは静かに過小計測されていく。

これはSafariの問題の、クエリ文字列版とも言える現象だ。Safari ITP後のクリックアトリビューションの記事はストレージとクッキーを扱っているが、本稿はURLパラメータそのものが削除・無視される話であり、症状は同じでもメカニズムは異なる。

2つのブラウザ、2つのメカニズム、1つの壊れたレポート

正確に理解しておく価値はある。「ブラウザがUTMを削除する」という言い方は半分しか正しくないからだ。

Firefoxは実際に削除する。 Strict Enhanced Tracking Protectionで有効になるクエリパラメータストリッピング機能は、URLパラメータを既知のトラッキング識別子のリストと照合し、一致したものをページ読み込み前に削除する。デフォルトのリストは限定的とはいえ実在するもので、しかも設定変更が可能なため、対象は増える一方だ。ブラウザ別のクリックIDとパラメータストリッピングに関する解説記事が、各ブラウザでの実態を示している。

Braveは主に読み取り側をブロックする。 Braveのパラメータ削除は一貫していない。確実に行うのは、UTMを読み取るはずのアナリティクススクリプト(GA4を含む)のブロックだ。パラメータ自体はURLの中に残っている場合もあるが、ページ上のどのスクリプトもそれを解析することを許されないため、レポートへの影響は同じになる。アトリビューションが取れなくなるのだ。

Safariのストレージ制限を加えると、プライバシー機能の三重奏が完成する。業界のテストでは、プライバシー重視のブラウザは訪問者のおよそ5分の1〜4分の1を占めるとされ、米国トラフィックの一部はデフォルトのGA4トラッキングを完全にブロックするブラウザから来ている。これはキャンペーンレポートにおける誤差の範囲では済まない数字だ。

Firefoxがページ読み込み前にURLからUTMパラメータを削除し、BraveがそのUTMを読み取るはずのGA4スクリプトをブロックする様子。どちらもUTMアトリビューションの喪失につながる

UTM方式が構造的に脆弱な理由

UTMのモデルは、プライバシー重視のブラウザが壊しうる2つの前提に依存している。トラッキングパラメータがページへの移動を生き延びること、そしてそのページ上のスクリプトがそれを読み取れることだ。どちらも遷移先で起きる出来事であり、それはまさにブラウザのプライバシー機能が働く場所でもある。つまり、タグを取り除くためだけに作られた関門を、そのタグ自身に生き延びさせようとしているのに等しい。

だからといってUTMをやめる理由にはならない。トラフィックの大半を占めるChromeでは今も問題なく機能しているからだ。ただし、ランディングページのUTMを唯一の正解として扱わない理由にはなる。これは損失を伴うチャネルであり、しかもその損失は、あなたがおそらく重視しているであろうプライバシー志向のオーディエンスに集中している。

ブラウザが触れる前にクリックを記録する

信頼できる解決策は、計測のタイミングを前倒しすることだ。遷移先のページとそのスクリプトが読み込まれるより前、リダイレクトの時点でクリックを捕捉する。短縮リンクはまさにそれを行う。誰かがgo.acme.com/springをクリックすると、リダイレクトがサーバーサイドで解決し、クリック、キャンペーン、遷移先、タイムスタンプを記録してから、初めてブラウザを先へ送り出す。Firefoxがランディングページでクエリパラメータを削除したり、Braveがそこでスクリプトをブロックしたりするのは、クリックがすでにカウントされた後の出来事だ。トラッキングデータはリダイレクトの中に存在していたのであって、ブラウザが削除できるクエリ文字列の中にはなかった。

短縮リンクが、遷移先のページが読み込まれる前にリダイレクトでクリックをサーバーサイドで記録する様子。後でブラウザがUTMパラメータを削除しても、クリックは記録として残る

正直に言っておくべき点もある。これは、Braveのスクリプトブロックが同時に壊しているページ内の行動分析までは回復しない。GA4がブロックされていれば、そのページ上のセッションデータやイベントデータは依然として影響を受ける。短縮リンクが回復するのは集客のシグナルだ。クリックが起きたという事実と、どのキャンペーン経由だったかという情報である。ほとんどのアトリビューションの課題にとって、消えていたのはまさにこの数字だ。そしてこれは、ダークソーシャルを計測可能にしているのと同じサーバーサイドの原理でもある。クリックは、ブラウザのプライバシー層が届かない場所で記録される。

UTMパラメータは、それを尊重するブラウザのためにそのまま使い続ければよい。そのうえで短縮リンクでラップしておけば、パラメータが削除された場合でもクリックはカウントされる。キャンペーンリンクをラップしておけば、プライバシー重視ブラウザの分がレポートから消えることはなくなる。

やるべきこと

ランディングページのUTMを唯一の正解として扱うのをやめる。今や設計上、損失が発生するものだからだ。
キャンペーンリンクをタグ付きの短縮リンクでラップし、リダイレクトの時点でサーバーサイドにクリックを記録する。
短縮リンクのクリック合計をGA4と突き合わせ、プライバシー重視ブラウザによる損失の実際の規模を見積もる。
UTMはそのまま使い続ける。死んだわけではなく、単独では十分でなくなっただけだ。

コーナーストーン記事を読む

本稿はengineeringクラスターに属する。関連記事はSafari ITP後のクリックアトリビューション、タグそのものについてはUTMパラメータとは：完全ガイドだ。

ブログ内の関連記事

よくある質問

FirefoxとBraveはUTMパラメータを削除しますか。

Firefoxは、Strictモードにおいて削除する。クエリパラメータストリッピング機能が、一部のutm_値を含む既知のトラッキングパラメータを、ページが読み込まれる前にURLから取り除く。Braveは事情が異なり、パラメータ自体はほとんど削除しない代わりに、それを読み取るはずのアナリティクススクリプト(GA4など)をブロックする。結果はよく似ていて、UTMベースのアトリビューションが壊れる。ただし、そのメカニズムは2つとも異なる。

UTMのトラッキングデータが消えてしまうのはなぜですか。

原因はプライバシー重視のブラウザだ。Firefox Strictモードはトラッキング用のクエリパラメータを削除し、Braveはそれを解析するアナリティクススクリプトをブロックし、Safariには独自のストレージ制限がある。これらを合わせると、プライバシー重視のブラウザは訪問者のかなりの割合を占め、一般的には5分の1〜4分の1程度と見積もられている。そのため、UTMタグ付きクリックの一部は、タグが失われた状態、またはそれを読み取るスクリプトがブロックされた状態で到着する。

ブラウザがUTMパラメータを削除する中で、キャンペーンを追跡するにはどうすればよいですか。

遷移先のページが読み込まれる前にクリックを記録することだ。短縮リンクはリダイレクトの時点でサーバーサイドで解決し、その瞬間にクリック、キャンペーン、遷移先を記録する。これは、ブラウザがクエリパラメータを削除したり、ランディングページ上のスクリプトをブロックしたりするより前のタイミングだ。トラッキングデータはリダイレクトの中にあり、ブラウザが削除できるクエリ文字列の中にはない。

UTMパラメータの削除は、すべてのブラウザに影響しますか。

同じようには影響しない。Chromeはデフォルトでは削除しないため、大半のトラフィックは今もUTMを保持している。ロスが集中するのはFirefox(Strict)、Brave、Safariだ。この3つを合わせたシェアはキャンペーンレポートを歪めるほど大きいため、ランディングページのUTMだけに頼っている場合、どのキャンペーンでもクリックの無視できない割合が過小計測されていると考えておくのが安全だ。

サーバーサイドのトラッキングは、UTM削除に対する答えになりますか。

はい、リダイレクトの時点でクリックをサーバーサイドで記録するのが、最も信頼できる答えだ。ブラウザが遷移先のURLやそのスクリプトに触れる前にクリックを捕捉するため、パラメータの削除やスクリプトのブロックによって消されることがない。誰かを匿名でなくすわけではなく、ブラウザのプライバシー機能が届かない地点に計測を移動させているだけだ。

Elidoを試す

URLを貼り付けて短縮リンクを取得

登録不要。リンクは30日間有効。永久に保存するには登録してください。

Free、登録不要 · 1日あたり2件