GA4 Measurement Protocol デバッグ: 2xx では何も証明できない理由

GA4 Measurement Protocol は、有効なイベント、名前を間違えたイベント、client_id のないイベント、作り話のシークレットなど、ほとんどどんな内容を送信しても 2xx ステータスを返します。そのため、デバッグにステータスコードは役に立ちません。GA4 Measurement Protocol の呼び出しをデバッグするには、同じ本文を /debug/mp/collect の検証サーバーへ送り、返された validationMessages を読み、示された問題を修正してから、DebugView または Realtime で到着を確認します。

最後の手順は、思っている以上に重要です。なぜでしょうか。検証サーバーは API secret を確認しないため、ペイロードが検証を通り、実際のエンドポイントから 204 が返ってきても、プロパティには届かないことがあります。私が以前見たチームも、誰かがシークレットをもう一度コピーしようと思い付くまで、まさにこの問題で1週間を失いました。

キャンペーンを追跡するためにサーバーサイドイベントを設定するなら、その前にリンクに何を含めるべきかは、UTM を最初から最後まで追跡する方法の基礎ガイドで説明しています。この記事では、イベントを送ったのに何も表示されない場面を扱います。

Measurement Protocol が何に対しても 2xx を返す理由

Google のプロトコルリファレンスは率直です。HTTP リクエストを受信するとエンドポイントは 2xx ステータスコードを返し、ペイロードの形式が不正でもデータが処理されなくてもエラーを返しません。収集は送信して終わりです。サーバーが処理を待つことはありません。

私たち自身でも確認しました。偽の measurement ID と作ったシークレットを付け、/mp/collect へ {"garbage":true} という本文を POST すると、本文が空の HTTP 204 が返りました。完全なイベントの場合と同じです。

ステータスコードを基準にした再試行ロジックで検出できるのは、ネットワーク障害だけです。それ以外は検出できません。GA4 がイベントを破棄したことも分からないのです。そのためには、もう一つのエンドポイントが必要です。

/debug/mp/collect の検証サーバーを使う方法

Measurement Protocol の検証サーバーは同じホスト上にあります。クエリ文字列も本文も同じです。

curl -s -X POST \
  "https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXXXX&api_secret=YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"events":[{"name":"session_start","params":{"firebase_x":1}}]}'

空の本文ではなく、JSON 本文付きの 200 を返します。このテスト用ペイロードには3つの問題があり、サーバーは最初に見つけたものを報告します。

{
  "validationMessages": [
    {
      "fieldPath": "client_id",
      "description": "Measurement requires a client_id.",
      "validationCode": "VALUE_REQUIRED"
    }
  ]
}

client_id を追加すると、次は NAME_RESERVED が session_start に対して返ります。イベント名を変更すると、次は firebase_ プレフィックスです。各メッセージには fieldPath、人間が読める説明、コードが含まれます。Google が文書化しているコードには、VALUE_INVALID、VALUE_REQUIRED、NAME_INVALID、NAME_RESERVED、VALUE_OUT_OF_BOUNDS、EXCEEDED_MAX_ENTITIES、NAME_DUPLICATED があります。

空の配列、"validationMessages": [ ] は、構造に問題がないことを意味します。/debug/mp/collect に送ったものは保存されません。開発中はいくらでも繰り返し送って構いませんが、デバッグ呼び出しだけではデータの到着を証明できないことを覚えておいてください。

検証サーバーが確認しないこと

多くのチュートリアルがこの部分を省いています。Google のイベント検証ページには、検証サーバーは api_secret を検証しないと明記されています。2026年9月22日のテストでは、measurement ID も確認しませんでした。G-FAKE123 とシークレット nonsense を送ると、空の validationMessages 配列が返りました。

間違ったシークレットでも通ります。失効したもの、別のデータストリームのもの、G- の入力ミスでも同じです。Measurement Protocol の api_secret は、私が最もよく見る「有効なペイロードなのにデータがない」原因です。確認するには、イベントが届くのを見るしかありません。

もう一つの盲点は検証モードです。デフォルトではサーバーは RELAXED モードで実行されます。このモードでは、Google の制限に反する2つの内容も通りました。パラメーターが26個あるイベントと、120文字のパラメーター値です。デバッグ本文に "validation_behavior": "ENFORCE_RECOMMENDATIONS" を追加すると、どちらも EXCEEDED_MAX_ENTITIES と VALUE_TOO_LONG で失敗します。本番を緩和モードのままにするとしても、私は必ず厳格モードで検証します。チェッカーになるか、ただの形式的な承認になるかの違いです。

GA4 DebugView と Realtime でサーバーイベントを見る

ペイロードの検証が通ったら、実際のエンドポイントへ送り、届く様子を確認します。サーバーイベントに使えるビューは2つあります。標準レポートは反映に24から48時間かかることがあるため、その一つではありません。

DebugView では、イベントごとのオプトインが必要です。Google の検証ガイドでは、イベントの params に "debug_mode": 1（または true）を入れ、正の engagement_time_msec を設定するよう求めています。このフラグを持つイベントだけが表示されるため、1つのイベントにフラグがないバッチは半分空に見えます。Admin、DebugView の順に開き、1分ほど待ってください。

Realtime には追加設定は必要ありません。「Event count by Event name」カードまでスクロールして、イベントを探します。Google は、ユーザーのアクティビティを Realtime に表示するには session_id と engagement_time_msec が重要だと説明しています。そのため、イベントの検証が通ったのに Realtime が空のままなら、まずこの2つを確認してください。

