PortfolioなぜWebhook起点にするか
購入完了を確実に捉えるには、フロント画面よりも決済結果に近いイベントを起点にする方が安定します。
そのため、orders/paid のような決済完了Webhookを基準に purchase を送信する設計が有効です。
ダミー送信イメージ
const payload = {
client_id: "1234567890.1234567890",
events: [
{
name: "purchase",
params: {
transaction_id: "ORDER-10001",
value: 12345,
currency: "JPY",
},
},
],
};
await fetch("https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXX&api_secret=DUMMY_SECRET", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(payload),
});
すべて説明用のダミー値です。実運用のID・Secretは公開しないでください。
1. 全体設計（非エンジニア向けに先に理解する）
1-1. 役割分担
この仕組みは、フロント・Webhook・GA4送信の3つが役割分担することで安定します。フロントは購入前識別子の保存、Webhookは購入確定の受信、サーバー送信はGA4への記録という形です。どこか1つに責務を寄せすぎると障害時の切り分けが難しくなるため、「どの処理をどこで担うか」を最初に決め、運用ドキュメントとして残すことが重要です。
1-2. なぜ「orders/paid」を使うのか
orders/paid を基準にすると、購入完了画面の表示成否やブラウザ挙動に依存せず、決済確定に近い事実データを扱えます。フロントイベントだけでは、通信遮断や画面離脱で取りこぼしが発生しやすいですが、Webhook起点ならその影響を減らせます。特に非エンジニア運用では「再現しやすい基準イベント」を選ぶことが、安定運用の第一歩になります。
1-3. 何を最小セットにするか
最小セットを明確にすると、導入初期の混乱を大きく減らせます。一般的には client_id、transaction_id、value/currency の3要素が基本で、まずはこの送信品質を安定させることを目標にします。最初から多項目を入れると失敗原因が複雑化するため、安定稼働を確認した後に、必要性が高い項目から段階的に拡張する進め方が安全です。
2. 実装時の重要ポイント
2-1. 署名検証（安全性）
Webhookは外部から到達可能な入口になるため、送信元検証は必須です。署名検証を省くと、偽の注文データを受け取って誤送信するリスクが生まれ、計測値だけでなく運用全体の信頼性を損ないます。初心者向け運用では「検証に失敗したら処理しない」という単純なルールを徹底し、例外的な暫定対応を常態化させないことが重要です。
2-2. 重複防止（数字の信頼性）
計測品質を守るうえで最も重要なのが、同一注文の二重送信防止です。transaction_id を基準に「すでに送信済みか」を判定し、再送が必要な場合でも重複計上を起こさない仕組みを作ります。再送機能だけを先に入れると過大計上、重複除外だけを厳しくすると欠損につながるため、両者を同時に設計してバランスを取ることがポイントです。
2-3. フォールバック（欠損対策）
本番では、識別子が欠けた注文が一定数発生します。重要なのは、欠損時に「何を優先するか」を事前に決めておくことです。たとえば、送信可否の条件、補助情報の扱い、保留処理の有無などを定義しておけば、担当者ごとの判断ブレを防げます。フォールバックは技術対応というより、運用ポリシー設計として扱うと非エンジニアでも管理しやすくなります。
2-4. 成功判定（監視可能性）
送信処理は「実行したか」ではなく「成功したか」で管理する必要があります。レスポンス判定を明確にし、成功件数・失敗件数・失敗理由を記録しておくと、再送対象を機械的に抽出できます。運用現場でありがちな「送ったはず」「多分成功」の曖昧な状態をなくすことが、欠損防止と説明責任の両面で重要です。数値化できる監視設計が品質を支えます。
3. 現場の悩み別ガイド
3-1. 「広告管理画面と数字が合わない」
媒体管理画面とGA4の数字が合わない場合、最初に確認すべきは実装ミスではなく定義差です。計上タイミング、アトリビューション窓、対象イベントが異なると、正常でも差分は発生します。そのうえで、差分が許容範囲を超える場合に、欠損由来か重複由来かを切り分けると原因特定が速くなります。順序立てた確認手順を持つことが重要です。
3-2. 「テスト注文では動くのに本番でズレる」
テスト環境では単純な成功ケースが中心ですが、本番ではキャンセル、再決済、部分返金、再送など例外パターンが増えます。この差分を想定しないと「テストでは正常、本番で不安定」という状態になります。実務では、注文状態ごとのシナリオ表を作り、どの状態で送るか・送らないかを明確にして確認することで、運用開始後のトラブルを大幅に減らせます。
3-3. 「運用担当が技術ログを読めない」
運用担当がコードや詳細ログを読めなくても改善できるよう、監視画面の指標は業務判断に直結する形で設計します。たとえば成功率、失敗理由上位、未再送件数を定点観測すると、優先対応が明確になります。技術詳細は裏側に残し、日々の運用では「今どこに問題があるか」だけを見える化することで、非エンジニア主体でも継続改善が可能になります。
4. 導入・運用チェックリスト
4-1. 初心者向け運用ルール
初心者向け運用では、複雑な分析よりも「小さく回す仕組み」を作ることが成果につながります。まず週次で成功率を確認し、失敗理由の上位2件に絞って対処します。改善後は再送で差分を確認し、効果が出た施策だけを標準化します。このサイクルが回るようになったら月次レビューへ移行し、運用負荷と品質のバランスを最適化していくのが実践的です。