GA4 高度設定の実践：イベントトラッキングとコンバージョンファネル完全ガイド

2023 年 7 月 1 日、Google は Universal Analytics のデータ収集を完全停止した。その朝、管理画面を開いて UA レポートの途切れた折れ線を見たとき、頭に浮かんだのはひとつだけ——GA4、結局どう使えばいいのか。

UA から移行して基本タグだけ入れた状態で、GA4 の画面を見て途方に暮れているなら、安心してほしい。同じ境遇のサイト運営者は多い。ページビューは見えても、どのボタンがクリックされたか、記事をどこまで読んだか、どのステップで離脱したか——本当に価値あるデータは、ひとつも取れていない「裸の状態」になっている。

この記事では GA4 とは何かは語らない。実践に踏み込む：イベントトラッキングでユーザー行動を可視化する方法、コンバージョンファネルで離脱ポイントを見つける方法、そして深い分析が必要なら BigQuery にデータをエクスポートして SQL でクエリする方法。3 つのイベントタイプから始めよう。

一、GA4 イベントトラッキングの 3 タイプ

GA4 のコアロジックは UA とまったく違う。UA は「セッション + ページビュー」モデル、GA4 は「すべてがイベント」。

よく聞くこの一文、具体的には何を意味するか。シンプルに言えば、ページ閲覧もボタンクリックも動画再生も、ページ最下部までのスクロールも、すべて独立した「イベント」として記録される。

ただしイベントは自由に作れるわけではない。Google は 3 カテゴリに分けており、それぞれ用途と制限が異なる。

1. 自動イベント（Enhanced Measurement）：すぐ使える

GA4 が提供する「無料ランチ」。データストリーム作成時にデフォルトで Enhanced Measurement が有効になり、7 種類のインタラクションを自動追跡する：

• ページ閲覧（page_view）
• スクロール（scroll）——ただし 90% スクロール深度のみ
• 外部リンククリック（click）
• サイト内検索（search）
• 動画インタラクション（video_start、video_progress、video_complete）
• ファイルダウンロード（file_download）
• フォームインタラクション（form_start、form_submit）

一見充実しているが、落とし穴がある。スクロール追跡はページ 90% 到達時のみ記録される。記事を最後まで読んだ人数や、50%、75% などの読了進捗を追いたい場合、Enhanced Measurement では不可能——GTM で自前設定が必要。

私のおすすめ：Enhanced Measurement は ON のまま、過信はしない。基礎データはくれるが、本当に価値ある行動データは自分で仕込む。

2. 推奨イベント：Google の台本に沿う

Google は業界別に「推奨イベント」を定義している。EC なら add_to_cart、begin_checkout、purchase、コンテンツサイトなら sign_up、login、share など。

メリットは、正しいイベント名とパラメータを使えば GA4 が対応レポートを自動生成すること。purchase を使えば購入関連レポートが出る。

ただし推奨イベントは自動では発火しない。サイトにコードを追加するか GTM で設定する必要がある。イベント名とパラメータは Google 規格に厳密に従う。

ブログでよく使う推奨イベントの例：

イベント名	トリガー	主要パラメータ
sign_up	ユーザー登録成功	method（登録方法）
login	ログイン成功	method（ログイン方法）
share	コンテンツ共有	content_type、item_id

自分のブログでは sign_up で購読行動を追跡している。最初 signUp（キャメルケース）と書いたら GA4 が認識しなかった——推奨イベントは snake_case 必須、1 文字のズレも許されない。

3. カスタムイベント：自由だがコストあり

Google の推奨リストにない行動を追うなら、自分で定義する。例えば「記事を読み終えた」を追跡する article_read_complete イベント。

自由度は高いが、制約もある：

1. パラメータ上限：1 イベント最大 25 個のカスタムパラメータ。Simo Ahava（GA4 分野の権威）の検証では、25 個超のデータも BigQuery にはエクスポートされるが、GA4 ネイティブレポートでは無視される。

2. 命名規則：英字・数字・アンダースコアのみ、先頭は英字。推奨イベントと揃えて snake_case を推奨。

3. レポート遅延：カスタムイベント設定後、レポート反映まで 24〜48 時間かかることがある。設定ミスと決めつけず、まず待つ。

設定優先順位：シンプルな判断フロー

どのタイプを使うか迷ったら、この順で決める：

1. Enhanced Measurement にないか確認——すぐ使えるならそれが最優先
2. 推奨イベントリストを確認——規格に沿えばレポート自動生成
3. どうしても必要ならカスタム——自由度は高いがメンテコストも高い

