「GA4でECの購入は計測できているが、どこで離脱しているかが分からない」——GA4のeコマース計測は、購入完了だけを取っていても意味がありません。
商品閲覧 → カート追加 → 決済開始 → 購入完了という一連のイベントを揃えて初めて、どこで落ちているかが分かります。
本記事では設定手順を解説したうえで、ファネルからECサイトの何を直すかまでを扱います。
記事のポイント
- GA4のeコマースで押さえるべき必須イベント
items配列の書き方（ここを誤ると商品別に見られない）- カート放棄率の出し方
- よくある実装ミス
- ファネルからECサイトの何を直すか
目次
- GA4のeコマース計測とは
- 押さえるべき必須イベント
- items配列の書き方
- 実装手順
- よくある実装ミス
- カート放棄率を出す
- ファネルから何を直すか
- よくある質問
- まとめ
GA4のeコマース計測とは
GA4のeコマース計測は、決められた名前のイベントと、決められた形式のパラメータ（items 配列）を送ることで、専用のレポートが使えるようになる仕組みです。
独自のイベント名を使うと、eコマースレポートが機能しません。 「購入完了」を cv_kanryo のような名前で送っている場合、収益レポートも商品別レポートも空のままです。
押さえるべき必須イベント
推奨イベントは多数ありますが、まずこの5つを揃えてください。
| イベント名 | 発火タイミング | なぜ必要か |
|---|---|---|
view_item | 商品詳細ページの表示 | 母数になる |
add_to_cart | カートに追加 | 購入意向の最初の指標 |
begin_checkout | 決済フローの開始 | カート放棄の判定に必要 |
add_payment_info | 支払い情報の入力 | 決済フロー内の離脱位置 |
purchase | 購入完了 | 成果 |
purchase だけでは何も分からない
購入完了だけを計測しているECサイトは非常に多いですが、それでは「購入が少ない」以上のことが分かりません。
add_to_cart と begin_checkout があって初めて、「カートには入っているが決済に進んでいない」のか「決済を始めたが完了していない」のかが切り分けられます。この2つは打ち手がまったく違います。
purchase はキーイベントから外せない
purchase は GA4 が自動的にキーイベントとして扱い、解除できません。 キーイベントの設定については「【2026年版】GA4のキーイベント（旧コンバージョン）設定方法｜計測されないときの対処法も解説」で解説しています。
items配列の書き方
eコマースイベントには、items という配列パラメータを付けます。ここに商品情報を入れます。
主なパラメータ
| パラメータ | 内容 | 必須 |
|---|---|---|
item_id | 商品ID（SKU） | どちらか必須 |
item_name | 商品名 | どちらか必須 |
price | 単価 | 推奨 |
quantity | 数量 | 推奨 |
item_category | カテゴリ | 推奨 |
item_brand | ブランド | 任意 |
item_variant | バリエーション（色・サイズ） | 任意 |
purchase に必要な追加パラメータ
| パラメータ | 内容 |
|---|---|
transaction_id | 注文ID（必須） |
value | 購入金額の合計 |
currency | 通貨コード（JPY） |
tax / shipping | 税・送料 |
transaction_id は必須です。 これがないと重複排除ができず、画面をリロードするたびに購入が重複計上されます。
currency を忘れない
value を送るなら currency も必ず送ってください。 通貨が指定されていないと、収益が正しく集計されません。日本円なら JPY です。
実装手順
GTMを使う場合
- サイト側で
dataLayerに商品情報を push する実装を開発側に依頼する- 商品詳細ページの表示時、カート追加時、決済開始時、購入完了時
- GTMで「データレイヤー変数」を作成し、
ecommerceを取得する - GTMで「Google アナリティクス: GA4 イベント」タグを作成
- イベント名:
add_to_cartなど - 「eコマースデータを送信」をオンにし、データレイヤーを指定
- イベント名:
- トリガーを「カスタムイベント」で設定する
- プレビューモードで
itemsの中身まで確認する - 公開する
手順5が重要です。 イベント名が正しくても、items の構造が違うと商品別レポートが空になります。
確認方法
「レポート」→「リアルタイム」でイベントの発火を確認し、その後「収益化」→「eコマース購入数」で商品別のデータが入っているかを見ます。
反映まで最大24〜48時間かかります。
よくある実装ミス
| ミス | 結果 | 対処 |
|---|---|---|
| 独自のイベント名を使っている | eコマースレポートが空 | 推奨イベント名を使う |
transaction_id がない | リロードで重複計上される | 注文IDを必ず送る |
currency がない | 収益が集計されない | JPY を送る |
items の構造が違う | 商品別レポートが空 | プレビューで中身を確認 |
price を文字列で送っている | 集計されない | 数値型で送る（"1000" ではなく 1000） |
add_to_cart を実装していない | 離脱箇所が分からない | 必須5イベントを揃える |
| 決済ページが別ドメイン | セッションが分断される | クロスドメイン計測または参照元除外 |
最後の項目に注意してください。 決済を外部サービスに委ねている場合、戻ってきたときに参照元が決済サービスになり、広告の成果が失われます。 対処は「【2026年版】GA4のクロスドメイン計測の設定方法｜セッションが分断される問題を解決する」で解説しています。
カート放棄率を出す
GA4に「カート放棄率」という指標はありません。 自分で算出します。
- カート放棄率 ＝ 1 −（
purchase数 ÷add_to_cart数）
「レポート」→「収益化」→「eコマース購入数」、または探索レポートで各イベント数を取得して計算します。
より正確に見るなら、ファネルデータ探索を使ってください。
- 「探索」→「ファネルデータ探索」
- ステップを定義する
view_item→add_to_cart→begin_checkout→purchase
- 「内訳」にデバイスカテゴリを追加する
ステップ間の落差が大きい箇所が改善対象です。 作り方は「【2026年版】GA4ファネルデータ探索の作り方｜離脱ステップを特定してフォーム改善につなげる」で解説しています。
ファネルから何を直すか
ここが本題です。どこで落ちているかによって、直す対象が変わります。
| 落ちている区間 | 疑うこと | 打ち手 |
|---|---|---|
| 商品閲覧 → カート追加 | 商品ページで納得されていない | 画像の点数・サイズ表記・レビュー・在庫表示・送料の明示 |
| カート追加 → 決済開始 | 送料や手数料で驚かれている | 送料を商品ページで先に明示する。カート内で合計金額を分かりやすく |
| 決済開始 → 支払い情報入力 | 会員登録を求めている | ゲスト購入を用意する |
| 支払い情報入力 → 購入完了 | 決済手段が足りない・入力が煩雑 | 決済手段の追加、住所自動入力、入力エラーの表示改善 |
とくに多いのは「カート追加 → 決済開始」の落差
送料が最後まで分からないと、カートで金額を見て離脱されます。 商品ページの段階で送料条件を明示するだけで改善することがあります。
デバイス別に必ず分解する
スマートフォンの購入完了率がPCの半分というパターンは非常に多く見られます。この場合、直すべきはスマートフォンの決済フローです。入力欄の大きさ、適切なキーボードの表示、住所自動入力の有無を確認してください。
改修の効果は必ずABテストで検証してください。 ECは季節性とセールの影響が大きく、期間比較では施策の効果を分離できません。
よくある質問
Q. 購入完了だけ計測していれば十分ですか？
A. 不十分です。add_to_cart と begin_checkout がないと、「カートに入れたが決済に進んでいない」のか「決済を始めたが完了していない」のかが切り分けられません。 この2つは打ち手がまったく違います。
Q. eコマースレポートが空です。
A. 独自のイベント名を使っている可能性が高いです。purchase add_to_cart など決められた名前を使う必要があります。 また items 配列の構造が違う場合も商品別レポートは空になります。
Q. 購入が重複して計上されます。
A. transaction_id を送っていない可能性が高いです。これがないと重複排除ができず、購入完了ページをリロードするたびに計上されます。
Q. カート放棄率はどこで見られますか？
A. GA4に「カート放棄率」という指標はありません。1 −（purchase 数 ÷ add_to_cart 数） で算出するか、ファネルデータ探索でステップ間の通過率を見てください。
Q. 収益が集計されません。
A. currency パラメータを送っていないか、price や value を文字列で送っている可能性があります。通貨コード（JPY）を送り、金額は数値型で送ってください。
Q. 決済が外部サービスなのですが注意点はありますか？
A. 決済サービスから戻ってきたときに、参照元がその決済サービスとして記録され、広告の成果が失われます。 「タグ設定を行う」→「参照元のリストを設定」で決済サービスのドメインを除外してください。
まとめ
GA4のeコマース計測について、要点を整理します。
- 決められたイベント名と
items配列を使わないとレポートが機能しない - まず5つを揃える:
view_itemadd_to_cartbegin_checkoutadd_payment_infopurchase purchaseだけでは「購入が少ない」以上のことが分からないtransaction_idは必須。 ないとリロードで重複計上されるvalueを送るならcurrency（JPY）も必ず送る。金額は数値型- GA4に「カート放棄率」の指標はない。 自分で算出するかファネルで見る
- もっとも多い落差は「カート追加 → 決済開始」。 送料を商品ページで先に明示する
- 「決済開始 → 支払い情報入力」で落ちるならゲスト購入を用意する
- デバイス別に必ず分解する。スマートフォンだけ低いパターンが多い
- 効果検証はABテストで。ECは季節性とセールの影響が大きい
CVR改善ならDejam！カートで落ちる理由を、行動データで確認する
Dejamは、LP制作・ヒートマップ分析・ABテスト・AI自動解析をオールインワンで提供するCVR改善特化ツールです。「どの区間で落ちているかは分かったが、なぜ落ちるのかが分からない」という段階から、本格的なPDCAを回して成果を最大化するまでを総合支援します。
Dejamが選ばれる理由
- ワンプロダクトで完結: LP制作・ヒートマップ分析・ABテストをすべて単一ツールで実施
- 月額3万円〜利用可能: オプティマイズプラン月額3万円〜 / CMSプラン月額5万円〜 / オールインワン月額12万円〜
- ユーザー課金なし: 何名で使っても追加費用は発生しない
- ISMS認証取得: ISO/IEC 27001:2022 & JIS Q 27001:2023認証取得済み
- 毎週アップデート: 市場トレンドとユーザーリクエストに応じて機能を毎週拡充
- 権威ある実績: 代表がダイレクトアジェンダで2連覇。LPO顕彰制度「LPO AWARD」主催者
Dejamの主要機能
- LP/記事LP制作: ノーコード・コードの切り替えに対応。AIで生成したコードを直接取り込み可能
- ヒートマップ: 5種類（クリック/クリックイベント/熟読/滞在/離脱）。データ保存期間無制限
- ABテスト: デザイン変更テスト・リダイレクトテスト・ポップアップテストの3種類。AIが自然言語でテストコードを自動生成
- Web接客・ポップアップ: 離脱しようとしたタイミングで別の訴求を出せる
- フォーム作成: 決済前の入力ステップを改善できる
GA4のファネルでは「カート追加から決済開始で落ちている」までしか分かりません。Dejamのヒートマップなら、商品ページのどこまで読まれて、送料表記を見た後にどう行動したかまで確認できます。
