「タグの設定は正しいはずなのに、実際のユーザー数より計測が少ない気がする」——その原因のひとつが、広告ブロッカー・トラッキング防止機能による計測タグの遮断です。設定ミスではないので管理画面を見ても気づきにくく、しかもブロックしているユーザーの分だけ静かに数字が欠けていきます。
こんな心当たりはありませんか？
- 実際のサイト訪問者数の体感より、GA4のユーザー数が 少ない気がする
- サーバーのアクセスログと、GA4のセッション数が 明らかに合わない
- Metaピクセルやコンバージョンタグが、一部のユーザーで発火していない
- 技術に詳しい層・特定ブラウザのユーザーほど、計測から抜け落ちている気がする
この記事では、広告ブロッカーがピクセルやタグをどうやって弾いているのかという仕組みから、コンバージョンが過少計測になる理由、正確に把握しづらい事情、そしてどこまで緩和できるのかを、実務目線で整理します。同意モードでの拒否とは別の要因である点も切り分けます。
まず前提：広告ブロッカーは「特定のリクエストを遮断する」仕組み
つまずきやすいのは、広告ブロッカーを「広告バナーを消すだけのツール」だと思い込むことです。実際には、多くの広告ブロッカー・トラッキング防止機能は、ページから外部の計測ドメインへ飛ぶリクエストそのものを遮断します。バナー非表示は結果の一部にすぎません。
代表的なツールと、その遮断のかかり方は次のとおりです。
| ツール／機能 | 遮断のかかり方 |
|---|---|
| uBlock Origin / AdBlock などの拡張 | フィルタリストに載ったドメインへのリクエストをブロック |
| Brave Shields（ブラウザ内蔵） | 既定でトラッカーへのリクエストを遮断 |
| Firefox 強力なトラッキング防止（ETP） | 既知のトラッカーリストに基づき遮断 |
| Safari の各種コンテンツブロッカー拡張 | フィルタルールに一致するリクエストをブロック |
これらの多くは、EasyPrivacy のような公開フィルタリストを共有しています。リストには「計測・トラッキング目的として知られるドメイン」が大量に登録されており、ブラウザはページ読み込み時に、そのリストと照合してリクエストを止めます。
何が弾かれるのか：具体的なドメイン
フィルタリストで遮断対象になりやすいのは、まさに私たちが計測に使っているドメインです。
google-analytics.com… GA4の計測リクエスト（collectなど）googletagmanager.com… Googleタグマネージャー（GTMのコンテナ本体）googleadservices.com… Google広告のコンバージョン計測facebook.com/tr… Metaピクセルのイベント送信
つまり、GTMのコンテナ自体が読み込めないケースでは、その中に入っているGA4・広告・Metaのタグがまとめて動かなくなることもあります。「タグは正しく実装しているのに、特定ユーザーで一切発火しない」という現象は、多くがこれです。
つまずきやすい例： 自分のPCでNetworkタブを見て「
collectが飛んでいるからOK」と判断しても、それはたまたま自分がブロッカーを入れていないだけかもしれません。ブロッカーを有効にしたブラウザで同じページを開くと、そのリクエストが丸ごと消えることがあります。
コンバージョンが過少計測になる仕組み
広告ブロッカーの影響が厄介なのは、「エラー」として表に出ないことです。リクエストが遮断されると、ブラウザ上ではそのイベントが最初から存在しなかったかのように扱われます。タグ側から見れば「発火しなかった」だけで、警告もエラーログも残りません。
結果として起きるのが、次の2つです。
1. ブロックしているユーザーの成果が丸ごと欠落する
広告ブロッカーを使っているユーザーがコンバージョンしても、そのイベントはGoogleやMetaに届きません。実際には成果が発生しているのに、レポート上はなかったことになります。
2. 計測結果が「ブロックしていない層」に偏る
残って計測されるのは、ブロッカーを使っていないユーザーだけです。つまりレポートの数字は、母集団の一部だけを見た偏った像になります。ここが単なる「数が減る」以上に重要な点で、コンバージョン率やユーザー属性の分析まで、ブロッカー非利用層に寄って歪みます。
つまずきやすい例： 「BtoBやIT系の商材なのにGA4の数字が実感より低い」というケース。技術に詳しい層やプライバシー意識の高いユーザーほどブロッカー利用率が高い傾向があるため、業種によっては欠落の影響が大きく出ます。
どのくらいブロックされているかは、正確には分からない
ここが広告ブロッカー問題のいちばん厄介なところです。「自社サイトで何％がブロックされているか」を、計測タグ側から正確に知る方法はありません。理由は単純で、ブロックされたイベントは届かないため、そもそも数えられないからです。
利用率の数値は調査によってばらつきが大きく、ブラウザ・地域・業種・デバイスによっても変わります。だからこそ、「一律に何割」と決め打ちするのではなく、自社の状況を実測で近似する姿勢が必要です。
近似のためによく使われるのが、次の突き合わせです。
- サーバーのアクセスログ … ページ自体は配信されるので、実際の到達数に近い
- GA4などのクライアント側計測 … タグが弾かれた分だけ少なく出る
この2つの差を見れば、「どれくらいのユーザーが計測タグを遮断しているか」のおおよその規模をつかめます（ボット等の要因もあるため、あくまで概算です）。
業界ベンチマーク：どのくらいブロックされているか
万人に当てはまる数字はありませんが（オーディエンス・地域・デバイスで変わるため）、2025〜2026年の業界データは参考になります。
| セグメント | おおよその広告ブロッカー利用率 |
|---|---|
| グローバル平均（全デバイス） | ウェブセッションの25〜30% |
| デスクトップユーザー | 30〜40% |
| モバイルユーザー | 10〜15%（モバイルブラウザは拡張機能の選択肢が少ないため） |
| 技術者・開発者層 | 50〜70% |
| EU・プライバシー意識の高い市場 | 35〜45% |
コンバージョン計測への影響： セッションの25〜30%がブロックされると、プラットフォーム上では実際に発生したコンバージョンの20〜40%が計測されないのが一般的です。Metaの場合——ピクセルのドメインはフィルタリストで特に積極的にターゲットにされるため——差はさらに広がることがあります。
これらの数値は方向性を示すもので、確定値ではありません。要点は、自社のギャップ（サーバーログ vs クライアント計測）を測定していなければ、気づかないうちにコンバージョンを大幅に過少報告している可能性があるということです。
どこまで緩和できるか：サーバーサイドタグ付け
「では防げるのか」というと、完全には防げませんが、一部は緩和できます。有力なのがサーバーサイドでのタグ付けです。
通常のブラウザ計測は、ユーザーのブラウザから直接 google-analytics.com などへリクエストを送るため、フィルタリストで狙い撃ちされます。これに対しサーバーサイドタグ付けでは、まず自社の一次ドメイン（例：analytics.あなたのサイト.com）へデータを送り、そこからサーバー経由でGoogleやMetaへ転送します。
- 送信先が自社ドメインになるため、ドメイン名だけを見るフィルタでは弾かれにくくなる
- ただし万能ではありません。ブロッカー側もこの手法を認識しており、より高度なフィルタは一次ドメイン経由の計測も検知・遮断しはじめています
つまり、サーバーサイドタグ付けは「一部のブロッカーを回避できる緩和策」であって、「すべてを取り戻す解決策」ではありません。過度な期待は禁物です。
ハイブリッド方式：クライアント＋サーバーの重複排除
2026年の実務ベストプラクティスは「クライアントかサーバーか」ではなく、両方を併用し、重複排除することです。仕組みは次のとおりです。
- クライアントサイドのタグ（GA4、Metaピクセル、Google広告）は通常どおり稼働させる
- サーバーサイドの計測を並行して追加する（sGTM、Meta CAPIなど）
- 各イベントに一意の
event_id（購入の場合はtransaction_id）を付与する - 広告プラットフォームは両方の経路からイベントを受け取り、IDで重複排除する
なぜうまくいくか： ブロッカーがないユーザーでは両方の経路が発火し、プラットフォーム側で重複排除されるため二重計上は起きません。ブロッカーがあるユーザーでは、クライアント側はサイレントに失敗しますが、サーバー側は成功するためコンバージョンは捕捉されます。
MetaはCAPIについてこのパターンを明確に推奨しています。ピクセル＋CAPIを並行稼働させ、同じ event_id を送り、Meta側で重複排除させるという方法です。GoogleもEnhanced ConversionsとsGTMで同様の仕組みに対応しています。
DNSレベルのブロック：サーバーサイドでも回避できない領域
広がりつつあるブロックの一種に、ブラウザがリクエストを行う前のDNSレベルで作動するものがあります。
- Pi-hole — ネットワーク全体のDNSブロッカー。ネットワーク上のすべてのデバイスでトラッキングドメインをブロック
- NextDNS / AdGuard DNS — フィルタリスト内蔵のクラウドDNSサービス
- ブラウザ統合型DNSブロック — 一部のブラウザはトラッキングドメインを
0.0.0.0に解決
DNSレベルのブロックは、DNSサービスのフィルタリストにあなたの計測用サブドメイン（例：analytics.yoursite.com）が含まれている場合、一次ドメインへのルーティングも無力化できます。現在の利用率は低め（推定2〜5%のユーザー）ですが、プライバシー意識の高い層では増加傾向にあります。
実務的な意味： クライアントサイドのいかなる仕組みでも追跡できないユーザー層が常に存在します。対策は技術的な修正ではなく、一定の「計測できないコンバージョン」のマージンを許容する計測戦略を組み立て、合計数の真実はバックエンドデータに求めることです。
同意モードでの拒否とは別の要因
混同しやすいので切り分けておきます。「計測が減る」原因には、大きく別系統の2つがあります。
| 要因 | 何が起きるか |
|---|---|
| 広告ブロッカー | ユーザーのブラウザ側でリクエストが物理的に遮断される。サイト側の同意設定とは無関係 |
| 同意モードでの拒否 | ユーザーが同意しないため、タグの挙動が制限される。仕組み・対処法は別 |
両者は独立して起きるため、片方だけ対処しても取りこぼしは残ります。同意モード側の仕組みと確認方法は別記事にまとめています（この記事は広告ブロッカーに絞っています）。なお、SafariのITP（トラッキング防止）も、ブラウザ側で計測が減るという意味では同じ系統の要因です。
本番で「弾かれていないか」を確認する手順
手順1：ブロッカーを有効にしたブラウザで開いてみる
最も直感的な確認方法です。
- uBlock Originなどを入れたブラウザ（またはBrave）で、確認したいページを開く
- 開発者ツールの「Network」タブを開き、フィルタに
collectgoogletagmanagerfacebook.com/trなどを入力する - リクエストが 飛んでいるか／ブロックされているか を見る（ブロック時は失敗・キャンセル表示になることが多い）
- ブロッカーをオフにした状態と比べ、消えるリクエストがあるかを確認する
手順2：サーバーログとクライアント計測を突き合わせる
前述のとおり、サーバー側の到達数とGA4等のセッション数の差を見れば、遮断の規模を概算できます。厳密な数値ではなくても、「無視できない規模か、誤差の範囲か」の判断材料になります。
手元の確認だけでは分からないこと
ここまでの手順は有効ですが、自分のPCで1回試すやり方には、広告ブロッカー特有の死角が2つあります。
- 自分の環境は、本番ユーザーの環境とは違う。 テストする人の多くは、開発用にブロッカーを切っていたり、逆に常時オンにしていたりと、実際の来訪者とは条件が異なります。あなたの「1台」で見えるのは、無数にあるブラウザ・拡張・設定の組み合わせのうちのひとつにすぎません。本番のユーザーは、あなたが試していない構成でアクセスしてきます。
- 広告クリックを絡めた再現は、自己クリックの規約リスクを伴う。 「広告経由で来て、ブロッカーを入れているユーザーのコンバージョンがどう扱われるか」を厳密に見ようとすると、本来はライブ広告をクリックして経路を再現する必要があり、これは自己クリックとして広告ポリシー違反のリスクを伴います。
広告ブロッカーの取りこぼしは、「ブロッカーを切っている自分」ではなく「ブロッカーを入れている他人」の環境で起きます。手元でOKに見えることが、かえって欠落を見えなくするのです。
確実に確認するためのチェックリスト
- ブロッカーを有効にしたブラウザで、計測リクエストが飛ぶか確認したか
- GTMのコンテナ（
googletagmanager.com）自体が弾かれていないか - GA4（
google-analytics.com）のリクエストが遮断されていないか - Metaピクセル（
facebook.com/tr）が発火しているか - サーバーログとクライアント計測の差で、遮断のおおよその規模を把握したか
- 自社の業種・ユーザー層（技術系ほど利用率が高い傾向）を考慮したか
- サーバーサイドタグ付けを、万能ではない緩和策として正しく位置づけているか
- 同意モードでの拒否と、広告ブロッカーの遮断を混同していないか
よくある質問（FAQ）
Q. 広告ブロッカーで、コンバージョンはどのくらい減りますか？ A. 一概には言えません。利用率は調査によって幅があり、ブラウザ・地域・業種・デバイスで大きく変わります。だからこそ具体的な割合を決め打ちせず、自社のサーバーログとクライアント計測の差から、自社固有の規模を概算するのが現実的です。
Q. 広告バナーを出していなければ、広告ブロッカーは関係ない？ A. いいえ。多くのブロッカーは広告バナーの有無に関わらず、計測・トラッキング目的のドメインへのリクエスト自体を遮断します。GA4やMetaピクセルだけを入れているサイトでも影響を受けます。
Q. サーバーサイドタグ付けにすれば、全部取り戻せますか？ A. いいえ。一次ドメイン経由にすることで一部のブロッカーは回避できますが、すべてではありません。高度なフィルタは一次ドメイン経由の計測も検知しはじめています。あくまで緩和策として捉えてください。
Q. 同意バナーで「拒否」されたのと、ブロッカーで弾かれたのは同じですか？ A. いいえ、別の要因です。同意モードでの拒否は「ユーザーが同意しないためタグの挙動が制限される」もの、広告ブロッカーは「ユーザーのブラウザ側でリクエストが物理的に遮断される」もので、仕組みも対処も異なります。両方が同時に起きることもあります。
Q. ブロックされているかどうか、管理画面で分かりますか？ A. 分かりません。遮断されたイベントはそもそも届かないため、GA4や広告の管理画面には「欠けている」という記録すら残りません。だからこそ、ブロッカーを有効にしたブラウザでの目視や、サーバーログとの突き合わせが必要になります。
まとめ：「切っている自分」ではなく「入れている本番ユーザー」で確かめる
広告ブロッカーによる取りこぼしは、設定ミスではないため管理画面には表れず、しかもブロックしている層の分だけ静かに数字が欠けていきます。大事なのは、ブロッカーを有効にした実際のユーザー環境で、計測リクエストがどう扱われるかを、リクエスト単位まで踏み込んで確認することです。
ConversionOKは、外部の独立した実ブラウザであなたの本番ページにアクセスし、実際に送信される計測タグ・ピクセルのリクエストを傍受して検証します。自分の広告をクリックする必要も、社内環境の影響を受けることもありません。まずは無料の静的チェックで、ブロッカーが絡む前の計測の入口が生きているかを確認してみてください。
関連記事