正直、多くのブログは Enhanced Measurement + 推奨イベント数個で十分。カスタムイベントは深い分析ニーズがある人向け。

二、イベントトラッキング実践設定

3 タイプの違いがわかったら、次は手を動かす。

GA4 イベント設定の主流は 2 つ：Google Tag Manager（GTM）、またはページに gtag.js を直接記述。GTM を推奨——学習コストはやや高いが、後からトリガー条件を変えても再デプロイ不要。

GTM で GA4 イベントを設定：4 ステップ

「ブログ記事の読了」を追跡する場合の流れ：

ステップ 1：GA4 Event Tag を作成

GTM で新規 Tag、タイプは Google Analytics: GA4 Event。Measurement ID を入力し、イベント名に article_read_complete。

ステップ 2：Trigger を設定

GTM に「いつ発火するか」を教える。

読了追跡ではスクロールトリガーが定番：ページ 90% スクロールで発火。Trigger タイプ Scroll Depth、Vertical Scroll Depths を 90% に。

細かい点：ブログに「読了プログレスバー」があると GTM のスクロール追跡と競合することがある。以前、ページ上部のプログレスバーでスクロールイベントが乱発し、データがノイズだらけになった。対策として、同一ユーザー・同一記事では 1 回だけ発火する制限を追加した。

ステップ 3：Event Parameters を追加

パラメータがイベントの本体。読了したことだけでは不十分——どの記事か、カテゴリ、著者が必要。

Tag 設定で Event Parameters を追加：

パラメータ名	値	説明
article_title	{{Page Title}}	記事タイトル
article_category	{{Custom JS Variable}}	記事カテゴリ（JS で抽出）
reading_time	{{Custom JS Variable}}	推定読了時間

パラメータ値の型は一貫させる。reading_time が数値なら常に数値。5 と "5分" を混在させると、GA4 は別パラメータとして扱う。

ステップ 4：Debug で検証

設定したらすぐ公開せず、GTM Preview でテスト。ブログを開き 90% までスクロールし、GA4 DebugView にイベントが届くか確認。

DebugView は GA4 の Configure > DebugView で確認。イベントが来なければ Trigger 条件、パラメータが空なら Variable 設定を疑う。

GTM を使わない場合：gtag.js 直接設定

Astro や Hugo など静的サイトジェネレーターを使い、GTM の複雑さを避けたいなら gtag.js 直接でも可。

// 在页面加载完成后执行
window.addEventListener('load', function() {
  // 滚动到 90% 时触发
  window.addEventListener('scroll', function() {
    var scrollPercent = (window.scrollY / (document.body.scrollHeight - window.innerHeight)) * 100;
    if (scrollPercent >= 90 && !window.articleReadTracked) {
      window.articleReadTracked = true;
      gtag('event', 'article_read_complete', {
        'article_title': document.title,
        'article_category': document.querySelector('meta[name="category"]')?.content || 'unknown',
        'reading_time': parseInt(document.querySelector('meta[name="reading-time"]')?.content || 0)
      });
    }
  });
});

GTM 設定と同じこと：90% スクロールで article_read_complete を送信。違いはコードがページに固定され、変更には再デプロイが必要な点。

よくある落とし穴（すべて経験済み）

落とし穴 1：イベント命名が非規格

articleReadComplete、article-read-complete、article_read_complete——GA4 では 3 つの別イベント。snake_case に統一し、Google 公式と揃える。

落とし穴 2：パラメータ値の型がブレる

今日 reading_time: 5、明日 reading_time: "5 minutes"、明後日 reading_time: true。GA4 は 3 つを別パラメータとして扱い、レポートが混乱する。

落とし穴 3：Consent Mode v2 でイベントがフィルタされる

EU 向けサイトで Google Consent Mode v2 を有効にしていると、Cookie 拒否ユーザーでは一部イベントが送信されない。設定ミスではないが、レポートデータは「縮む」——問題ないと思い込まないこと。

落とし穴 4：予約語をイベント名・パラメータ名に使う

page_view、session_start、first_visit は GA4 予約イベント名。カスタムイベント名に使わない。パラメータにも予約語リストがあるので、設定前に公式ドキュメントを確認。

ブログ向け実践例

ブログシナリオでよく使うイベント設定：

