Back to posts

Cloudflare Web AnalyticsとGA4の違い:個人ブログでの選び方

このサイトのリニューアルで、地味に悩んだのがアクセス解析です。旧構成では Universal Analytics のIDが残ったままになっていて、UA自体の計測が終了した後もタグだけが置いてありました。要するに、しばらくの間「解析が入っているつもりで、実は何も取れていない」状態だったわけです。タグの棚卸し自体は移行作業の一部として進めていて、その洗い出しは NetlifyからCloudflare Pagesへ移すときのチェックリスト にまとめました。

置き直すにあたって候補になったのが、移行先の Cloudflare が提供する Web Analytics と、今の Google アナリティクスである GA4。調べてみると、この2つは「アクセス解析」という同じ括りでも、設計思想がかなり違います。この記事では、その違いと、個人ブログではどう選ぶかを整理します。

前提として、このサイトで解析に求めるのは「どの記事が読まれているか」と「どこから来たか」が分かることくらいです。広告を運用しているわけでも、商品を売っているわけでもありません。その前提での選び方として読んでください。

まず結論:見るものが違う

ざっくり言うと、Cloudflare Web Analytics は「ページがどれくらい・どう見られたか」を軽く測る道具で、GA4 は「訪問者がサイトの中で何をしたか」を追う道具です。

要点: 違いは機能の多い少ないではなく、計測の単位です。Web Analytics はページビュー中心、GA4 はイベント中心。欲しい情報がどちら側にあるかで選ぶのが先で、ツールの優劣の話ではありません。

計測方式の違い

どちらも、基本的にはブラウザで JavaScript を実行してデータを送る「ビーコン型」です。サーバーのアクセスログを集計する方式ではないので、JavaScript が動かない環境ではどちらも計測できません。

違いが出るのは設置と中身です。

Cloudflare Web Analytics は、専用の小さなスニペット(beacon)をページに入れるだけです。サイトが Cloudflare のプロキシ経由、あるいは Cloudflare Pages で配信されている場合は、エッジ側で自動挿入もできます(Pages ならダッシュボードからワンクリックで有効化)。計測にはブラウザの Performance API を使っていて、ページビューや表示速度といった「ページ単位」の情報を集める作りです。公式ドキュメントでは、訪問者の個人データは収集・利用しないと明記されています。

GA4 は Google タグ(gtag.js)を入れます。こちらはページビューも「イベント」の一種として扱い、クリック、スクロール、ファイルのダウンロード、サイト内検索など、訪問者の行動をイベントとして記録していくのが基本形です。さらに Cookie を使って「同じ人の再訪問か」を識別するので、セッションやユーザーの流れを追えます。

Cookieとプライバシーの違い

ここが両者の一番大きな分かれ目です。

項目Cloudflare Web AnalyticsGA4
Cookie使わない(localStorage 等のクライアント側の状態も使わない)ファーストパーティ Cookie を使う(_ga でユーザーを識別)
個人の識別しない設計。再訪問者を同一人物として追わないCookie でユーザーを区別し、セッションや再訪問を追える
同意バナーの要否解析のためだけなら、原則として不要地域や運用方針によっては同意取得の検討が必要
流入元の記録リファラー、国、デバイス、ブラウザ等左記に加え、キャンペーン(utm)単位の分析が本領
表示速度の指標Core Web Vitals など実ユーザー計測(RUM)が標準ページ速度のレポートはあるが主役ではない
イベント/コンバージョンほぼ取れない(ページビュー中心)イベントを自由に定義でき、キーイベント(旧コンバージョン)として集計できる
導入の手間スニペット1つ、またはエッジで自動挿入タグ設置+イベント設計が必要になると一気に重くなる
向いているサイト読まれる量と速度を見たいブログ・静的サイト広告・販売・会員導線など「成果」を追うサイト

注意: Web Analytics の「Cookie を使わない」は、計測のために読み手の端末へ何も残さない、という意味です。サイト側に別途 Cookie を使う仕組み(広告タグなど)を入れれば話は変わります。プライバシーポリシーの書き方は、解析ツール単体ではなくサイト全体で判断してください。

GA4 が Cookie を使うのは欠点ではなく、「同じ人が戻ってきた」ことを知るための仕様です。公式ヘルプでも、_ga Cookie はユーザーを区別するためのものと説明されています。逆に言うと、再訪問かどうかを知りたくないサイトでは、その分だけ余分なものを持ち込むことになります。

