---
title: GA4 キーイベントの設計思想と実装プロセス
tags: 
author: [渋谷TAIZI](https://docswell.com/user/4514287294)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/8EDKMW9W7G.jpg?width=480
description: GA4 キーイベントの設計思想と実装プロセス by 渋谷TAIZI
published: July 13, 26
canonical: https://docswell.com/s/4514287294/5GNWMJ-2026-07-13-230250
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/8EDKMW9W7G.jpg)

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

# Page. 2

![Page Image](https://bcdn.docswell.com/page/V7PKR9ZXJ8.jpg)

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

# Page. 3

![Page Image](https://bcdn.docswell.com/page/2JVVRMW3JQ.jpg)

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

# Page. 4

![Page Image](https://bcdn.docswell.com/page/5EGLMGDYJL.jpg)

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

# Page. 5

![Page Image](https://bcdn.docswell.com/page/4JQYRX167P.jpg)

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

# Page. 6

![Page Image](https://bcdn.docswell.com/page/K74W86RME1.jpg)

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

# Page. 7

![Page Image](https://bcdn.docswell.com/page/LJ1Y2VQYEG.jpg)

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

# Page. 8

![Page Image](https://bcdn.docswell.com/page/GJWGRLM172.jpg)

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

# Page. 9

![Page Image](https://bcdn.docswell.com/page/4EZLRMQX73.jpg)

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

# Page. 10

![Page Image](https://bcdn.docswell.com/page/Y76WRN6P7V.jpg)

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

# Page. 11

![Page Image](https://bcdn.docswell.com/page/G75M856P74.jpg)

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

# Page. 12

![Page Image](https://bcdn.docswell.com/page/9J29KNMZER.jpg)

探索レポートによる計測データの検証レシピ
日付
イベント名
イベント数
セッション
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
レポート形式
時系列
ディメンション
日付、イベント名
指標
イベント数、セッション
フィルタ
イベント名[含む]
[キーイベント名]
設定後は放置せず、必ず探索レポートを構築して、
データが正しく計測・集計されているかを確認する習慣をつけます。

# Page. 13

![Page Image](https://bcdn.docswell.com/page/DEY4NPXNJM.jpg)

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