行動	イベント名	主要パラメータ
記事読了	article_read_complete	article_title、category、author
コメント送信	comment_submit	article_title、comment_length
購読ボタンクリック	newsletter_click	button_location、article_title
目次ナビクリック	toc_click	section_title、article_title

これらを設定すれば、GA4 でブログ上の実際のユーザー行動が見える。次は行動データの分析——コンバージョンファネルの出番。

三、コンバージョンファネル設定と分析

イベントトラッキングが整ったら、核心の問い：「初回来訪」から「目標行動の完了」まで、どこで何人が離脱したか。

それがコンバージョンファネルの役割。

GA4 の Funnel Exploration は UA よりはるかに強力。UA のファネルは固定的だったが、GA4 では各ステップをカスタマイズし、セグメント比較や離脱時間分析ができる——有料ツール級の機能が無料版に入っている。

最初のコンバージョンファネルを作る

GA4 で Explore > Funnel Exploration を開く。空のファネルテンプレートが表示される。

まず「ファネルステップ」を定義。最大 10 ステップだが、ブログでは通常 4〜5 ステップで十分。

ブログ購読ファネルの例：

1. ステップ 1：記事ページ閲覧（event: page_view、条件：page_location に /posts/ を含む）
2. ステップ 2：購読ページ訪問（event: page_view、条件：page_location に /subscribe を含む）
3. ステップ 3：購読フォーム送信（event: newsletter_signup）
4. ステップ 4：確認メール開封（event: email_opened）——メールシステム側の追跡が必要

ステップ定義のコツ：各ステップの条件はシンプルに。複雑な条件の組み合わせはファネルデータの解釈を難しくする。

ファネル分析：離脱ポイントを特定

ファネル設定後、各ステップのコンバージョン率と離脱人数が見える。

ブログ購読ファネルの例：

ステップ	ユーザー数	コンバージョン率（前ステップ比）
記事ページ閲覧	10000	-
購読ページ訪問	800	8%
購読フォーム送信	240	30%
確認メール開封	180	75%

一目でわかる：最初の離脱は「記事ページ → 購読ページ」、8% しか進まない。購読入口が目立たないか、導線の位置が悪い可能性。

2 つ目の離脱は「購読ページ → フォーム送信」、30%。フォームが長い、または購読の価値提案が弱いかもしれない。

離脱ポイントが見えたら、セグメント比較で離脱にパターンがないか調べる。

セグメント比較：「誰が」離脱しているか

Funnel Exploration はセグメント（Segments）追加で、ユーザーグループ間のコンバージョン差を比較できる。

よく使うセグメント軸：

• 新規 vs リピーター：新規はコンテンツ価値を知らないためコンバージョン率が低い傾向
• モバイル vs PC：モバイルはフォーム入力体験が劣りやすい
• 流入チャネル：検索 vs SNS

新規とリピーターの購読ファネル比較例：

ステップ	新規コンバージョン率	リピーターコンバージョン率
記事ページ → 購読ページ	5%	15%
購読ページ → フォーム送信	25%	40%

リピーターは各ステップで高い——当然、コンテンツを既に評価している。新規の「記事 → 購読ページ」が 5% なら、購読入口に気づいていない。

この発見を受け、記事末尾に目立つ購読カードを追加したところ、新規コンバージョン率は 5% から 12% に上がった。

Open Funnel：多様なユーザーパスを分析

Funnel Exploration のデフォルトは「線形ファネル」：順番通りに各ステップを完了したユーザーのみカウント。

実際の行動はもっと自由。購読ページをスキップして記事下部から直接購読する人もいる。確認メールを開いたあと記事に戻る人もいる。

GA4 の「Open Funnel」モード：順序を強制せず、ステップを完了した時点でそのステップに入る。

Open Funnel で「非典型パス」が見える。購読ユーザーの 15% は専用購読ページを経由せず、記事下部から直接送信していた——記事下部の入口の方が専用ページより効果的。記事下部の購読体験改善に注力すべき、という示唆になる。

ファネル分析のよくある誤解

誤解 1：最終コンバージョン率だけ見る

最初から最後までの「総コンバージョン率」も重要だが、中間ステップの離脱こそ改善の鍵。「1.8% が購読完了」だけでなく「どのステップで 92% が離脱したか」を見る。

誤解 2：時間軸を無視

Funnel Exploration では「コンバージョン時間」——最初のステップから最終完了までの所要時間——を設定できる。「閲覧 → 注文 → 支払い」で 7 日かかるなら、意思決定サイクルが長い。信頼構築やリマインド施策が必要かもしれない。

