GA4 キーイベントの設計思想と実装プロセス

GA4 キーイベントの 設計思想と実装プロセス Googleアナリティクス4 完全入門 — 「コンバージョン」の概念をアップデートする

「コンバージョン」という概念の終わり [旧] コンバージョン (Conversions) 特別なゴールとして、通常のユーザー行動からは 完全に独立して処理される特殊なデータ。 [新] キーイベント (Key Events) すべてのユーザー行動 (イベント) というフラットなデータ群の中から、 ビジネス成果に直結する「特に重要な行動」として指定された指標。 単なる名称変更ではありません。すべてを「イベント」として等しく扱うGA4の基本思想の表れです。

キーイベントとは 「目印をつけたイベント」に過ぎない first_visit page_view scroll purchase キーイベントという特別なオブジェクトが 新しく生成されるわけではありません。 GA4では、実態はあくまで「イベント」です。 管理画面上のトグルスイッチをONにして「目印 (マーク)」をつけたイベントだけが、内部でキー イベントとして処理・可視化されます。

GA4管理画面では、過去のデータに遡及して集計されない ★マークをONにした瞬間 過去のイベントデータは 遡及してキーイベント化されない 目印を付けた時点から 計測・集計が開始される 過去の成果を見落とさないためにも、実装初期段階での正確なキーイベント設定が不可欠です。

GA4管理画面とBigQueryにおけるデータ保持仕様の違い ON GA4管理画面 (UI) 仕様: 「フラグ」が存在する。 挙動: UI上でトグルをONにすると、ダッシ ュボード上で独立した「キーイベント数」な どの指標として可視化される。 BigQuery (生データ) 仕様: 「フラグ」は存在しない。 挙動: すべて一律の「イベント (行データ)」 として格納される。専用カラムや判別用のフ ラグは一切エクスポートされない。 結論: BigQueryの生データを見ただけでは、どれがキーイベントかを判別することは不可能です。

BigQueryではSQLを用いて「自己定義」を行う SELECT * FROM `project.dataset.events_*` WHERE event_name = '対象のイベント名' BQ側ではすべてが対等な「イベント」です。 集計する側のクエリ (条件指定) によって、 キーイベントとしての処理を実現します。 【逆転のメリット】 BigQueryには「キーイベントのフラグ」とい う概念がないからこそ、クエリの書き方次第 で過去のデータに遡ってキーイベントとして 集計・分析することが可能です。

ビジネスモデルに基づくカウント方法の戦略的選択 1 2 イベントごとに1回 (Once per event) ロジック: 発生の都度、すべて実数として カウント。 適したケース: ECサイトの「購入」。1セッ ションで2回購入した場合、2つの価値が生 まれるため両方カウントするのが自然。 1 セッションごとに1回 (Once per session) ロジック: 同一セッション内の重複を排除し、 最初の1回のみカウント。 適したケース: BtoBの「資料請求・会員登 録」。リロードや連打によるデータ膨張を 防ぎ、「1訪問あたり1件の成果」として正確 に評価する。

実装プロセスの全体像は2つのルートに分岐する ルートA: GA4管理画面からの設定 (カスタムイベントの作成) ルートB: Google タグ マネージャー (GTMからの設定) 最終ステップ どちらの手法を選んでも、最終的 には必ず「GA4管理画面で対象イベント の★マーク (トグル) をONにする」 プロセスが必須となる。

特定ページへの到達を計測するカスタムイベントの解剖図 一致する条件 カスタムイベント名: view_book_top 成果がひと目で分かる 小文字の名前にする パラメータ: event_name 演算子: 次と等しい 値: page_view AND パラメータ: page_location 演算子: 次と等しい 値: [計測URL] 「event_nameもパラメータ？」 ここが最大の混乱ポイントです。 GA4のシステム内部では、ベースと なる『イベント名』自体もパラメータの 一種として扱われるため、両方とも パラメータ欄に入力します。

URL指定における完全一致の罠と回避策 設定条件: 次と等しい (完全一致) example.com/thanks example.com/thanks example.com/thanks?ref=top 推奨する回避策 パラメータ付与の可能性があるページを 対象にする場合は、演算子を「次を含 む」や「次で始まる」に変更し、URLの 一部を指定するのが最も確実です。 【計測漏れ】 1文字でも違うと弾かれる

Google タグ マネージャー (GTM) を用いた設定アプローチ Step 1: トリガー 指定ページ到達時に発火 させる条件を設定。 Step 2: タグ GA4イベント発火。 パラメータとして値「1」を 設定 (GA4での集計を容易 にするテクニック)。 Step 3: GA4へ送信 GA4へデータを転送し、 管理画面で★をONにする。 警告: GTMのプレビュー機能を利用して、タグが正確に発火するかを必ず事前に検証してください。

探索レポートによる計測データの検証レシピ 日付 イベント名 イベント数 セッション 2023.06.10 イベント名 1,350 1,302 2023.06.12 イベント名 225 1,013 2023.06.13 イベント名 256 934 2023.06.16 イベント名 128 467 2023.06.17 イベント名 21 400 レポート形式 時系列 ディメンション 日付、イベント名 指標 イベント数、セッション フィルタ イベント名[含む] [キーイベント名] 設定後は放置せず、必ず探索レポートを構築して、 データが正しく計測・集計されているかを確認する習慣をつけます。

複雑な仕様を紐解く、3つの設計思想 The Identity キーイベントは特別な データではなく、 「星をつけたイベン ト」である。 The Strategy カウント方法 (イベント 単位 vs セッション単位) は、自社のビジネス目的 に合わせて使い分ける。 The Architecture BigQueryにはフラグが 存在せず、SQLの自己 定義によって過去への遡 及分析が可能となる。 GA4のフラグな設計思想を理解すれば、 計測設定は極めてシンプルで柔軟なものになります。