ウェブ解析ダッシュボードに表示される数字を、そのままサイトに来た人の総数だと信じていませんか。
実はその数字は、初めからブラウザや拡張機能によって計測されなかった訪問者を除いた、部分的な集計であることが少なくありません。
本記事では、Safari や Firefox などブラウザ自身が標準で計測をブロックする仕組みと、広告ブロッカーが担う別のブロック層を整理し、なぜその欠損がランダムではなく偏っているのかを解説します。
そのうえで、自分のデータがどれくらい削れているかを疑う方法と、完璧な計測を前提にせず意思決定に使う考え方まで扱います。
広告の費用対効果を判断する立場でも、プロダクトの利用状況を追う立場でも、根っこにあるデータが欠けていれば、その上に積む意思決定はどこかで歪みます。
ブラウザ自身が計測を遮断する時代
かつて計測のブロックといえば、利用者が自分の意思で導入する広告ブロッカー拡張機能の役割でした。
しかし現在では、主要ブラウザの一部がベンダーの標準設定として、サードパーティの計測リクエストを既定でブロックするようになっています。
Safari の Intelligent Tracking Prevention（ITP）
Apple の Safari は、ITP（Intelligent Tracking Prevention）と呼ばれる仕組みで、サイトをまたいで利用者を追跡するサードパーティCookieを長年にわたりブロックしています。
サードパーティCookieに依存する計測タグは、Safariでは最初から機能しない前提で設計する必要があるということです。
さらにITPは、ファーストパーティCookieであっても有効期限を短く制限したり、URLに付いた計測用パラメータを解析コード側で読み取りにくくしたりする挙動も持ちます。
広告経由の訪問を正しく紐づけたいと考えている担当者ほど、この制約の影響を大きく受けます。
Firefox の Enhanced Tracking Protection（ETP）
FirefoxにはETP（Enhanced Tracking Protection）という仕組みがあり、既定の「標準」設定では通常ウィンドウでの主要な計測サービスの読み込みまでは止めない一方、利用者が「厳格」設定に切り替えると、既知のトラッキング用スクリプトを通常ウィンドウでも幅広くブロックします。
つまり同じFirefoxでも、利用者がどの設定を選んでいるかによって計測される・されないが分かれるということです。
プライバシー意識の高い利用者ほど「厳格」設定を選びやすいため、ここでも欠損は無作為には起きません。
Brave Shields ― 既定で最も厳格な例
ブラウザBraveは、Shieldsという遮断機能を既定でオンにした状態で配布されており、多くの既知の計測用ドメインへのリクエストを、利用者が何も設定しなくても最初からブロックします。
他のブラウザは設定を変えるほど厳しくなるのに対し、Braveは最初から厳しいという違いがあります。
Chromeは既定でブロックしていない
一方、世界で最も利用されているブラウザであるChromeは、サードパーティCookieを既定で一律にはブロックしていません。
Privacy Sandboxの終了で触れたとおり、Googleはサードパーティ Cookieの廃止方針そのものを撤回しており、利用者が自分でブラウザの設定を変えない限り、多くの計測タグはChromeでは従来どおり動作します。
つまり同じサードパーティCookieというキーワードでも、ブラウザによって既定の扱いがまったく異なるということです。
自社の訪問者がどのブラウザをどれだけ使っているかによって、遮断の影響度は大きく変わります。
Chromeは世界で最も利用者数が多いブラウザであるため、この一点だけを見れば、多くの計測はまだ動いていると言えます。
ただしそれは、Safari・Firefoxの厳格設定・Braveといった非Chrome環境の欠損を無視してよい理由にはなりません。
拡張機能とアドブロッカーという、もう一つの遮断層
ブラウザ標準機能とは別に、利用者が自分で導入する拡張機能によるブロックも根強く存在します。
この層は歴史が長く、仕組みも比較的シンプルです。
EasyList・EasyPrivacy というブロックリストの仕組み
uBlock Origin や多くの広告ブロッカーは、EasyList・EasyPrivacyという有志が保守する公開リストをもとに、通信先のドメインやURLパターンを機械的に照合してブロックしています。
google-analytics.com や googletagmanager.com のような、広く知られた計測用ドメインは典型的な収録対象です。
このリストはドメイン単位で判定するため、同じ計測の仕組みでも、どのドメインからスクリプトやビーコンを送っているかによってブロックされるかどうかが変わります。
これは後述する「ファーストパーティ計測」の考え方に直結します。
拡張機能の仕組み自体が変わりつつある
広告ブロッカーの多くは、通信を横取りして止める仕組みをブラウザの拡張機能APIに頼っています。
Chromeは拡張機能の基盤をManifest V3という新しい仕様に移行させており、この過程で、拡張機能が通信を動的に書き換えたりブロックしたりできる範囲に制約が加わりました。
これにより一部の広告ブロッカーは、あらかじめ登録した静的なルールで処理する方式へ作りを変える必要に迫られています。
遮断の仕組みが変わっても遮断そのものがなくなるわけではないため、計測側が受ける影響の性質は変わっても、影響が消えるとは考えにくいでしょう。
計測を提供する側からすれば、特定のAPIの挙動を前提に作り込むほど、こうした基盤側の変更で挙動が崩れるリスクも抱えることになります。
ブロック率は読者層によって大きく偏る
広告ブロッカーの利用率は、一般消費者向けのサービスよりも、エンジニアや開発者向けのプロダクトのように技術的なリテラシーが高い読者層で明確に高くなる傾向があります。
BtoB SaaSやデベロッパーツールを運営している場合、自社が思っている以上に計測から漏れている利用者がいる可能性を疑うべきです。
なぜこれは「ランダムな欠損」ではなく「偏った欠損」なのか
欠損が問題になるのは、それが起きる量だけでなく、起き方が偏っているからです。
ここは以前扱った生存者バイアスの構図とよく似ています。
広告ブロッカーを入れる人、Safariの厳しい制限を受け入れて使い続ける人、Firefoxで「厳格」設定をわざわざ選ぶ人には、プライバシー意識や技術リテラシーという共通の傾向があります。
つまりダッシュボードに残るのは計測を拒否する動機や手段を持たなかった人たちに寄った集団であり、全訪問者の縮小コピーではありません。
年齢層やITリテラシー、利用デバイスといった属性が計測の有無と相関しているなら、ダッシュボードの内訳そのものが実態とはずれた構成になっている可能性があります。
たとえば説明用の仮定として、月間1万セッションのうち実際には15%が何らかの形で計測をブロックしており、しかもブロックする層のコンバージョン率が非ブロック層より低いとします。
この場合、ダッシュボード上のCVRは実態よりも高く表示されることになり、広告の実質的な費用対効果を過大評価してしまう恐れがあります。
もっとも偏りは常に一方向とは限りません。
BtoB SaaSのように技術に詳しい人ほど有力な見込み客になり得る商材では、ブロックしている層の中にこそ評価が高い訪問者が紛れている可能性もあり、単純に多い側が正しいとは言い切れない点には注意が必要です。
同じロジックは、ファネルの段階が進むほど強く効いてくる場合があります。
計測ブロックに積極的な層ほど比較検討に時間をかけて複数のチャネルを比較してから決める傾向を持つとすれば、コンバージョン直前の行動ほど正しく追跡できていない可能性があるからです。
サードパーティ計測とファーストパーティ計測で、遮断のされ方が違う
すべての計測が同じように遮断されるわけではありません。
誰のドメインからリクエストが送られているかが、ブロックされやすさを大きく左右します。
なぜ第三者のドメインは狙われやすいのか
ITPやEasyListのようなブロックの仕組みは、多くの場合自社ドメイン以外の第三者へ送られる通信や、広く知られた計測ベンダーのドメインを狙って判定します。
多数のサイトに埋め込まれる汎用的な計測タグほど、ブロックリストに載りやすく、遮断の標的になりやすい構造です。
ファーストパーティ・サーバーサイド計測は万能ではない
そのため近年は、サーバーサイド計測のように、自社ドメインを経由してデータを送る構成へ寄せる動きが広がっています。
第三者ドメインへの直接通信がない分、汎用ブロックリストに機械的に載って止められる可能性は下がります。
ただしこれは遮断リスクを減らす設計であって、無条件で計測できることを保証するものではありません。
MonaLensも自社サイトと同一ドメインの収集エンドポイントを使い、Cookieを使わない計測を選んでいますが、それはブラウザやOSレベルの将来の制限まで免れる保証ではない点は誠実に伝えておくべきでしょう。
自分のデータがどれくらい削れているかを疑う方法
遮断の存在を知っていても、自社サイトでどの程度起きているかは推測するしかありません。
とはいえ、いくつかの手がかりから輪郭をつかむことはできます。
まず有効なのは、決済や申込みなど計測ツールを介さない実績データと、アナリティクス側のコンバージョン数を突き合わせることです。
実績のほうが継続的に多いなら、その差分がおおよその欠損の目安になります。
差分がゼロに近いなら、少なくとも大きな遮断は起きていないと判断してよいでしょう。
下の表は、気になる症状から疑うべき原因と確認方法を整理したものです。
| 気になる症状 | 疑うべき原因 | 確認の手がかり |
|---|---|---|
| 決済件数よりCV数が少ない | 計測タグ自体がブロックされている | 決済システムの実績とアナリティクスのCVを月次で突合する |
| 直接流入の比率が不自然に高い | リファラやUTMが計測前に失われている | 広告経由のセッションだけ抽出し流入元の内訳を見る |
| モバイルよりPCの数字が相対的に少ない | PCで拡張機能によるブロックが多い | デバイス別・ブラウザ別にセッション数を分解する |
地域・言語別の内訳も手がかりになる
自社の主要な顧客層がどの国・地域に多いかによっても、ブラウザやブロッカーの浸透度は変わってきます。
特定の地域からの流入だけコンバージョン率が不自然に低い、あるいは逆に極端に高いといった歪みが見えたら、遮断の偏りが混ざっている可能性を一度疑ってみるとよいでしょう。
海外展開をしているプロダクトであれば、国ごとに主流のブラウザや拡張機能の利用習慣が異なる点も踏まえて数字を読む必要があります。
このほか、Safariや厳格設定のFirefoxからのセッション比率が、自社の過去実績と比べて急激な低下を見せていないかを定点観測しておくことも役立ちます。
急な変化は、遮断が増えたシグナルである可能性があります。
計測ツールを選ぶときに確認しておきたい視点
ここまでの構造を踏まえると、計測ツールやタグを選定・見直しする際に確認しておきたい観点も見えてきます。
- 計測用のリクエストが自社ドメインから送られる構成になっているか
- 動作の前提としてサードパーティCookieやクロスサイトの識別子に依存していないか
- 決済や申込みの実績データと定期的に突合できる設計になっているか
これらを満たしたからといって遮断が完全になくなるわけではありませんが、汎用ブロックリストによる機械的な遮断の対象にはなりにくくなります。
MonaLensのように同一ドメインでの収集を前提にした設計は、この観点に沿った選択肢のひとつですが、それを唯一の解のように語るのは正確ではないでしょう。
大切なのは、ツールのアーキテクチャがこの構造をどう踏まえているかを、選ぶ側が理解しておくことです。
乗り換えのたびに過去データとの連続性が失われるコストも考えると、この視点は導入前に確認しておくほど価値があります。
完璧な計測を諦めて、意思決定にどう使うか
ここまで見てきたように、ウェブ解析の数字は程度の差こそあれ、常に一部の訪問者を欠いた近似値です。
完璧な答えを待つよりも、その限界を理解したうえで意思決定に使う姿勢のほうが現実的です。
重要なのは、絶対値を過信せず、同じ計測方法・同じ欠損傾向で比較できる相対的な変化を意思決定の軸にすることです。
前月比や施策前後の比較であれば、欠損の偏りがある程度打ち消し合うため、絶対数そのものよりも頼りにできます。
ブラウザの標準機能、拡張機能によるブロックリスト、そして両者が生む偏った欠損は、今後さらに強まることはあっても弱まることは考えにくい構造です。
だからこそ、数字を鵜呑みにするのではなく、どこにどんな穴が空きやすいかを知ったうえで使う姿勢が、これからのウェブ解析にはますます求められます。
冒頭の問いに戻るなら、ダッシュボードの数字は嘘をついているわけではなく、最初から一部だけを映す前提の道具だということです。