誤解 3：データ不足で分析

ファネル分析には十分なデータ量が必要。ステップが数十ユーザーしかいないと、コンバージョン率のブレが大きく結論が信頼しにくい。数百以上になってから深掘りを。

四、BigQuery データエクスポート実践

ここまで GA4 画面内の操作。GA4 ネイティブレポートには制限がある：データ量が大きいとサンプリングされる。月間 50 万 PV のブログでも、レポートは 10% サンプルベースのことがある。

サンプリング自体は悪くない——レポート読み込みを速くする。ただし精密なコンバージョン率分析や、10 以上のディメンション組み合わせには不向き。

そのとき BigQuery エクスポートが活きる。

BigQuery エクスポート設定：3 ステップ

BigQuery は Google のデータウェアハウス。GA4 データをエクスポートすれば SQL で全量データをクエリでき、サンプリング制限を受けない。

設定手順：

ステップ 1：BigQuery プロジェクトを作成

Google Cloud Console でプロジェクトを作成し、BigQuery API を有効化。新規ユーザーは月 10GB ストレージ、1TB クエリ処理の無料枠——ブログサイトなら十分。

ステップ 2：GA4 でエクスポートを設定

GA4 Admin の BigQuery Linking を開き Link をクリック。BigQuery プロジェクトを選択し、エクスポート頻度を選ぶ：

• Daily：前日分を 1 日 1 回エクスポート
• Streaming：リアルタイムエクスポート（数時間以内に当日データが見える）

両方 ON を推奨。Daily は長期分析向けに構造が安定、Streaming は当日データの確認向け。

ステップ 3：データが流れるのを待つ

設定後 24 時間以内にエクスポート開始。ただし落とし穴：BigQuery エクスポートに過去データのバックフィルはない。今日設定しても今日以降のデータのみ——過去 2 年分は自動では入らない。

深い分析ニーズがあるなら、早めに BigQuery エクスポートを設定。履歴データが必要になってからでは手遅れ。

BigQuery データ構造：ざっくり把握

GA4 から BigQuery へのエクスポートは 1 日 1 テーブル、命名は events_YYYYMMDD。例：events_20260429 は 2026 年 4 月 29 日のイベント。

各レコードが 1 イベント。主要フィールド：

フィールド	説明
event_name	イベント名（例：page_view、article_read_complete）
event_timestamp	発生時刻（マイクロ秒 Unix タイムスタンプ）
user_pseudo_id	匿名ユーザー ID（クロスデバイス識別）
event_params	イベントパラメータ（ネスト構造、SQL で UNNEST が必要）
geo	地理情報（国、都市）
device	デバイス情報（ブラウザ、OS、デバイスカテゴリ）

初心者がつまずきやすい点：event_params はネストフィールドで単純な列ではない。パラメータ値を取るには UNNEST で展開する。

実用的な SQL クエリ例

特定イベントのユーザー数：

SELECT
  COUNT(DISTINCT user_pseudo_id) as unique_users
FROM `your-project.analytics_123456789.events_*`
WHERE event_name = 'article_read_complete'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'

4 月に記事読了を完了したユニークユーザー数を計算。

イベントパラメータの分布：

SELECT
  param.value.string_value as article_category,
  COUNT(DISTINCT user_pseudo_id) as users
FROM `your-project.analytics_123456789.events_*`,
UNNEST(event_params) as param
WHERE event_name = 'article_read_complete'
  AND param.key = 'article_category'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'
GROUP BY article_category
ORDER BY users DESC

event_params を展開し、記事カテゴリ別の読了完了ユーザー数を集計。

BigQuery vs GA4 ネイティブ：使い分け

シナリオ	GA4 ネイティブ	BigQuery
日次トラフィックの確認	○	-
コンバージョンファネル	○	-
4 ディメンション超の組み合わせ分析	-	○
精密なコンバージョン率（非サンプリング）	-	○
Looker、Python など外部ツールへエクスポート	-	○
リアルタイム監視（当日データ）	○（Streaming）	○（Streaming）

日常レポートは GA4 画面、深い分析は BigQuery。

BigQuery のコスト管理

BigQuery はクエリ処理量で課金。ブログ規模なら通常問題ないが、節約のコツ：

1. _TABLE_SUFFIX で日付範囲を限定：全テーブルスキャンを避ける
2. WHERE で早期フィルタ：早く絞るほど処理量が減る
3. マテリアライズドビューを作成：頻繁なクエリは事前集計

