「GA4のイベント設定は12項目を実装し終えた。これで測定は完了、と思っていたのに、レポートを見ても『どのチャネルが効率よく売っているか』はやっぱり分からない」——EC事業者からよく聞く声です。GA4のイベント設定は測定の起点ですが、設定が終わっても、それだけでは売上の意思決定にはつながりません。この記事では、3階層の境界線・EC推奨12項目・予約衝突の回避・検証3レイヤーまでの「設定側」を締めたうえで、そこから先の「売上接続」の壁がどこにあるかを整理します。
目次
この記事のまとめ#
- GA4イベントは3階層（自動収集／推奨／カスタム）。境界線を曖昧にすると半年後に必ず壊れます
- ECサイトは推奨イベント12項目を仕様どおりに送るのが基本。カスタムイベントは「推奨で表現できない自社固有の行動」だけに限定します
- 予約接頭辞（
ga_google_firebase_）と予約パラメータ（page_referrer等）の衝突は、実装から半年気付かないサイレント故障の主犯です - 設定→検証→売上分解→次の一手の4段ゲートで、GA4だけで自動で来られるのは2段目（検証）まで＝3段目の入口。その先の売上接続には別の仕組みが要ります
1. なぜ「設定完了」で GA4イベント設定は終わらないのか#
結論から言うと、「12項目を実装した」＝「測定できた」ですが、「売上の意思決定に使える」まではまだ届いていません。GA4のイベント設定は測定の起点で、そこから先に「検証」「売上分解」「次の一手」の段があります。
多くの現場で起こるのは、実装完了直後に「これで測定は終わり」と受け取り、レポートを開いてから「あれ、思ったより見えない」となる状態です。原因は3階層の境界線を曖昧にしたまま走り出したことにもありますが、それを直しても足りません。purchase.value を正しく取れるのと、「どのチャネルが効率よく売っているか」が見えるのは、別のレイヤーです。実装で最頻の故障は、purchase の二重計上、カスタムイベント名の表記揺れ、予約接頭辞使用によるサイレント破棄、value に文字列を入れたことによる売上0円積み上げ、の4つ。ここは技術的に潰せば直りますが、直しても売上接続の議論はまだ始まっていません。イベント数とセッション数の関係はGA4のイベント数とセッション数にまとめています。
2. GA4イベントの3階層と、EC推奨12項目#
結論から言うと、ECで起こる行動はほぼ全て「推奨イベント」でカバーされています。カスタムイベントは「推奨で表現できない自社固有の行動」だけに限定するのが原則です。
GA4のイベントは、送信元とGA4側の認識方法によって3階層に分かれます。自動収集はGoogleが定義しGoogleが送信する（page_view session_start 等・仕様固定）。推奨はGoogleが定義しサイト側が送信する（view_item add_to_cart purchase 等・仕様あり）。カスタムはサイト側が定義しサイト側が送信する（自社固有・予約接頭辞NG）。ECで実装すべき推奨イベントは、ユーザー行動のステップ順に12項目に整理できます。
| カテゴリ | イベント名 | 送信タイミング | 必須パラメータ |
|---|---|---|---|
| 閲覧 | view_item_list | カテゴリ一覧・検索結果 | item_list_id / items[] |
| 閲覧 | view_item | 商品詳細表示 | currency / value / items[] |
| 閲覧 | select_item | 一覧から商品クリック | item_list_id / items[] |
| カート | add_to_cart | カート追加 | currency / value / items[] |
| カート | view_cart | カートページ | currency / value / items[] |
| カート | remove_from_cart | カートから削除 | currency / value / items[] |
| 購入導線 | begin_checkout | チェックアウト遷移 | currency / value / items[] |
| 購入導線 | add_payment_info | 支払情報入力完了 | currency / value / payment_type / items[] |
| 購入導線 | add_shipping_info | 配送情報入力完了 | currency / value / shipping_tier / items[] |
| 購入 | purchase | 購入完了 | transaction_id / currency / value / items[] |
| 返金 | refund | 返品処理完了 | transaction_id / currency / value |
| 検索 | search | サイト内検索 | search_term |
事故が最多なのは purchase です。transaction_id が空文字や重複だとGA4の重複排除が効かず売上が二重計上されます。Shopifyのサンクスページ実装で purchase が「サンクスページ表示」と「アプリ側CV計測」の両方から発火する事故は最頻出です。具体対策はGA4 eコマース設定（Shopify編）にまとめています。
3. カスタムイベント設計と予約衝突の回避#
結論から言うと、カスタムイベントは「実装する前」に命名規則とパラメータ設計を決め切ります。実装後にルールを揃えるのは、計測データ全件の再設計に近い大工事です。予約衝突（ga_ 接頭辞・page_referrer 等）はサイレント故障の主犯で、半年気付かない事故はほぼここに集中します。
命名規則の3原則。第一に「動詞_名詞」の順で組む（click_hero_cta）。名詞_動詞の順（hero_cta_click）はレポート一覧で並べたときに視認性が落ちます。第二に snake_case で統一。camelCase や kebab-case を混ぜると GA4 レポート上で別イベント扱いになります。第三に予約接頭辞回避。ga_ google_ firebase_ で始まるイベント名は GA4 側で受信時に破棄されます[3]。自社独自の接頭辞をつけたい場合は rs_click_cta のように2文字以下の独自プレフィックスを使います。
パラメータ設計の3原則。第一に必要最小限（実用上は5-7個に絞る）。第二に型の統一（value は常に数値、item_id は常に文字列。BigQuery エクスポート時に集計エラーになるのを防ぐ）。第三にカスタムディメンション登録（レポートで利用するパラメータは GA4 管理画面で登録しないと UI に表示されません）。
予約パラメータでは page_referrer page_location page_title の独自定義が代表的な衝突源です。自動収集の同名パラメータと混ざり、レポート上で値が混在して「(not set)」が増えて見える状態を作ります。「(not set)」原因の切り分けはGA4の「Direct/(none)」5原因で整理しています。決めた規則はチーム共有ドキュメント化しておかないと、実装担当が複数人いる場合は半年で必ず崩れます。
4. 設定完了後に始まる本当の壁 — 検証と売上接続#
結論から言うと、設定→検証→売上分解→次の一手の4段ゲートで、GA4だけで自動で来られるのは2段目（検証）まで＝3段目の入口。3段目（売上分解）から先は、探索レポートを手組みする作業になります。
まず2段目、検証について。イベント実装後は3レイヤーで動作確認します。実装直後にDebugViewでイベント送信を秒単位で確認（イベント名・必須パラメータ・型の3ポイント）。公開前にリアルタイムレポートで集計対象として扱われているか確認（DebugViewに出るがリアルタイムに出ない場合は予約接頭辞使用の可能性）。公開1週間後にBigQueryエクスポートで実際に格納されたパラメータ構造を確認。この3レイヤーを飛ばすと「計測できているように見えて壊れている」サイレント故障に気付けません。ここまでがGA4だけで来られる範囲です。
問題は3段目からです。purchase.value を正しく取れても、「どのチャネルから来たセッションが効率よく売上を作っているか」は、GA4の標準eコマースレポートでは主役として出てきません。チャネル別の売上とRPS（セッションあたり売上）を並べるには、探索レポートで自分でディメンションを組み合わせて作る必要があります。しかも、アトリビューションモデル（last / first / linear / time_decay）を切り替えると、探索レポートは4回組み替えることになります。売上・RPS・セッションは別画面で突き合わせる。中小ECの担当者がこれを毎週回すのは、実務的に重すぎます。設定完了後の壁は「技術的に測れているか」ではなく「毎週の判断に組み込めるか」にあります。source/mediumレベルの粒度と売上分解はGA4のSource Groupと売上分解にまとめています。
RevenueScopeの解決策
RevenueScope は、集めたイベントデータのうち purchase（売上）データを「売上の意思決定」に変える3段目・4段目を担います。get_breakdown（dimension=channel）が、purchase.value を last_touch 帰属でチャネル別に配分し、売上・RPSをセッション数・エンゲージメントと同じ画面に並べます。attribution_model パラメータを切り替えると、last / first / linear / time_decay の4モデルがワンクリックで動きます。GA4側でレポートを組み替え直す必要はありません。下の表は、見本ECのチャネル別 帰属売上シェア（last_touch）です。
| チャネル | 帰属売上シェア |
|---|---|
| Direct | 30.1% |
| Google検索 | 26.9% |
| ChatGPT | 14.2% |
| Meta | 6.0% |
| Claude | 4.8% |
| Google Ads | 3.8% |
| Perplexity | 3.8% |
| Gemini | 3.6% |
| Referral | 3.1% |
| Yahoo!検索 | 2.6% |
| Copilot | 1.0% |
| X | 0.0% |
| Bing | 0.0% |
| Unattributed（未帰属） | 全売上の7.8% |
見本ECの実出力（サンプルデータのフィクションサイト）。シェアは帰属済み売上に対する割合、Unattributed のみ全売上に対する未帰属分。
先に、担う範囲をはっきりさせておきます。RevenueScope が引き受けるのは、purchase（売上）データをチャネル別の売上・RPS（セッション数・エンゲージメント付き）として1画面に並べ、アトリビューションモデルを切り替えて業務判断に組み込むところまでです。view_item 等の行動イベントは消費しません。チャネル別のAOV・CVRは返しません（AOV・CVRはサイト全体サマリとキャンペーンのdrilldownのみ）。GA4のイベント設定そのものは代替しません（GTM代替も含めて未対応）。粗利・LTV・在庫は対象外です。GA4の代替ではなく補完として、読み取り専用でつなぐだけなので、組んだイベント計測はそのまま活きます。どのモデルを主に採るか、どのチャネルの予算をどう動かすかは、あなたが決めます。
FAQ#
よくある質問#
Q. GA4イベントを12項目実装し終えたら、次に何を見るべきですか？
A. 順序としては、まず3レイヤー検証（DebugView→リアルタイム→BigQuery）で「送れているか・集計されているか・格納されているか」を確定します。そのうえで、チャネル別の売上・RPSを1画面で並べて「どのチャネルが効率よく売っているか」を毎週見比べる仕組みに移ります。GA4の標準レポートでは主役に出てこない切り口なので、探索レポートを組むか、専用ダッシュボードを用意するかの選択になります。
Q. 予約接頭辞（ga_ google_ firebase_）を使うと何が起きますか？
A. GA4側で受信時に破棄されます[3]。実装しても計測は動かないので、レポートには一切現れません。厄介なのは「実装した気になっている」のに数字が上がらないので、原因究明までに時間がかかることです。カスタムイベント名は必ず予約接頭辞を避けて設計してください。自社独自の識別子を頭につけたい場合は、rs_ のように2文字以下の独自プレフィックスにします。
Q. カスタムイベントの設計を「実装後」に揃え直すのは現実的ですか？
A. 現実的ではありません。実装済みのイベント名・パラメータ名は、既に送信済みのデータに紐づいており、リネームすると過去データとの断絶が発生します。命名規則と型の統一は、実装前に決め切るのが原則です。既に混在してしまっている場合は、①既存イベントはそのまま残置 ②新規実装から新ルール適用 ③レポート側で新旧ルールを別集計する、の3点セットで移行するのが実務的です。
まとめ#
GA4イベント設定は、測定の起点ですが、それだけで売上の意思決定に届くわけではありません。3階層（自動収集／推奨／カスタム）の境界線・推奨12項目・カスタムイベントの命名規則・予約衝突の回避・3レイヤー検証まで押さえれば、「設定できている」状態には到達します。ここまでがGA4だけで自動で来られる範囲です。
その先の「どのチャネルが効率よく売っているか」を毎週見比べるには、探索レポートを何枚も組んでアトリビューションモデルを4回切り替える手作業が要ります。中小ECの担当者にはこれが重すぎ、実装は終わったのに判断に使えていない状態が続きがちです。設定完了後の本当の壁は、技術面ではなく業務判断への組み込みにあります。
RevenueScope は、purchase（売上）データをチャネル別の売上・RPSと4モデル切替に接続する3段目・4段目を引き受けます。GA4の代替ではなく補完として、読み取り専用でつなぐだけ。組んだイベント計測はそのまま活きます。設定完了後の判断ワークフローを、毎週回せる形にできるかどうかで、集めたデータが売上を動かすかが決まります。
どの広告が売上を生んでいるか、一目でわかる
月5,000セッションまで、AIアナリストもずっと無料。クレジットカード不要。最短5分で導入。
