GA4 カスタムイベント設計の正解 — 3階層モデルで計測スキーマを堅牢化
GA4を導入して半年経った頃、レポートを開くと (not set) が増え、purchase イベントが二重計上され、なぜか同じ商品で purchase が2種類のパラメータ構造で記録されている — このような状態に陥った経験はないでしょうか。
原因のほとんどは、技術力ではなく 計測スキーマの設計時に「3階層の境界線」を引かなかったこと にあります。本記事はECサイト運営者向けに、GA4のカスタムイベント設定を 半年後・1年後にも壊れない計測スキーマとして初期構築する ための設計ガイドです。
この記事のまとめ
- GA4イベントは「自動収集 / 推奨 / カスタム」の3階層構造。各階層で送信元・編集可否・パラメータ仕様が異なり、混在させると半年後に必ず壊れる
-
ECサイトは推奨イベント12項目で計測スキーマを固める。
view_item/add_to_cart/purchaseなどをGoogle仕様通りに送ることで、標準レポート・eコマースレポート・BigQueryエクスポートの全てが整合する - カスタムイベントの命名規則を実装後に揃えるのは、計測データ全件の再設計に近い大工事。「動詞_名詞」「snake_case」「予約接頭辞回避」を設計時に決め切る
- 検証は3レイヤー：DebugViewで送信確認 → リアルタイムで集計確認 → BigQueryで構造確認
1. GA4イベントの3階層 — 計測スキーマの土台
GA4のイベントは送信元と認識方法によって3階層に分類されます。これは単なる分類ではなく、計測スキーマを設計する上で最初に引くべき境界線 です。
| 階層 | 送信元 | 編集可否 | 例 |
|---|---|---|---|
| 自動収集 | GA4タグが自動送信 | 不可（無効化のみ） |
page_view / session_start
|
| 推奨イベント | サイト側で実装・送信 | 名前固定・必須あり |
view_item / add_to_cart / purchase
|
| カスタム | サイト側で実装・送信 | 名前・パラメータ自由 |
click_hero_cta / scroll_50pct
|
EC運営者にとって最も重要な事実：ECで起こる行動はほぼ全て推奨イベントでカバーされている。カスタムイベントは「推奨では表現できない自社固有の行動」のみに限定するのが原則です。
ここを誤って「全部カスタムで送ればいい」とすると、推奨イベントとして扱えば標準レポートに自動で乗ったはずのデータが、独自指標として埋もれていきます。発見されるのは半年後、レポートが信用できなくなったタイミングです。
2. 推奨イベント実装例（gtag.js）
ECサイトで最頻出する view_item と purchase の実装例を示します。
view_item：
gtag('event', 'view_item', {
currency: 'JPY',
value: 4980,
items: [
{
item_id: 'SKU_12345',
item_name: 'Premium T-Shirt',
item_category: 'Apparel',
item_brand: 'BrandName',
price: 4980,
quantity: 1
}
]
});
purchase：
gtag('event', 'purchase', {
transaction_id: 'T_12345_67890',
currency: 'JPY',
value: 9960,
tax: 906,
shipping: 500,
items: [
{ item_id: 'SKU_12345', item_name: 'Premium T-Shirt', price: 4980, quantity: 2 }
]
});
3. カスタムイベント命名規則 — 設計時に決め切る3原則
✅ click_hero_cta (動詞_名詞・snake_case)
❌ Click Hero CTA (スペース・大文字混在で別イベント扱い)
❌ pricing_view (動詞が後ろ・視認性低下)
❌ ga_download_xxx (ga_接頭辞は予約済みで計測無効化)
予約接頭辞 ga_ / google_ / firebase_ で始まるイベント名は受信時に破棄されます。プロジェクト固有の接頭辞をつけたい場合は rs_click_cta のように2文字以下の独自プレフィックスにすると安全です。
命名規則を実装後に揃えようとすると、過去に飛んだ全イベントの再マッピング・カスタムディメンション再登録・Looker Studioのデータソース更新・BigQueryビューの書き直しが連鎖発生します。設計時の数分のコストが、後追いだと数日の大工事に化ける のはここです。
4. BigQuery で実装後の検証
GA4のBigQuery連携を有効化すると、生データが日次でエクスポートされます。event_name の表記揺れや想定外イベントの混入を SQL で直接検証できます。
-- 直近7日間のイベント名一覧
SELECT
event_name,
COUNT(*) AS event_count,
COUNT(DISTINCT user_pseudo_id) AS users
FROM `<project>.<dataset>.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260423' AND '20260429'
GROUP BY event_name
ORDER BY event_count DESC;
-- purchase の重複検出（同じ transaction_id が複数回飛んでいないか）
SELECT
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'transaction_id') AS tid,
COUNT(*) AS fire_count
FROM `<project>.<dataset>.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260423' AND '20260429'
AND event_name = 'purchase'
GROUP BY tid
HAVING fire_count > 1
ORDER BY fire_count DESC;
このクエリで fire_count > 1 の行が出た場合、その transaction_id は重複計上されています。Shopifyのサンクスページや GTM のトリガー設定を見直してください。
5. 動作検証の3レイヤー
| レイヤー | 確認内容 | タイミング |
|---|---|---|
| 1. DebugView | GA4が受信したイベント | 実装直後・秒単位 |
| 2. リアルタイム | GA4が集計対象としたイベント | 公開前・分単位 |
| 3. BigQuery | 実際に格納されたパラメータ構造 | 公開1週間後・SQL |
DebugView と Realtime の差分が、サイレント故障の発見ポイントです。
- DebugViewには表示されるが Realtime に出ない → 予約接頭辞使用の可能性
- Realtime には出るが標準レポートに出ない → カスタムディメンション未登録の可能性
「DebugViewで見えたから大丈夫」で終わらせると、集計レイヤーで静かに落ちている故障 に気付けません。3レイヤー全てで確認する習慣が、半年後の信頼性を担保します。
6. 計測スキーマの真価 — 売上分解への接続
推奨イベント12項目を正しく実装すると、GA4の標準eコマースレポートで売上・注文数・AOV まで自動で集計されます。しかし、ここで止まると「全体の売上は分かるが、どのチャネル・どのセッションが効率よく稼いでいるか」が見えません。
推奨イベントの真価は、purchase.value を セッション単位・チャネル単位 で割り戻して初めて発揮されます。Looker Studio や Tableau で RPS（Revenue Per Session = Revenue ÷ Sessions） をチャネル別に並べると、ROAS だけでは見えないチャネル間の投資効率比較が可能になります。
つまり、GA4のイベント実装は「素材集め」であって、それ自体がゴールではありません。スキーマを堅牢化することで初めて、その上に意思決定レイヤー（売上分解・チャネル比較・投資判断）が積み上がる という順序を意識すると、設計の優先順位がぶれなくなります。
まとめ
GA4のカスタムイベント設定は、技術的に難しい話ではありません。最初に「3階層の境界線」を引き、推奨イベント12項目を仕様通りに実装し、カスタムイベントの命名規則を決め、3レイヤーで検証する。この4ステップで、半年後・1年後の計測スキーマが堅牢に保たれます。
詳しい実装手順、予約パラメータの落とし穴、Shopifyの典型故障パターンは GA4 カスタムイベント設定 完全ガイド｜EC向け 自動収集／推奨／カスタムの3階層 にまとめました。
本記事は RevenueScope News に掲載した同名記事を、Zenn向けに設計思想・スキーマ視点で再編集したものです。
Discussion