自分のブログは月次データ量約 1GB、クエリ量 100GB/月以下——無料枠内。大規模サイトはコスト監視を、中小ブログは心配不要。

五、GA4 vs UA：移行者が知るべき差分

UA から移行したベテラン向けの章。

GA4 と UA の違いは UI の変更だけではない。根本ロジックが変わり、「当たり前」の概念が存在しないか、定義が変わっている。

イベントモデル vs セッションモデル

UA の中心は「セッション」：来訪、回遊、離脱——これが 1 セッション。1 セッションに複数 PV とイベント。

GA4 の中心は「イベント」：各ユーザー行動が独立した原子単位。セッションはイベントの集合に過ぎず、分析の起点ではない。

つまり：

UA では「セッション数」「セッションあたり PV 数」を見ていた。GA4 では「イベント数」「ユーザー数」が主役。

GA4 にも「セッション」概念は残るが、強調点は「ユーザージャーニー」。午前にブログを開き、午後また戻る——UA では 2 セッション、GA4 では 1 ユーザーの複数訪問。

エンゲージメント率 vs 直帰率

UA の「直帰率（Bounce Rate）」にこだわるサイト運営者は多い：低いほど良い、ユーザーが留まった証拠。

GA4 では直帰率は廃止。「エンゲージメント率（Engagement Rate）」に置き換わった。

理由：UA の直帰率定義に問題があった。1 ページだけ見て離脱＝直帰。でも 1 ページで 10 分かけて記事を最後まで読んでも、UA では直帰扱い。

GA4 のエンゲージメント率：10 秒以上滞在、または 1 つ以上のコンバージョンイベント、または 2 ページ以上閲覧で「エンゲージあり」。エンゲージメント率 = エンゲージありセッション / 総セッション数。

GA4 のエンゲージメント率と UA の直帰率を直接比較しない。対立概念ではなく、別の測定基準。

Data Streams vs Views

UA には「ビュー（Views）」：複数ビューを作り、それぞれ異なるフィルタを適用。国内トラフィックのみ、内部 IP 除外など。

GA4 にはビューがない。代わりに「データストリーム（Data Streams）」：Web、iOS App、Android App ごとに 1 ストリーム。

フィルタは「Property Filters」——UA ビューフィルタより機能は弱い。内部トラフィック・スパムの除外程度で、UA のように「別データセットを見る」複数ビューは作れない。

UA ビューでデータを分けていた場合、GA4 移行後はデータアーキテクチャの再設計が必要。BigQuery エクスポート後に自分でフィルタするか、Looker Studio で複数レポートビューを作る。

UA Goal の再マッピング

UA の「目標（Goals）」は GA4 では「コンバージョンイベント（Conversion Events）」。

設定方法も変わる。UA Goal は「特定ページ訪問」「X 分以上滞在」「イベント発火」など。GA4 コンバージョンイベントは「特定イベントの発生」のみ——ページ訪問をコンバージョンにしたいなら、まず page_view イベントを設定し、それをコンバージョンとしてマーク。

移行時は UA Goals を一覧化し、GA4 コンバージョンイベントに 1 つずつマッピング。面倒だが必須——さもないとコンバージョン履歴の継続ができない。

まとめ

要点は 4 つ：

1. イベントトラッキング：3 タイプ（自動・推奨・カスタム）を理解し、優先順位で設定
2. コンバージョンファネル：離脱ポイントを特定し、セグメント比較、Open Funnel で非典型パスを発見
3. BigQuery エクスポート：深い分析が必要なら早めに設定、過去データはバックフィル不可
4. 移行マインドセット：UA の指標を GA4 に無理やり当てはめない、新ロジックに適応

この記事を読んだあと、すぐ 1 つやるなら：GA4 を開き Enhanced Measurement が有効か確認し、3〜4 ステップのコンバージョンファネルを作ってブログ購読フローを分析する。

データは答えを自動では教えてくれない。でも問題がどこにあるかは示してくれる。あとは、その問題をどう解くか。

---

参考資料

• Set up events | Google Analytics | Google for Developers — GA4 公式イベント設定ドキュメント
• Recommended events - Analytics Help — 推奨イベント一覧
• Enhanced measurement events - Analytics Help — 自動イベントの説明
• Funnel Exploration Report in GA4 - Analytics Mania — ファネルレポート解説
• GA4 BigQuery Export Schema Tutorial - Optimize Smart — BigQuery エクスポートチュートリアル