「GA4のeコマースを設定したのに、収益化レポートの売上がECカートの数字と合わない」——ネットショップの計測でとても多い悩みです。購入は起きているのに、金額が入っていなかったり、商品が1つも記録されていなかったり。原因の多くは、購入時に送られる purchase イベント の中身の不備に集約されます。
こんな症状に心当たりはありませんか？
- 収益化レポートで 購入数はあるのに売上（
value）が0、または空欄 - 「eコマースの購入数」は出るのに、商品（
items）の一覧が空 - カートの管理画面とGA4の 売上金額がずれる
- 同じ注文が 二重に計上 され、売上が実際より多く出る
この記事では、GA4の購入イベントが正しく送られているかを確認する方法を、purchase の必須パラメータごとに整理します。どこを見れば「送れている／送れていない」が切り分けられるのか、実務目線で解説します。
まず押さえる：purchaseイベントに必要なパラメータ
GA4のeコマース計測の中心が、購入完了時に送る推奨イベント purchase です。売上と商品を正しく記録するには、次のパラメータがそろっている必要があります。
| パラメータ | 役割 | よくある不備 |
|---|---|---|
transaction_id |
注文を一意に識別するID | 欠落すると同じ購入が重複計上される |
value |
購入金額の合計 | 未設定／文字列で送っていて売上が0になる |
currency |
通貨コード（ISO 4217） | JPY/USD でない・欠落で金額が集計されない |
items |
購入商品の配列 | 空配列・スキーマ誤りで商品が記録されない |
ポイントは、value と currency は必ずセットだということです。GA4は通貨が分からないと金額を売上として集計できません。また items は配列で、各商品が item_id や item_name などのフィールドを持ちます。この配列が空だったり構造が違ったりすると、購入は数えられても中身の商品が消えます。
items 配列のつまずき（商品が記録されない）
「購入数は出るのに商品が空」というときは、ほぼ items の問題です。典型的な原因は次の3つです。
- items配列が空：
purchaseは送っているがitems: []になっている。カート情報の受け渡しが途中で切れているケース。 - スキーマ（構造）の誤り：各商品が
item_idもitem_nameも持っていない。GA4はどちらか一方は必須とみなすため、両方欠けると商品として扱われません。 - フィールド名の間違い：
idやnameなど旧Universal Analytics時代のキーのまま送っている。GA4はitem_id／item_nameを期待します。
つまずきやすい例： 開発者ツールで
purchaseの送信は見えるのに商品が記録されない場合、リクエストの中身でitemsが空になっていないか、キー名がitem_id／item_nameになっているかを1件ずつ確認してください。「イベントが飛んでいる」＝「商品まで正しく入っている」ではありません。
value・currency のつまずき（売上が合わない）
金額まわりの不備は、売上レポートを静かに壊します。
valueが文字列："3000"のように文字列で送ると、GA4が数値として集計できず売上に反映されないことがあります。数値（3000）で渡します。currencyの欠落・非ISO：currencyがない、あるいは¥や円のような表記だと集計されません。ISO 4217の3文字コード（JPY・USDなど）で渡す必要があります。- 税・送料の扱いが不統一：
valueに税や送料を含めるか含めないかは、カート側とGA4側で方針を揃えないと、金額のズレとして表面化します。どちらでも構いませんが、一貫させることが重要です。
つまずきやすい例： 「購入数は合うのに売上だけずれる」場合、
valueに何を含めているか（税込み／税抜き／送料の有無）をまず疑ってください。多くのズレはここに原因があります。
transaction_id のつまずき（重複計上）
transaction_id は注文を一意に識別するためのパラメータです。これが欠けていたり、毎回変わってしまうと、GA4は同じ購入を別々の購入と見なし、重複して計上します。
- サンクスページを再読み込みするたびに
purchaseが飛び、transaction_idがなければそのたびに新しい売上として数えられる - 逆に、正しい
transaction_idが入っていれば、GA4は同じIDの重複購入を排除してくれる
重複計上そのものの詳しい切り分けは、コンバージョンが二重計測される原因と対処 で扱っています。注文番号など、注文ごとに一意で変わらない値を transaction_id に入れるのが基本です。
dataLayerのつまずき（GTM実装の場合）
Googleタグマネージャー（GTM）で purchase イベントを送っている場合、データは dataLayer を経由します。「purchaseは飛ぶのにデータがおかしい」問題の多くは、次の3つに起因します。
- ecommerceオブジェクトをクリアしていない。 GTMはdataLayerのpushを再帰的にマージします。直前の
add_to_cartなどで残った商品データがpurchaseのpushに混入し、意図しないデータが送られることがあります。対策は、purchaseのpush直前に{ ecommerce: null }をpushしてオブジェクトをリセットすることです。 - トリガーのタイミングとdataLayerの投入タイミングのずれ。 GA4イベントタグのトリガーが「DOM Ready」で発火する設定なのに、カートプラットフォームがdataLayerにトランザクション情報をpushするのがその直後だと、タグは空の
ecommerceオブジェクトで発火します。GTMプレビューモードで、purchaseのdataLayer pushがタグ発火より 前 に来ているかを確認してください。 - 変数タイプの設定ミス。 GTMにはecommerceフィールド用の組み込み「データレイヤー変数」（例：
ecommerce.transaction_id）があります。これをカスタムJavaScript変数で代用したりハードコードしたりすると、カート側のフォーマット変更時にマッピングが壊れることがあります。
簡易テスト： GTMプレビューモードでテスト購入を行い、
purchaseイベントの Variables タブを確認します。transaction_id・value・currency・itemsのすべてが値を持っていれば正常です。いずれかがundefinedなら、dataLayerへのpushが欠けているか、タグより後に実行されています。GTM全般のトラブルシューティングは GTMのタグが計測されない原因と対処 も参照してください。
決済代行のリダイレクトとpurchaseイベントの欠落
チェックアウト時に外部の決済代行サービス（PayPal・Stripe Checkout・Klarnaなど）にリダイレクトし、サンクスページに戻ってくるフローでは、purchase イベントが発火しない・データが欠けるリスクが高くなります。
- 戻り時のセッション切れ。 リダイレクトにより新しいナビゲーションが発生し、ブラウザが戻り先を新セッションとして扱うことがあります（Safari ITPや広告ブロッカーで顕著）。この場合、サンクスページにカート情報が渡らず、
itemsやvalueが空になります。Safari固有のデータ消失については Safari ITPとコンバージョン欠損 で詳しく扱っています。 - アトリビューションの上書き。
purchaseが発火しても、GA4が決済ドメインを「参照元」として記録し、本来の流入元が上書きされることがあります。GA4のデータストリーム設定で決済ドメインを クロスドメインリンクリスト に追加し、セッションを維持してください。設定方法は クロスドメイントラッキングが壊れる原因 を参照してください。 - サーバーサイドでの代替送信。 決済代行がサーバーサイドWebhook（例：Stripeの
checkout.session.completed）を確実に送る場合、クライアントサイドのスクリプトに頼らず、GA4 Measurement Protocolを使ってサーバー側でpurchaseイベントを送信する方法もあります。リダイレクト問題を根本から回避できます。サーバーサイドの検証方法は サーバーサイドGTMの検証 を参照してください。
eコマースイベントの順序も重要
GA4のeコマースイベントはファネル構造を持ちます：view_item → add_to_cart → begin_checkout → purchase。purchase は単独でも発火できますが、上流のイベントの不備が、最終的にpurchaseのデータに波及することがあります。
add_to_cartがdataLayerのecommerce.itemsを正しく構成していない場合、同じ不正な items 配列がpurchaseまで引き継がれる可能性があります。- カートプラットフォームによっては、ファネルの各ステップで
items配列を段階的に構築します。begin_checkoutがスキップされたりエラーで発火した場合、purchaseに渡される配列が不完全になることがあります。 purchaseだけでなくファネル全体を確認することで、スキーマの誤りを早期に発見でき、デバッグが速くなります。
送られているかを確認する4つの方法
purchase イベントとその中身が正しく送られているかは、次の順で確認できます。
- GA4のDebugView：デバッグモードを有効にして実際に購入（またはテスト購入）を行い、「管理 → DebugView」で
purchaseイベントが流れてくるか、value・currency・itemsが入っているかを見ます。itemsを展開して中身まで確認するのがポイントです。 - 開発者ツールのNetwork：ブラウザの開発者ツールで
collectをフィルタし、サンクスページ表示時に…/g/collectへのリクエストが飛ぶかを確認。中身でen=purchase、transaction_id、value、currency、itemsの各パラメータを見ます。 - GA4の収益化レポート：「レポート → 収益化 → eコマース購入数」で、商品ごとの数量・売上が積み上がっているかを確認します（標準レポートは反映に時間差があります）。
- transaction_idで重複を確認：同じ注文が2回数えられていないか、探索レポートなどで
transaction_id単位の重複がないかを見ます。
GA4のタグそのものが発火しているかの確認手順は、GA4のタグが正しく動いているか確認する方法 を先に読むと切り分けが早くなります。
手元の確認だけでは分からないこと
DebugViewや開発者ツールはとても有効ですが、自分の手元で1回テスト購入して確認するやり方には、構造的な限界が2つあります。
- 自分の環境＝本番のユーザー環境ではない。 ログイン状態・拡張機能・社内IP除外・広告ブロッカーなどの影響で、手元では
purchaseが正しく飛んでいても、実際の購入者の条件では欠けていることがあります。とくに決済代行やリダイレクトを挟むフローでは、サンクスページに戻る前にセッションが切れてitemsが空になる、といった事故が起きがちです。 - 広告クリックがからむ売上は確認が難しい。 「広告経由の購入が本当に売上として記録されるか」をきちんと見ようとすると、本来はライブ広告をクリックして経路を再現する必要があり、これは自己クリックとして 広告ポリシー違反のリスク を伴います。
「DebugViewで見えたからOK」と判断すると、本番の購入者がたどる実際の決済フローで、value や items が欠けている問題を見逃しがちです。発火のさらに先、記録されるかまでを見る考え方は 発火しているのに記録されない理由 で詳しく扱っています。
確認のためのチェックリスト
- サンクスページ（購入完了ページ）で
purchaseイベントが発火しているか -
valueが 数値 で入っているか（文字列になっていないか） -
currencyが ISO 4217コード（JPY／USD等）で入っているか -
items配列が空でなく、各商品にitem_id／item_nameがあるか -
transaction_idが注文ごとに一意で入っているか（重複計上の防止） - 税・送料を
valueに含めるかどうかがカート側と揃っているか - 同じ注文が二重に計上されていないか（
transaction_id単位で確認） - 本番の実ユーザー条件でも欠けていないか（手元の1回だけで判断しない）
よくある質問（FAQ）
Q. 購入数は出るのに売上（value）が0なのはなぜ？
A. value が未設定、文字列で送られている、または currency が欠落・非ISOで集計できていない、が典型です。開発者ツールのNetworkで …/g/collect の value と currency の中身を確認してください。
Q. 商品（items）だけが記録されないのはなぜ？
A. items 配列が空、あるいは各商品が item_id／item_name を持っていない可能性が高いです。旧UAの id／name のまま送っていないかも合わせて確認します。
Q. 同じ購入が二重に計上されるのは？
A. transaction_id が欠けている、または再読み込みのたびに違う値になっているのが典型です。注文番号など一意で不変の値を入れれば、GA4が重複を排除します。詳しくは重複計測の記事を参照してください。
Q. valueに税や送料は含めるべき？
A. GA4として「必ずこう」という決まりはありませんが、カート側の売上定義とGA4側のvalueを一致させることが最重要です。方針がずれると金額のズレとして必ず表面化します。
Q. DebugViewでpurchaseが見えれば安心？ A. それは「送信された」ところまでの確認です。標準の収益化レポートに正しく積み上がるか、そして本番の購入者の実際の決済フローでも欠けていないか、までを見て初めて安心できます。
まとめ：発火の確認で止めず、中身と本番の記録まで見る
GA4のeコマース購入計測は、purchase イベントの transaction_id・value・currency・items がそろって初めて正しく動きます。DebugViewや開発者ツールで「送れている」ことは確認できますが、大事なのはその先——本番の購入者がたどる実際の決済フローでも、金額と商品が欠けずに記録されるかです。
ConversionOKは、外部の独立した実ブラウザであなたの本番ページにアクセスし、実際に送信される購入イベント（value・currency・items を含む）を傍受して検証します。自分の広告をクリックする必要も、社内環境の影響を受けることもありません。まずは無料の静的チェックで、eコマース計測の入口を確認してみてください。