同じガイドには、もう一つ注意点があります。ウェブストリームでは、有効なイベントに gtag.js がすでに使った client_id を設定すると説明されています。人工的な ID でも集計され、各 ID は別ユーザーになりますが、ブラウザーセッションに結び付くことはありません。セッションを中心に作ったレポートでは、これは出所が分かるまで説明できない「1イベントだけのユーザー」の長い尾として現れます。詳しくは次のセクションで説明します。足りないのがイベントではなくキャンペーンデータなら、GA4 に UTM パラメーターが表示されない場合でこの問題の DebugView 側を解説しています。

よくあるペイロードエラーとバリデーターの回答

壊れたイベントのほとんどは、いくつかのパターンに当てはまります。2026年9月22日にそれぞれを送ったとき、検証サーバーが返した内容を示します。

2つの行には補足が必要です。リファレンスによれば ga_ プレフィックスは予約済みですが、試したときのバリデーターは両方のモードで ga_session_id を受け付けました。そのため、空の配列を許可の証拠と考えないでください。また、100文字の値制限には、完全な遷移先 URL が頻繁に引っ掛かります。UTM タグを5つ付けたランディングページは、その長さを超えることがよくあります。

client_id 自体が微妙な点です。緩和モードの検証ではどの文字列でも通りますが、厳格モードでは c1 と elido-12-4711 の両方が「It should be in . format」というメッセージで拒否されました。イベントをブラウザーセッションに結び付ける必要があるなら、実際の _ga の値を送ってください。GA4 のサーバーサイドトラッキングガイドで、その結び付けを詳しく説明しています。

Elido の GA4 転送機能と接続テストでの使い方

Elido は短縮リンクのクリックをサーバーサイドで GA4 に転送します。Integrations の GA4 カードに Measurement ID と Measurement Protocol API secret を貼り付けると、そのワークスペースで以後発生するすべてのクリックが1つの link_click イベントになります。

{
  "client_id": "elido-12-4711",
  "events": [
    {
      "name": "link_click",
      "params": {
        "workspace_id": 12,
        "link_id": 4711,
        "slug": "spring-26",
        "country": "DE",
        "device": "mobile",
        "destination": "https://shop.example/spring?utm_source=newsletter",
        "engagement_time_msec": 100
      }
    }
  ]
}

client_id は elido-<workspace>-<link> なので、1つのリンクへのすべてのクリックが同じ GA4 ユーザーとして記録され、ブラウザーセッションに結び付くものはありません。Cookie を使わずに行う場合の正直なトレードオフです。合計値と slug、country、device による内訳は機能しますが、ユーザー数とセッションファネルは機能しません。country と device は通常のイベントパラメーターです。先にカスタムディメンションとして登録してください。また、100文字を超える destination は上の表の制限に掛かるため、代わりに slug または link_id を使ってレポートを作成してください。

接続テストボタンは、この記事で推奨している順序に従います。

まず、人工的な link_click に elido_test: true を付けて /debug/mp/collect に送ります。validationMessages が空でなければテストは失敗し、Google の説明をそのまま表示します。配列が空なら、同じイベントを実際に /mp/collect へ送ります。ボタンの下には、ベンダーの応答（HTTP ステータス、Measurement ID は含むがシークレットは含まないデバッグエンドポイント、Google の本文）と、Measurement Protocol は API secret を検証しないという注記が表示されます。

つまり緑色が意味するのは「有効で、Google が受け取った」ということです。「あなたのプロパティに入った」という意味ではありません。テストイベントには debug_mode: 1 と elido_test: true が含まれるため、link_click として DebugView に表示されます。Realtime でも確認できます。すべてのランディングページにタグを設置せず GA4 でクリックイベントを見たいなら、ワークスペースを作成し、まずテスト用プロパティを GA4 カードに指定してください。

効果的な GA4 Measurement Protocol デバッグの順序

GA4 のイベントが表示されないときは、次の順序で進め、最初に失敗したところで止めます。

1. 本文を /debug/mp/collect に送り、validation_behavior を ENFORCE_RECOMMENDATIONS に設定します。すべてのメッセージを修正します。
2. Admin、Data streams、ウェブストリーム、Measurement Protocol API secrets の順に開き、API secret をもう一度コピーします。G- ID と同じストリームのものか確認します。
3. /mp/collect に debug_mode: 1 を付けたイベントを1つ送り、2分間 DebugView を見ます。
4. フラグを外して Realtime を確認し、その後、標準レポートへの反映を1〜2日待ちます。

私自身のデバッグの多くは、ステップ2で終わります。Google のトラブルシューティングページも、正しいシークレットか、まだ有効か、正確にコピーしたかという同じ3つの質問から始まります。数値が流れるようになってもリンクのクリック数と一致しない場合は、短縮リンクのクリック数と GA4 のセッションで差の理由を説明し、サーバーサイドコンバージョントラッキングで通常続いて発生するコンバージョンイベントを扱っています。コンバージョントラッキングページにある他の送信先にも、検証してから確認する習慣を適用できます。

ブログ内の関連記事

• リダイレクト経由の GA4 サーバーサイドトラッキング - 認証情報、ペイロードの形、client_id の結び付け。
• リンク分析における Mixpanel と GA4 の比較 - クリックデータをどのツールに置くべきか。
• Mixpanel のリンクトラッキング - Mixpanel に向けた同じ転送機能と、独自の「何に対しても 200」を返す挙動。
• GA4 に UTM パラメーターが表示されない場合 - このデバッグ問題のキャンペーンデータ版。
• サーバーサイドコンバージョントラッキング - GA4、Meta CAPI、TikTok を横並びで比較。