ヘッドレスサイトでGA4のコンバージョンを正しく記録する設計

このシリーズで扱う範囲

ヘッドレス構成のECサイトを運用していると、GA4に記録された購入数が、実際の受注数より明らかに少ないという食い違いに気づくことがあります。商品ページの閲覧やカート追加は問題なく取れているのに、購入だけが合わない。広告の費用対効果を判断したいのに、肝心の売上側の数字が信用できない状態です。

原因の多くは、カートから決済画面へ移る瞬間にあります。ヘッドレス構成では、商品を見せるフロント側と、決済を担うチェックアウト側が別々の仕組みで動いているため、計測の線がその境目で切れてしまう。設定ミスというより、構成上そうなりやすい、という性質のものです。

このシリーズでは、購入コンバージョン(CV。ここでは「決済が確定した注文」を指します)を安定して記録するための設計を、3つの工程に分けて解説します。

購入CVを取りこぼさないための3段構え

順番に積み上げる形になっていて、どれか1つでも欠けると数字が合いません。

1. どの境目でデータが失われるのかを特定する
2. 決済画面へ移る前に、ユーザーを識別する情報を注文側へ引き継ぐ
3. 決済完了の通知をきっかけに、サーバー側からGA4へ購入を送信する

図を一言でまとめると、ブラウザの中にしかない情報を決済前に注文へ預けておき、決済が終わったあとにサーバー側から送り直す、という流れです。

詳しく知りたい方へ

実装の工程ごとに、3記事に分けて解説しています。上から順に読むと、なぜその設計にしたのかという判断の部分から、実際の組み立て方まで一続きで理解できます。

使用技術

• Next.js（サイトの表側を作る土台）
• Shopify Storefront API / Admin API（商品・注文データのやり取り）
• Shopify Webhook（決済完了などを自動で知らせる通知の仕組み）
• GA4 Measurement Protocol（サーバー側からGA4へ直接データを送る窓口）

設計前に決めておく運用ルール

技術的な組み立てと同じくらい、運用のルールを先に決めておくことが効きます。実装を始める前に、次の4点を関係者で合意しておくと後戻りが減ります。

• 実際に使っている環境変数名やキー名は公開しない
• 管理用のAPIには必ず認証をかける
• 引き継ぎ処理が失敗しても、購入の導線は止めない
• ログには個人情報や認証情報を残さない

とくに3つ目は、計測のために売上を止めては本末転倒という判断です。計測はあくまで補助であって、購入体験より優先されるものではありません。