GA4を導入して半年経った頃、レポートを開くと「(not set)」が増え、購入イベントが二重計上され、なぜか同じ商品の purchase イベントが2種類のパラメータ構造で記録されている — このような状態に陥った経験はないでしょうか。
原因のほとんどは、初期実装時に GA4イベントの3階層（自動収集 / 推奨 / カスタム）の境界線を曖昧にしたまま走り出した ことにあります。GA4は柔軟で何でも計測できる反面、その柔軟性は「ルールを決めずに走ると確実に壊れる」というトレードオフを伴います。
本記事は、ECサイト運営者向けに、GA4のカスタムイベント設定を 半年後・1年後にも壊れない形で初期構築する ための完全ガイドです。3階層の境界線、推奨イベント12項目、カスタムイベントの命名規則、予約パラメータの落とし穴、動作検証手順までを実務目線で整理しています。
この記事のまとめ#
- GA4イベントは3階層構造（自動収集 / 推奨 / カスタム）。それぞれ送信元・編集可否・パラメータ仕様が異なるため、混在させると後で必ず壊れる
- ECサイトは「推奨イベント」で押さえる。
view_item/add_to_cart/purchaseなど12項目を仕様通りに送ることで、標準レポート・eコマースレポート・BigQueryエクスポートの全てが整合する - カスタムイベントは命名規則とパラメータ設計を先に決める。後から「動詞_名詞」「snake_case」「予約接頭辞回避」のルールを揃えるのは、計測データ全件の再設計に近い大工事になる
- 動作検証は3レイヤー：DebugViewで送信確認 → リアルタイムレポートで集計確認 → BigQueryで構造確認。1つでも飛ばすと「計測できているように見えて壊れている」状態に気付けない
1. なぜGA4のカスタムイベント設定は詰むのか#
広告運用に携わる担当者を対象とした調査によると、社内のGA4レポート自動化まで到達できた企業は 11% にとどまります[1]。導入はしたが「使いこなせていない」企業が大半を占める背景には、初期実装時の イベント設計の曖昧さ があります。
GA4以前のUniversal Analyticsは「ページビュー」中心の計測モデルで、イベントは補助的な存在でした。GA4は逆に すべてがイベント で、ページビューですら page_view というイベントとして扱われます。この設計思想の転換に対応せずに「とりあえず動けばいい」で実装すると、半年後に以下のような典型的な故障に行き着きます。
purchaseイベントが2種類存在し、片方は税込み・片方は税抜きで売上が10-15%ズレる- カスタムイベント名が
Click_Buttonclick-buttonclickButtonと表記揺れし、レポート集計時に分割表示される event_nameがga_session_startのような予約接頭辞ga_google_firebase_を使っており、計測自体が無効化されていることに半年気付かないvalueパラメータに数値ではなく文字列を入れてしまい、売上集計が0円のまま積み上がっていく
これらは全て、3階層の境界線を曖昧にしたまま走り出した結果 です。本記事の目的は、この境界線を最初に明確化し、半年後に詰まない計測基盤を作ることにあります。
2. GA4イベントの3階層 — 自動収集 / 推奨 / カスタムの境界線#
GA4のイベントは、送信元 と GA4側の認識方法 によって3階層に分類されます。この階層を理解せずに「とりあえずカスタムイベントを送る」を続けると、推奨イベントとして扱えば標準レポートに乗ったはずのデータが、独自指標として埋もれていきます。
| 階層 | 送信元 | 編集可否 | パラメータ仕様 | 例 |
|---|---|---|---|---|
| 自動収集 | GA4タグが自動送信 | 不可（無効化のみ可） | 仕様固定 | page_view / session_start / first_visit / user_engagement |
| 推奨イベント | サイト側で実装・送信 | 名前は固定・パラメータ必須項目あり | 仕様あり（公式ドキュメント） | view_item / add_to_cart / purchase / sign_up |
| カスタムイベント | サイト側で実装・送信 | 名前・パラメータ自由 | 自由（ただし予約接頭辞NG） | click_hero_cta / scroll_50pct / download_whitepaper |
階層を見分けるルールはシンプルです。「Googleが定義した仕様があるか」「サイト側が定義するか」 の2点で判定できます。自動収集はGoogleが定義し送信もGoogleが行う、推奨はGoogleが定義しサイト側が送信する、カスタムはサイト側が定義しサイト側が送信する、という構造です。
EC事業者にとって最も重要なのは、「ECで起こる行動はほぼ全て推奨イベントでカバーされている」 という事実です。商品閲覧、カート追加、購入完了、リファンドまで、Google Analytics公式の推奨イベント仕様に揃えるだけで、標準のeコマースレポートが正常に動作します。カスタムイベントは「推奨イベントでは表現できない自社固有の行動」のみに限定するのが原則です。
3. ECサイト向け推奨イベント完全リスト（カテゴリ別12項目）#
ECサイトで実装すべき推奨イベントは、ユーザー行動のステップに沿って12項目に整理できます。それぞれ「いつ送るか」「必須パラメータ」「実装上の注意」を押さえれば、標準のeコマースレポートが正しく集計されます。
GA4推奨イベント名一覧#
GA4の推奨イベントはカテゴリ横断で50種類以上ありますが、ECサイトで実装すべきイベントは以下の12項目に集約できます。各イベント名は Google公式ドキュメント記載のスペル に厳密一致させる必要があります（view_item を view_items viewItem view_product などと変えると標準レポートで集計されなくなります）。
| カテゴリ | イベント名 | 送信タイミング | 必須パラメータ |
|---|---|---|---|
| 閲覧 | 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コマース設定で最頻出の故障パターンです。詳細な対策は GA4 eコマース設定を30分で終わらせるチェックリスト — Shopify編 で整理しています。
推奨イベントから「売上分解」につなげる#
12項目の推奨イベントを正しく実装すると、GA4の標準eコマースレポートで売上・注文数・AOV（平均注文単価）まで自動で集計されます。しかし、ここで止まってしまうと「全体の売上は分かるが、どのチャネル・どのセッションが効率よく稼いでいるか」が見えません。
推奨イベントの真価は、purchase イベントの value を「セッション単位」「チャネル単位」「ランディングページ単位」で割り戻して初めて発揮されます。例えば、Google Organicから来たセッションのRPS（Revenue Per Session：セッションあたり売上）と、Meta広告から来たセッションのRPSを比較すれば、CVRの差・AOVの差・両方を含めた投資効率が一目で判断できます。
このような「売上から逆引きで指標を組み立てる考え方」については、マーケティングKPI設計の正解 で詳しく整理しています。GA4のイベント実装はそのための「素材集め」であり、ゴールではない、という視点を持っておくと設計の優先順位がぶれません。
4. カスタムイベントを設計する正しい順序#
推奨イベントでカバーできない行動（例：「ヒーローCTAクリック」「スクロール50%到達」「ホワイトペーパーDL」）はカスタムイベントで実装します。ここで重要なのは、「実装する前に命名規則とパラメータ設計を先に確定する」 ことです。実装後にルールを揃えるのは、計測データ全件の再設計に近い大工事になります。
命名規則の3原則#
カスタムイベント名は以下の3原則を初期設計時に決め切ります。
- 動詞_名詞：行動を動詞で表現（
click/view/download/submit）、対象を名詞で表現（cta/whitepaper/form）。click_hero_ctaのように動詞_名詞_詳細で組み立てる - snake_case：単語間はアンダースコア区切り。
clickHeroCta（camelCase）やclick-hero-cta（kebab-case）と混在させると、GA4レポートで別イベント扱いになる - 予約接頭辞回避：
ga_/google_/firebase_で始まる名前は計測自体が無効化される。プロジェクト固有の接頭辞をつけたい場合はrs_click_ctaのように2文字以下の独自プレフィックスにする
パラメータ設計の3原則#
イベント名と同様、パラメータも実装前に確定します。
- 必要最小限：1イベントあたり25個までという上限はあるが、実用上は5-7個に絞る。無駄なパラメータは集計時のノイズになり、カスタムディメンション登録枠（プロパティあたり50個）を圧迫する
- 型を統一：
valueは数値、item_idは文字列、is_logged_inはbooleanのように、同名パラメータの型は全イベントで統一する。型が混在するとBigQueryエクスポート時に集計エラーになる - カスタムディメンション登録：レポートで利用するパラメータはGA4管理画面で「カスタムディメンション」として登録する。登録しないパラメータはBigQueryには残るが、GA4 UI上のレポートでは表示されない
良い例 / 悪い例#
実務で頻発する命名ミスを並べると、ルールの重要性が体感できます。
| 良い例 | 悪い例 | 問題点 |
|---|---|---|
click_hero_cta | Click Hero CTA | スペース・大文字混在で別イベント扱い |
view_pricing | pricing_view | 動詞が後ろにあり一覧で並べたとき視認性低下 |
submit_contact_form | form_submit | 「どのフォーム」が消える・form_submit_contact と表記揺れする原因 |
rs_download_whitepaper | ga_download_whitepaper | ga_ 接頭辞は予約済みで計測無効化 |
5. 予約パラメータと計測ルールの設計 — 衝突・上書き・パラメータ消失を防ぐ#
GA4には 予約済みのイベント名・パラメータ名 が存在します。これらと衝突する命名を行うと、カスタム値が無視される、自動収集イベントが破壊される、ログに記録されない、といった「サイレント故障」が発生します。
予約接頭辞・予約イベント名#
以下の接頭辞で始まるイベント名は使用禁止です[2]。実装してもGA4側で受信時に破棄されます。
ga_/google_/firebase_
加えて、以下のイベント名は自動収集イベントと衝突するため、上書き不可です。
app_remove/app_update/first_open/in_app_purchase/session_start/user_engagement/screen_view
予約パラメータ名#
パラメータ名にも予約済みのものがあります。代表的な衝突原因として、page_referrer page_location page_title を独自定義すると、GA4が自動収集している同名パラメータと衝突し、レポート上で値が混ざります。
「(not set)」が増える原因はこの衝突に起因することも多く、流入元が消失して見える状態に陥ります。「(not set)」がレポートに増えてきたときの原因切り分けは GA4の『Direct / (none)』が増える5つの原因と診断・対処 と 「(not set)」「(other)」「Unassigned」 GA4の不明な流入4種類を見分ける で別途整理しています。
計測ルールの文書化#
ここまで決めた命名規則・パラメータ設計・予約衝突回避のルールは、必ず チーム共有のドキュメントとして文書化 します。実装担当が複数人いる場合、口頭伝達やSlackメンションだけで運用すると半年で必ず崩れます。最低限、以下の項目をスプレッドシートまたはNotionで一覧管理するのが実務的です。
| 列 | 内容 |
|---|---|
| イベント名 | click_hero_cta |
| カテゴリ | 推奨 / カスタム |
| 送信タイミング | ヒーローセクションのCTAボタン押下時 |
| 必須パラメータ | cta_label / page_path |
| 任意パラメータ | is_logged_in |
| カスタムディメンション登録 | 済 / 未 |
| 担当者 | （実装者名） |
| 実装日 | 2026-04-30 |
6. 実装後の動作検証チェックリスト（DebugView / リアルタイム / BigQuery）#
イベントを実装したら、必ず3レイヤーで動作検証します。1つでも飛ばすと「計測できているように見えて壊れている」状態に気付けません。
設定内容の確認手順#
GA4管理画面・gtag.js / GTM設定・サンクスページHTMLの3ヶ所で、実装したイベントが想定通りに動作する状態を確認します。順序としては、実装直後にDebugView → 公開前にリアルタイム → 公開1週間後にBigQuery で段階的にチェックするのが事故を防ぐ最短ルートです。各レイヤーで何を確認するかを以下に整理します。
レイヤー1：DebugView（送信確認）#
GA4管理画面の「DebugView」で、イベントがGA4に到達しているか を秒単位で確認できます。Chrome拡張「Google Analytics Debugger」を有効化するか、Chrome DevTools の Networkタブで collect?v=2 リクエストを確認します。
確認ポイントは3つです。
- イベント名が想定通りに送信されているか（
click_hero_ctaがClickHeroCTAで送られていないか） - 必須パラメータが全て揃っているか（
purchaseのtransaction_idが空でないか） - パラメータの型が想定通りか（
valueが数値で来ているか、文字列になっていないか）
レイヤー2：リアルタイムレポート（集計確認）#
DebugViewはGA4が 受信 したイベントを表示しますが、リアルタイムレポートはGA4が 集計対象として扱った イベントを表示します。両者の差分が、サイレント故障の発見ポイントです。
- DebugViewには表示されるがリアルタイムには出ない → 予約接頭辞使用の可能性
- リアルタイムには出るが標準レポートには出ない → カスタムディメンション未登録の可能性
レイヤー3：BigQueryエクスポート（構造確認）#
GA4のBigQuery連携を有効化すると、生データが日次でエクスポートされます。レポートUIでは見えない「実際に格納されているパラメータ構造」を、SQLで直接確認できます。
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
このクエリで「想定外のイベント名」が混入していないか、表記揺れが発生していないかを週次でチェックすると、サイレント故障を早期発見できます。
3レイヤーすべてで検証が完了すれば、GA4のイベント計測は「設定したつもり」ではなく「設定できている」状態に到達します。検証完了後は、purchase イベントの value をセッション単位・チャネル単位で割り戻して、RPS / AOV ベースで売上分解できる状態が整います。
参考文献#
[1] オーリーズ 「Googleアナリティクス4の活用状況に関する実態調査」 2023年10月 [2] Google 「[GA4] 推奨イベント」 2025年3月 [3] Google 「[GA4] 自動収集イベント」 2025年2月 [4] Google 「[GA4] イベント命名ルール」 2025年1月 [5] Google 「[GA4] BigQuery Export スキーマ」 2025年4月