GA4の購入数が、カート側の確定注文数より多い。売上も同じだけ膨らんでいます。原因の特定は、それほど難しくありません。ただ、修正作業には時間がかかり、その間も広告費は毎日出ていきます。膨らんだままの数字で決めてよい判断は何か。そこから先に確定させます。
目次
この記事のまとめ#
- GA4は届いた購入イベントを届いた回数どおりに集計していて、ずれているのは送信の側
- 原因は購入完了ページの再読込、購入タグの二重発火、トランザクションIDの不備の3つ
- トランザクションIDに空の文字列を送ると購入イベントはすべて重複として除去される[1]
- 客単価は売上と注文数が同じ倍率で膨らむので変わらず、検知には使えない
- 一律に二重計上されている間も、チャネル間の売上シェアとRPSの順位は入れ替わらない
1. GA4は正しく集計している——ずれているのは送っている側#
GA4は、届いた購入イベントを届いた回数のとおりに集計しています。集計の側に不具合はありません。
症状のパターンはだいたい決まっています。4日目から急に、GA4の購入数だけが持ち上がる。それ以降は、カート側の確定注文数との比がほぼ一定のまま並走します。
手がかりは、比がほぼ一定という点です。特定の日だけ跳ねているならセールや不正注文を疑います。毎日そろって同じ倍率なら、疑うのは個々の注文ではなく、送信の仕組みそのものです。
GA4の不具合ではありません。GA4は正しく集計しています。実際の注文回数と一致していないのは、送信された回数のほうです。ここまで分かれば、次に決めるのは修正の手順ではありません。修正が終わるまでの間、何を判断の軸に置くかのほうです。
なお、逆向きの症状もあります。GA4の売上がカートより少なく出る場合で、そちらは返金の扱いや計上の時点が絡みます。GA4の売上がShopifyと合わない理由にまとめました。
2. 原因は3つ、確認する場所も、購入数が増える側か減る側かも異なる#
確認する場所は原因ごとに異なります。そして購入数が増える側に振れるか減る側に振れるかも、同じではありません。
前提を1つだけ置きます。購入の発生を測定するには、対応するフィールドで定義した商品アイテムを持たせたpurchaseイベントを送信します[3]。1つの注文につき1回。この1回が2回になっているのが、今回の症状です。
まず、購入完了ページの再読込です。購入イベントを購入完了ページに置いている構成では、そのページが再度読み込まれるたびに購入が記録されます。ブラウザの戻る操作、注文内容を確認したくて開いたブックマーク、メールから届いた確認リンク。どれも読者にとっては自然な動作です。確認は、テスト注文を1件通してから購入完了ページを再読込するだけで済みます。GA4のDebugViewには収集されたイベントがリアルタイムで表示されますが、使うにはデバッグモードを有効にする必要があります[5]。
次が、購入タグの二重発火です。Googleタグマネージャーのトリガーは、その種類のイベントが検出されたときにタグを呼び出します[4]。そして新しいトリガーは、既定では関連するイベントタイプのすべてのイベントに対して発動します[4]。同じ購入タグに条件の重なるトリガーが複数ぶら下がっていれば、1回の注文で2回配信されることがあります。ただし公式が「トリガーが複数なら必ず2回配信される」と書いているわけではありません。見るのは設定の本数ではなく、1回の注文での配信回数です。設定そのものの入門はGTMでEC購入を計測する基本にあります。
最後がトランザクションIDです。ここだけ、数字の振れる向きが逆になります。
transaction_idは取引を一意に識別するIDで、このパラメータを使うと購入イベントの重複を回避できます[2]。トランザクションIDを追加すると、同じトランザクションIDで2つの購入が登録されていても、Googleアナリティクスにより購入の重複が除去されます[1]。
逆になるのはここからです。IDとして空の文字列を送ってはいけません。transaction_id=""である購入イベントは、すべて重複として除去されます[1]。全注文で同じIDを固定して送っている場合も同じです。異なるトランザクションで同じIDが送信されると、キーイベントが本来の値よりも大幅に少なくカウントされる恐れがあります[1]。
つまり、IDに空の文字列を入れているときと、全注文で同じ値を使い回しているときは、購入数を増やす側ではなく減らす側に振れます。増える症状を追いかけている最中に、ここを念のためと触ると、今度は購入数が実際より少なく出ます。
一方、IDそのものを送っていない場合は逆です。重複を除去する手がかりがないので、2回届いた購入は2回のまま集計されます。増える側の原因はこちらで、purchaseにIDが載っているかどうかで、見る向きが変わります。IDはオーダーごとに一意で、動的な値である必要があります[1]。オーダー確認番号をそのまま使えます[1]。purchaseに載せるパラメータの全体像はGA4イベント設定にあります。
広告の管理画面のCV数とGA4のCV数が合わない話は、これとは別です。あちらは広告媒体が申告する数、こちらはGA4が集計する購入イベントで、集計している主体から異なります。媒体側の数が増える経路はGoogle広告の拡張コンバージョン、媒体とGA4の差そのものは広告とGA4のCV数が合わないで扱っています。
3. 二重計上でも崩れない数字と、崩れる数字#
二重計上で崩れるのは絶対値だけです。チャネル間の比は崩れません。そして客単価は、崩れないほうに入ります。
客単価は、売上を注文数で割った値です。
客単価 = 売上 ÷ 注文数
購入が2回計上されると、売上も注文数もそろって2倍になります。分子と分母が同じ倍率で膨らむので、割った結果は変わりません。「客単価が普段どおりだから大丈夫」という読み方は、ここで成り立たなくなります。客単価は、この症状の検知には使えません。
購入率とRPS（セッションあたり売上）は、上がる側に振れます。購入したセッションの数も、売上も、そろって膨らむからです。ここまでは全部、絶対値の話です。
崩れないのは比のほうです。すべての注文が一律に2回計上されているなら、チャネル別の売上シェアも、RPSの順位も、1つも入れ替わりません。倍率は全チャネルに同じだけ乗るので、比を取った時点で相殺されます。
ただし、これは一律に起きている場合に限ります。特定の決済手段の完了ページでだけ、あるいは特定のキャンペーンの着地ページでだけ二重に送信されているなら、そのチャネルだけが過大に評価されます。そこへ予算を寄せると、修正が終わったあとに配分を組み替えることになります。
一律か偏りかは、チャネルの1行を見ていても判定できません。1段下げて、キャンペーン単位で確かめます。ただしキャンペーン単位の数値はその期間のスナップショットなので、前期比はここには出ません。症状が出る前の期間と、出たあとの期間を、同じ粒度で2回読んで並べることになります。
ここで「修正が終わるまで判断を止める」という選択肢が浮かびます。ただ、原因の特定に1日で着いても、送信の仕組みに手を入れて反映を待つなら数週間先です。その間も広告費は毎日出ていきます。だから問いが変わります。「GA4の数字をどう修正するか」ではなく、「膨らんだままの数字で、どのチャネルに予算を寄せるか」。後者に必要なのは正しい絶対値ではなく、同じ倍率が乗った状態でも比較できる並びのほうです。
RevenueScopeの解決策
RevenueScope は、チャネル別のセッション・売上・RPSを1画面で表示します。行を開くと、そのチャネルの中のキャンペーン別に売上・RPS・客単価・購入率を表示します。売上はサイトの購入イベントから受け取るので、二重に送信されていればこちらの売上も同じ倍率で膨らみます。だから使うのは比のほうで、判断に効くのもそちらです。
「直近30日、チャネル別のRPSと売上シェアは？」とMCP経由でChatGPTなどのAIアシスタントに尋ねると、次の形で返ってきます。説明のために架空店舗ミナミで書き出します。
| チャネル | セッション | 売上 | RPS | 売上シェア |
|---|---|---|---|---|
| Google検索 | 4,000 | 60万円 | 150円 | 40% |
| Google広告 | 2,000 | 45万円 | 225円 | 30% |
| 3,000 | 30万円 | 100円 | 20% | |
| Direct | 2,000 | 15万円 | 75円 | 10% |
※ 数値は説明用に置いた架空店舗ミナミのもので、丸めた値です。デモ画面が読んでいるのは見本ECのサンプルデータ（日々更新）なので、金額も並び順も上の表とは一致しません。売上シェアは表の売上から計算した値です。
購入がすべて2回計上されていれば、売上もRPSもそろって2倍になります。60万円は120万円に、150円は300円に。それでもシェアは40%のままで、RPSの順位も入れ替わりません。今日決められるのは、RPSが最も高いGoogle広告に予算を寄せるかどうかです。
ただし225円は、Google広告という行の平均です。行を開くと、指名キーワードのRPSは360円、汎用キーワードは90円。225円で配信しているキャンペーンは、この中に1本もありません。
見るのは、この2本のほうです。症状が出る前の期間で同じ2本を読み、そこからの伸び方を並べます。二重計上が一律なら、360円も90円もそろって同じだけ膨らんでいるので、どちらを伸ばすかの判断は変わりません。片方だけが膨らんでいれば、二重に記録されているのは配信の一部だけということです。平均のままでは、その判定ができません。
FAQ#
よくある質問#
Q. 購入数が多い期間の売上は、レポートから丸ごと外したほうがいいですか？
A. 外さなくてかまいません。絶対値は使えませんが、チャネル間の売上シェアとRPSの順位は残ります。丸ごと外すと、比較できる期間そのものが無くなります。外すのは金額を報告する場面だけで十分です。
Q. 客単価が普段どおりなら、二重計上は起きていないと考えてよいですか？
A. いいえ。売上と注文数が同じ倍率で膨らむので、客単価は変わりません。二重計上が起きていても普段どおりに見えます。確認は、カート側の確定注文数との日次の突き合わせで行ってください。
Q. トランザクションIDを送っていれば、タグが2回発火しても購入数は増えませんか？
A. 同じトランザクションIDで2つの購入が登録されていれば、購入の重複は除去されます[1]。ただしIDが空の文字列だと、購入イベントはすべて重複として除去されます[1]。IDはオーダーごとに一意で、動的な値である必要があります[1]。
Q. 修正にはどれくらいかかりますか？
A. 原因の特定は1日で完了できることが多く、タグ側の修正であれば作業自体も短時間です。時間がかかるのは、修正後のデータが溜まって前期比が読めるようになるまでです。週次で比べるなら、確定するのは数週間先になります。
まとめ#
GA4の購入数がカートの確定注文数より多いとき、集計の側に不具合はありません。届いた回数が、実際の注文回数と一致していないだけです。原因は購入完了ページの再読込、購入タグの二重発火、トランザクションIDの不備。確認する場所は原因ごとに異なります。IDに空の文字列を入れているときと、全注文で同じ値を使い回しているときは、購入数が少なく出る側に振れます[1]。IDそのものを送っていなければ、重複は除去されずに増える側へ振れます。
客単価は、売上と注文数が同じ倍率で膨らむので変わりません。検知には使えないと決めておいてください。使えるのは、カート側の確定注文数との突き合わせのほうです。
修正が終わるのを待つ必要があるのは、金額そのものを報告するときだけです。チャネル別のRPSと売上シェアを開き、いまの順位を控えてください。倍率が一律に乗っている限り、その順位は修正のあとも同じです。予算の配分は、今日決められます。
どの広告が売上を生んでいるか、一目でわかる
月5,000セッションまで、AIアナリストもずっと無料。クレジットカード不要。最短5分で導入。
