この工程でやること
前の工程で、ブラウザの中にあった識別情報を注文データへ預けました。ここからはその情報を使って、決済が確定したあとにサーバー側からGA4へ購入を送ります。
きっかけになるのは、決済が完了したときに届く通知です。Shopifyには、注文の支払いが確定した時点で自動的にお知らせを送る仕組み（Webhook）があり、その中のorders/paidという通知を受け取って処理を始めます。送り先はGA4のMeasurement Protocol（サーバー側からGA4へ直接データを送るための窓口）です。
この記事では、なぜブラウザ側ではなく通知を起点にするのか、同じ購入を二重に数えないためにどうするか、そして数字が合っているかをどう見張るかをまとめます。
なぜ決済完了の通知を起点にするのか
完了ページが表示されるとは限らない
購入を「購入完了ページが表示されたかどうか」で判定すると、数字は簡単にぶれます。決済のあと通信が切れる、ユーザーが完了ページを見る前に画面を閉じる、ブラウザの戻る操作でページが再表示される。どれもよくある動きで、そのたびに1件が抜けたり増えたりします。表示という不安定な出来事を基準にしている限り、この揺れは消せません。
決済が確定したという事実だけを扱う
決済完了の通知は、支払いが確定したときにサーバー同士でやり取りされるお知らせです。ユーザーの画面がどうなったかに左右されないので、届く条件がはっきりしています。ブラウザの種類や拡張機能、通信の状態といった、こちらでは制御できない要素の影響を受けない。再現しやすい基準を選ぶことが、安定した計測の第一歩になります。
通信の切断や画面を閉じる操作で抜け落ち、戻る操作で二重に数えることもある
支払いが確定した事実だけを扱うため、ユーザーの画面の状態に左右されない
図を一言でまとめると、目に見える画面の出来事ではなく、システム側で確定した事実を数える、という切り替えです。
送るのは3つの情報だけで足りる
GA4へ購入を伝えるのに必要な情報は多くありません。誰の購入かを示す識別子、どの注文かを示す識別子、そして金額と通貨。まずはこの3つを確実に送れる状態を作ることを目標にします。最初から項目を増やすと、うまくいかないときに原因の候補が広がって切り分けに時間がかかる。安定して届くようになってから、必要性の高いものを1つずつ足していくほうが結果的に早いです。
送信の仕組みで押さえる4つのポイント
通知の送り主を必ず確かめる
通知の受け口は、外部からアクセスできる入口でもあります。送り主が本物かどうかを確認しないまま処理すると、偽の注文データを受け取って架空の購入を記録してしまう可能性がある。確認に失敗したら処理しない、という単純なルールを最初から徹底しておきます。ここを一時的に緩めた対応がそのまま残ってしまうケースが多いので、例外を作らないのが結局いちばん安全です。
同じ注文を二度数えない
一時的な不調で送信に失敗し、あとから送り直す場面は必ず出てきます。このとき、その注文をすでに送ったかどうかを判定できないと、1件の購入が2件になる。判定の基準になるのが注文ごとの識別子です。送信済みの注文を記録しておき、同じ識別子が来たら送らない。逆に、除外の条件を厳しくしすぎると本来送るべき購入まで弾いてしまうので、送り直せることと二重に数えないことを、必ず同時に設計します。
識別情報が欠けた注文をどう扱うか
実際に運用すると、識別情報が入っていない注文が一定数出てきます。前の工程の書き込みが失敗したケース、店頭や電話など別経路で作られた注文などです。大事なのは、そのときに何を優先するかを事前に決めておくこと。送らずに保留するのか、金額だけでも記録するのか。判断の基準を決めておけば、担当者によって扱いが変わることを防げます。これは技術の問題というより、運用のルールとして決める部分です。
「送った」ではなく「成功した」で管理する
送信処理は、実行したかどうかではなく、相手に受け取られたかどうかで管理します。成功件数、失敗件数、失敗の理由を記録しておけば、送り直すべき注文を機械的に取り出せる。運用でありがちなのは「送ったはず」「たぶん成功している」という曖昧な状態で、これがあると数字がずれたときに原因を説明できません。数えられる形にしておくことが、そのまま品質の担保になります。
現場で出てくる相談への答え
広告の管理画面と数字が合わない
媒体の管理画面とGA4の数字が違うとき、まず疑うべきは実装ミスではなく定義の差です。いつの時点で計上するか、成果をどの接点に割り当てるか、何を対象イベントとするか。これらが違えば、どちらも正しく動いていても数字はずれます。許容できる差の範囲を先に決めておき、それを超えたときだけ、抜けによるものか二重計上によるものかを切り分ける。この順番で見ると原因の特定が早くなります。
テスト注文では動くのに本番でずれる
テストでは、素直に成功するケースばかりを試しがちです。本番になると、キャンセル、再決済、一部返金、送り直しといった例外が次々に出てきます。この差を想定していないと、テストは通ったのに本番だけ不安定という状態になる。注文の状態ごとに、送るのか送らないのかを一覧にして整理しておくと、運用開始後のトラブルをかなり減らせます。
運用担当が技術的なログを読めない
日々の運用を担当する人が、コードや詳細な記録を読めなくても改善を回せる形にしておくことが大事です。見る指標は、送信の成功率、失敗理由の上位、まだ送り直していない件数の3つくらいで足ります。技術的な詳細は裏側に置いたまま、いまどこに問題があるかだけが分かる画面を用意する。これだけで、エンジニアが常駐していない体制でも改善を続けられます。
導入・運用チェックリスト
表を一言でまとめると、入口を守り、二重に数えず、結果を見える形にして、秘密の値を外に出さない。この4点が、この工程の最低ラインです。
小さく回して改善する
週に一度、送信の成功率を確認し、失敗理由の上位2件だけに絞って対処します。直したら送り直して差分を確かめ、効果があったやり方だけを標準の手順に加える。このサイクルが回るようになったら、確認の間隔を月次に広げて運用の負荷を下げていく。最初から完璧な分析を目指すより、小さく回せる仕組みを作るほうが結果につながります。
まとめ
決済完了の通知を起点にして、サーバー側からGA4へ購入を送る。この形にすると、ユーザーの画面で何が起きたかに左右されず、支払いが確定した事実だけを数えられます。押さえるのは、送り主の確認、注文ごとの重複防止、識別情報が欠けたときの扱い、そして成功したかどうかで管理すること。
3記事を通して積み上げてきたのは、どこで切れているかを特定し、切れる前に情報を預け、確定した事実をきっかけに送り直す、という流れです。専門的な実装はAIエージェントに任せながらでも、何を正しい数字とするかの判断さえ人が持っていれば、非エンジニア中心の体制でも計測は安定させられます。