GA4 eコマース設定とは、購入の瞬間を1回だけの purchase イベントとして、4つの必須パラメータ（value、currency、transaction_id、items）とともに、同じ注文を二重に数えない発火条件で計測することです。作業はイベントが飛んだ時点では終わりません。DebugView にイベントが1件だけ表示され、24〜48時間後にレポートの売上が基幹システムの注文と一致し、チャネル内訳が広告プラットフォームと同じ話をした時に完了します。以下のリストはこの3つの関門を確認するためのものです。
GA4 eコマース設定とは何を指すのか？
GA4 eコマース設定とは、購買行動の各ステップを標準のイベント名と標準のパラメータで GA4 に送ることです。タグではなく約束事だと考えてください。GA4 のレポートはこの名前を前提に作られています。命名が独自だとイベント自体は届きますが、売上・商品・コンバージョンのレポートは空のままになります。
- view_item：商品詳細ページの閲覧。商品への関心を測ります。
- add_to_cart：カート追加。カゴ落ち率の分母がここで決まります。
- begin_checkout：決済フローへの進入。決済内の離脱がここで見えます。
- purchase：注文完了。売上、ROAS、チャネル内訳の唯一の情報源です。
4つとも価値がありますが、広告の判断を決めるのは最後の1つだけです。時間が限られているなら、まず purchase を完璧にし、残りは後から埋めてください。
purchase イベントの必須パラメータは？
イベント全体を支えるのは4つのパラメータです。value（注文金額）、currency（ISO 通貨コード）、transaction_id（注文の一意な ID）、items（商品の配列）。1つでも欠けると GA4 はイベントを記録しますが、該当レポートは空になります。currency がなければ売上は計算されず、transaction_id がなければ重複除外ができず、items がなければ商品パフォーマンスがそもそも生成されません。
- value：注文の合計金額。税と送料を含めるかを決め、その判断を基幹システムと完全に揃えてください。揃っていないと比較が毎回議論になります。
- currency：ISO 4217 のコード（JPY、USD、EUR）。イベント階層で送ります。多通貨販売では各イベントが自分のコードを持ちます。
- transaction_id：注文ごとに一意。ランダム生成は避け、基幹システムの注文番号から生成して突き合わせを可能にします。
- items：商品ごとに最低限
item_idとitem_name。price、quantity、カテゴリ、バリエーションは推奨で、商品レポートの深さはここから生まれます。
なぜ同じ注文が二重に計上されるのか？
重複は購入イベントをサンクスページに結び付けることから生まれます。再読み込み、戻るボタンでの再訪、共有された注文完了 URL のいずれでも再発火します。GA4 は同じ transaction_id を持つ2件目を24時間以内なら除外しますが、ID を毎回ランダム生成しているとこの保護は働かず、売上が膨らみます。
transaction_idは基幹システムの注文番号から生成します。乱数、タイムスタンプ、セッション ID は使いません。- イベントは決済確定時に、1か所からのみ発火させます。ページ読み込みではなく注文の状態に紐付けてください。
- 送信済みの ID をブラウザのセッションストレージに保存し、2回目の送信をブロックします。再読み込みに対する最も安価な保険です。
- ブラウザとサーバーの両方から送っている場合は片方を止めるか、両方が同じ
transaction_idを使うようにします。そうしないと2件の記録が2件の注文に見えます。
計測は整った。判断はまだ手作業ですか？
Ads Sensor は整備された GA4 データと広告プラットフォームのデータを1つの画面に統合し、優先順位と根拠のある打ち手を提示します。
返品とキャンセルは売上にどう反映されるのか？
GA4 は返品分を自動では差し引きません。注文が返品またはキャンセルされたら、別途 refund イベントを送る必要があります。送らないと GA4 の売上は次第に基幹システムの純売上を上回り、その上に積み上げた ROAS の計算はすべて楽観的になります。アパレルやシューズのように返品率が高いカテゴリでは、このずれが判断を直接ゆがめます。
- 全額返品：元の注文と同じ
transaction_id、返金額を正のvalue、そしてcurrency。マイナス値は送りません。 - 一部返品：同じ
transaction_idに、返品された商品と数量だけを含むitems配列を添えます。GA4 はその行だけを差し引きます。 - キャンセル：出荷前のキャンセルでも売上が取り消されるなら返品と同じ扱いにします。会計上は別でも、計測上は同じです。
- 時間差：返品は販売の数日後に発生します。したがって昨日の ROAS と先月の ROAS は成熟度が異なります。同じ遅れを見込んで比較してください。
チャネル内訳を広告判断とどう合わせるか？
正しい件数と金額を計測するだけでは足りません。各購入が正しいチャネルに帰属している必要があります。内訳が壊れると売上の合計は正しく見えるのに配分が誤り、予算が誤ったチャネルへ動きます。最も多い原因は、決済代行がセッションを分断してコンバージョンを自分の手柄にしてしまうことです。
- 参照元の除外：決済代行と 3-D セキュアのドメインを不要な参照のリストに追加します。データストリームごとに最大50ドメインまで指定できます。
- クロスドメイン計測：カート、決済、完了ページが別ドメインなら1つの導線として宣言します。しないと遷移のたびに新しいセッションと新しい参照元が生まれます。
- UTM の規律：有料チャネルでは自動タグ設定を有効にし、手動で付ける場合は
utm_sourceとutm_mediumを固定の語彙から選びます。自由記述は内訳を粉砕します。 - ノーリファラーの意味：直接流入は利用者がアドレスを打ち込んだという意味ではなく、多くは情報の欠落です。直接流入の比率が異常に高いのは設定不良の最初のサインです。
内訳を直しても、GA4 と広告プラットフォームの数字は1対1では一致しません。アトリビューションモデル、コンバージョン期間、クリックの定義が異なるためです。差の原因を減らす土台としては ファーストパーティデータ戦略が効き、信号欠損の技術面は サーバーサイド計測の記事で解説しています。
設定が終わったら何をどう検証するか？
検証は3層で行います。イベント発生時の DebugView、処理後の24〜48時間、そしてチャネル単位です。この順番を飛ばさないでください。DebugView で完璧に見える設定でも、返品の未送信や参照元の破損によってレポート層ではまだ誤っていることがあります。次の6ステップを順に実施します。
- DebugView：実際にテスト注文を行い、
purchaseイベントが1件だけ表示されることを確認します。イベントを開き、value、currency、transaction_id、itemsが埋まっているかを見ます。 - ID の一致：イベントの
transaction_idは基幹システムの注文番号と文字単位で同一ですか。接頭辞や書式の違いは今のうちに直します。 - 再読み込みテスト：完了ページを再読み込みし、戻るボタンでも訪れます。2件目の
purchaseイベントが送信されてはいけません。 - 返品テスト：テスト注文を一部返品し、
refundイベントが正しい商品を含んでいるか確認します。 - レポート突き合わせ：24〜48時間待ち、同じ期間の取引数と売上を基幹システムの注文と比較します。実務では数ポイントの差は通常の範囲ですが、恒常的に広がる差は実装の問題です。
- チャネル確認：購入したセッションの参照元とメディアを見ます。決済代行が参照元に出ていれば、除外リストが不十分です。
整った GA4 データはどう広告判断に変わるのか？
ここまで来れば信頼できる売上とチャネルの表が手元にありますが、判断はまだ手作業です。そこで Ads Sensor の出番です。GA4 のトラフィック、コンバージョン、チャネル内訳のデータを Meta広告、Google 広告、TikTok 広告、Criteo の費用と1つの画面に統合し、キャンペーンを AI が読み、優先順位と根拠を付けた打ち手を出します。正直に言えば、Ads Sensor は GA4 の設定を代行しません。すでにある GA4 を読むツールです。設定はこのチェックリストであなたが完了させてください。
- 統合テーブル：プラットフォームの費用と GA4 の売上・チャネル内訳を同じ画面に並べます。
- AI 分析：キャンペーン単位のリスクと機会を、根拠付きの推奨として提示します。
- 承認して適用：受け入れた推奨は各プラットフォームの API 経由で適用され、適用前後の比較が自動で記録されます。
- 異常検知：費用、コンバージョン、売上の異常を24時間監視し、しきい値は調整できます。
- レポートモード：代理店向けに、顧客へそのまま出せる月次レポート。
チェックリストを終えたら、次はデータに判断を生ませる段階です。ベータに登録してアカウントを接続すれば、最初の分析を確認できます。