取れる指標の差:イベントが必要かどうか

選び方を決めるのは、結局ここです。

Web Analytics で見られるのは、ページビュー、訪問数、流入元(リファラー)、国、デバイス、ブラウザ、そして Core Web Vitals を含む表示パフォーマンスです。「先月より読まれたか」「どの記事が伸びているか」「表示が遅くなっていないか」を見るには、これで足ります。むしろ画面がシンプルで、開くたびに迷いません。

一方、こういう問いには Web Analytics では答えられません。

  • 記事末尾のリンクはどれくらいクリックされているか
  • お問い合わせや申し込みといった「成果」が何件あったか
  • 広告キャンペーンごとに、来た人がどこまで読んだか

これらは全部イベントの話で、GA4 の担当です。GA4 は任意のイベントを定義して、重要なものを「キーイベント」として集計でき、Google 広告とも連携できます。サイトで何かを売ったり、広告の費用対効果を見たりするなら、GA4(あるいは同種のツール)はほぼ必須になります。

どちらの数字も「欠ける」ことは知っておく

どちらのツールも、表示される数字が実訪問そのものではありません。欠け方に違いがあります。

  • 広告ブロッカー・トラッキング防止:どちらの計測スクリプトもブロック対象になりえます。ブロックされた訪問は、どちらの画面にも出てきません
  • JavaScript 無効・ボット:ビーコンが動かないので計測されません。アクセスログに残るアクセスとは数字が合いません
  • GA4 側の追加要因:Cookie の保持はブラウザの制限を受けます(公式ヘルプでは、再訪問がない場合 Chrome で最大400日、Safari で7日といった上限が示されています)。同意を取っていない訪問者をどう扱うかでも数字は変わります
  • Web Analytics 側の追加要因:Cookie に依存しないので同意の有無で減りませんが、そもそも「個人を追わない」設計なので、ユニークユーザーのような指標は近似の範囲を出ません

実感ベースの注意: 2つのツールを併用すると、ページビュー数だけでもそこそこズレます。これはどちらかが壊れているのではなく、計測条件が違うためです。「数字が合わない」こと自体を問題にし始めると、解析を見るのが嫌になります。

個人ブログでの落としどころ

このサイトの前提(読まれる量と流入元が分かれば十分)で整理すると、選び方はこうなります。

  1. 成果(申し込み・購入・広告効果)を追う予定がない → Cloudflare Web Analytics だけで十分。タグも軽く、同意バナーの検討も解析分については不要になります
  2. 将来、イベント計測や広告連携をしたくなりそう → GA4 を軸にする。ただしイベント設計を最初から頑張りすぎない。まず標準の計測だけ入れて、必要になった時点で設計する方が続きます
  3. Cloudflare に移行するついで → Pages なら Web Analytics はワンクリックで有効化できます。「まず入れて、眺めてから考える」ができるのは地味に大きいです

両方入れる場合の注意

併用自体は可能で、実際に両方入れているサイトも多いと思います。その場合に気をつけるのは次の点です。

  • 役割を先に分ける:「量と速度は Cloudflare、行動と成果は GA4」のように、どちらの数字を正とするかを決めておく。決めないと、見るたびにズレに悩みます
  • タグの管理場所を揃える:片方はテンプレート直書き、片方はタグマネージャー、のように散らかると、リニューアル時にまた「残ったままのタグ」が生まれます。旧 UA の二の舞いです
  • 重さは合計で見る:計測タグは1つ1つは軽くても積み重なります。静的サイトの速さを売りにしているのに解析タグで落とすのは本末転倒なので、入れた後に表示速度を確認するところまでをセットにする

このサイトでは

このサイトは Cloudflare Pages への移行にあわせて、まず Web Analytics を有効化するところから始めることにしました。理由は単純で、今の自分が見たいのは「どの記事が読まれているか」と「表示が遅くなっていないか」だけだからです。イベント計測が欲しくなる場面が出てきたら、そのときに GA4 の追加を検討します。解析は「とりあえず高機能な方を入れておく」より、「自分が実際に開く方」を選んだ方が、結果として長く続きます。

旧 UA の件で学んだのは、解析ツールは入れることより、入れっぱなしにしないことの方が大事だということです。どちらのツールを選んでも、移行やリニューアルのたびに「今のタグは生きているか」を確認する。それだけは、ホスティング移行後の確認リスト:当日・数日・数週間で見るもの に入れておこうと思います。

参考