はじめに
GA4の画面を開いて、購入数が受注管理の数字より2割ほど少ない。そんな状態に気づいたとき、まず疑いたくなるのはタグの設定ミスです。ただ、ヘッドレス構成のECサイトでは、設定が正しくても購入だけが記録されないことが起こります。
理由は、商品を見せるフロント側と決済を担うチェックアウト側が、別々の仕組みとして動いているためです。計測の担当範囲が画面の移動で分断されるので、その境目でデータが引き継がれないと、購入イベントだけが行方不明になります。
この記事では、どの境目で何が失われるのかを整理します。原因の切り分けができるようになると、次にどこへ手を入れるべきかの判断がつくようになります。
データが途切れる3つの境目
表を一言でまとめると、欠損は1か所ではなく、購入までの流れの中の3つの地点で別々の理由から起きる、ということです。順番に見ていきます。
決済画面へ移る瞬間
カートから決済画面へ移る瞬間は、計測の観点でもっとも情報が失われやすい地点です。ブラウザの中に保持していた識別情報は、そのページを離れた時点で決済側には渡りません。何も手を打たないまま遷移すると、購入したという事実だけが単独で残り、どの広告やどの検索から来たユーザーの購入なのかを結び付けられなくなります。遷移する前に情報を預けておく処理を標準の流れに組み込むだけで、後工程の安定性が大きく変わります。
注文データを受け取る瞬間
決済完了の通知(Webhook。何かが起きたときに自動でお知らせが届く仕組み)を受け取れていても、その注文データに識別情報が入っていなければ、GA4へ正しく購入を送ることはできません。現場で起きるのは「受注は見えているのに、GA4の購入だけ増えない」という状態です。送信先の設定ではなく、送るための材料が足りていないことが原因なので、注文を受け取った段階で必要な項目がそろっているかを確認する仕組みが要ります。
送信をやり直す瞬間
一時的な通信エラーで送信に失敗し、あとから送り直す場面は必ず発生します。このとき、同じ注文をすでに送ったかどうかを判定する仕組みがないと、1件の購入が2件として数えられます。逆に、除外の条件を厳しくしすぎると、本来送るべき購入まで弾いてしまう。送り直せることと、二重に数えないこと。この2つを同時に成り立たせる設計が必要で、片方だけでは数字が安定しません。
何を「購入」とみなすかを先に決める
完了ページの表示ではなく、決済の確定を基準にする
購入を「サンクスページが表示されたか」で判定すると、ブラウザの戻る操作や表示の失敗、通信の中断で数字がぶれます。運用上は「決済が確定した注文」を基準にしたほうが再現性が高く、分析・広告・経営レポートの数字をそろえやすくなります。何をもって1件の購入とするかを最初に統一しておくと、あとからの集計トラブルや部門間の認識のずれを防げます。
数字が合わない原因は1か所とは限らない
「設定はしたのに数字が合わない」という状態は、イベント名をそろえても件数が一致しない、広告の管理画面とGA4で購入数がずれる、特定の注文だけ抜ける、といった形で現れます。原因が複数の層に分かれているため、1つ直しても解消しないことがある。まず「どの境目で欠損したか」を切り分ける視点を持つと、当てずっぽうの修正を避けて、手を入れる順序を決められます。
フロント計測とサーバー計測の役割を分ける
フロントだけで購入まで追いきれない理由
ブラウザ側の計測は、どのページが見られたかという行動の把握には向いています。ただ、購入の確定まで完全に任せるのは現実的ではありません。ブラウザの種類、拡張機能、通信の状態、画面遷移の方式の違いによって、最後のイベントだけが欠けることが起きるためです。フロントは「行動の把握」、サーバーは「確定した事実の記録」と役割を分けておくほうが、数字の説明責任を持ちやすくなります。
複数のツールで数字が完全一致しない前提
GA4と広告媒体の管理画面が常に完全一致する運用は、実際には成立しません。計上のタイミング、成果をどの接点に割り当てるかの考え方、除外条件がそれぞれ違うためです。どこまでを許容できる差とするかを先に決め、その範囲を超えたときだけ調査する。このルールがあると、日々の運用を止めずに改善を続けられます。
技術者が少ない体制での進め方
社内にエンジニアが少ない場合、最初から細かい最適化を狙うより、壊れにくい基本の形を優先するほうが結果につながります。購入イベントの定義を統一すること、識別情報の引き継ぎを実装すること、成功率の確認を定例にすること。この3点に絞れば、専門知識が深くなくても段階的に品質を上げられます。実装そのものはAIエージェントに任せる形で進めましたが、何を正とするかの判断だけは人が決める必要がありました。
設計に入る前に決めておく3つのこと
何を正しい数字とするか
購入確定をどのイベントで判定するか、売上の金額に税や送料を含めるか、キャンセルや返金をどの時点で反映するか。ここを決めておかないと、同じデータでも担当者ごとに解釈が変わります。文書として残しておけば、あとからメンバーが増えても判断の基準がぶれず、引き継ぎも楽になります。
何を引き継ぐか
購入の時点まで持ち運ぶ情報の種類を決めます。最低限は、分析用の識別子、注文の識別子、どのサイト由来かを示す識別子の3つ。項目を増やしすぎると管理の手間と情報漏えいのリスクが上がるため、最初は購入との紐付けに必須なものだけに絞るのが安全です。必要になった項目は、運用の実績を見ながら段階的に足していきます。
どう監視するか
成功件数と失敗件数を見える形にして、失敗したときの送り直し手順を担当者が実行できるように用意し、週次または隔週で確認する。監視は問題の発見だけでなく、どこから改善するかの優先順位を決めるためにも使えます。数値をもとに判断する形にしておくと、特定の人の勘に頼らない運用になります。
まとめ
ヘッドレス構成で購入CVが欠けるのは、決済画面へ移るとき、注文を受け取るとき、送信をやり直すときの3つの境目で、それぞれ別の理由からデータが失われるためです。設定ミスを探す前に、どの境目で切れているかを切り分ける。そのうえで、購入の定義・引き継ぐ情報・監視の方法を先に決めてから実装に入ると、非エンジニア中心の体制でも判断軸を持って進められます。
次の記事では、最初の境目である決済画面への遷移に対して、識別情報をどう引き継ぐかを解説します。