gtag.js または GTM を通じた GA4 クライアントサイドタギングは、ほとんどのチームがデフォルトとするアトリビューションのベースラインです。理想的な条件下では良好に機能します：高速な接続の Chrome デスクトップユーザー、アドブロッカーなし、ITP の24時間スクリプトセットクッキー上限が発動していない Safari セッション。2026年において、EU トラフィックでの理想的な条件カバー率はおよそ65〜75%です。
残りの部分 - uBlock Origin ユーザー、Brave の内蔵ブロッキング、iOS の Safari の Intelligent Tracking Prevention、NextDNS や Pi-hole などのネットワークレベルブロッカーの増加コホート - は、www.google-analytics.com に到達する前にイベントがドロップするか、_ga クッキーが消去されて使用可能なクライアント識別子なしに到達します。EU 重視のオーディエンスでの典型的なギャップはコンバージョンイベントの25〜35%です。一部の業界 - フィンテック、プライバシーツール、開発ツール - では、ユーザー層がアドブロッカー採用と相関するため、これよりも高くなります。
GA4 の Measurement Protocol は、これらすべてをバイパスするサーバーサイドのパスです。あなたのサーバーが Google のコレクションエンドポイントと直接通信します。ブラウザの状態は無関係です。この投稿では正確なセットアップを説明します：クレデンシャル、ペイロードの形、client_id のスティッチング、検証、そして gtag とサーバーサイドパスを並行して実行するチームのための重複排除パターン。
基盤となるコンバージョン転送アーキテクチャ - サーバーサイドが勝る理由と複数プラットフォームへのファンアウトの仕組み - はサーバーサイドコンバージョントラッキング概要で説明しています。このチュートリアルの Meta CAPI バージョンはMeta CAPI へのコンバージョン転送にあります。設定パターンは同じ形で、ここでは GA4 固有のパラメーターを扱います。
TL;DR#
- GA4 の gtag.js は、アドブロッカー（uBlock、Brave）と ITP（Safari クッキー有効期間の上限）により、典型的な EU トラフィックでコンバージョンイベントの25〜35%を失います。Measurement Protocol はリクエストがあなたのサーバーから発信されるため、これらをすべてバイパスします。
- 2つのクレデンシャルが必要です：データストリームの Measurement ID（
G-XXXXXXXX）と、Admin → Data Streams → Measurement Protocol API secrets で生成する API シークレット。両方とも2分以内に Elido のワークスペース設定に貼り付けられます。 client_idは GA4 セッションにサーバーサイドイベントを結びつけるフィールドです。Elido はショートリンクのリダイレクト時にファーストパーティ UUID クッキーを設定し、すべてのコンバージョン転送に含めるため、ブラウザから_gaクッキーを読む必要がありません。- 検証には約10分かかります：GA4 DebugView では Measurement Protocol イベントがおよそ10秒以内に表示されます。標準レポートへの反映には24〜48時間かかります。
必要な2つのクレデンシャル#
GA4 Measurement Protocol には2つの情報が必要で、どちらも GA4 Admin コンソールから取得します。
Measurement ID。 G-XXXXXXXX の形式で表されるデータストリーム識別子です。Admin → Data Streams → ウェブストリーム → ストリーム詳細パネルで確認できます。これはクライアントサイド設定で gtag('config', 'G-XXXXXXXX') に渡す ID と同じです - シークレットではなく、ページソースに表示されます。
API シークレット。 これはコレクションエンドポイントへのサーバーサイド書き込みを承認するクレデンシャルです。Admin → Data Streams → ウェブストリーム → Measurement Protocol API secrets → Create に移動します。シークレットは短い英数字の文字列です。サービスアカウントキーのように扱ってください：ワークスペースシークレットとして保存し、他のサービスクレデンシャルと一緒にローテーションし、ソースコードにコミットしないでください。
Elido では、Workspace Settings の Integrations → GA4 にこれらを貼り付けます。保存すると、Elido は GA4 デバッグエンドポイントに対してペアを検証し、接続を確認します。検証は即時です。このステップで 4xx が返ってきた場合、Measurement ID または API シークレットが間違っています。
イベントの形#
GA4 Measurement Protocol リファレンス（2026-05-12参照）はリクエストフォーマットを規定しています。エンドポイントは：
POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=<secret>
ボディには client_id、オプションの user_id、および events 配列が含まれます。purchase イベントのペイロードは次の通りです：
{
"client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"user_id": "user-shop-12847",
"events": [
{
"name": "purchase",
"params": {
"transaction_id": "ord_98231",
"value": 89.5,
"currency": "EUR",
"engagement_time_msec": 1,
"items": [
{
"item_id": "sku-spring-jeans-32-blue",
"item_name": "Spring Jeans 32 Blue",
"quantity": 1,
"price": 89.5
}
]
}
}
]
}
このペイロードで間違えやすい点がいくつかあります：
event_name は小文字のスネークケースでなければなりません。GA4 イベントリファレンス（2026-05-12参照）には推奨イベント名が記載されています：purchase、sign_up、generate_lead、add_to_cart。Purchase（大文字 P）を送信すると、GA4 のレポートで gtag で発火された purchase イベントとマージされず、別のイベントになります。プラットフォームは警告しません。イベントは奇妙な名前のカスタムイベントとして記録されるだけです。
engagement_time_msec は必須であり、正の整数に設定する必要があります。これがないと、GA4 はイベントをカウントしますがセッションエンゲージメントを認識せず、一部のアトリビューションモデルはエンゲージメント時間のないイベントを除外します。1 に設定すれば要件を満たすのに十分です。
event_params はイベントごとに25パラメーターまでです。これを超えるペイロードは Measurement Protocol が拒否します。拒否はデフォルトでサイレントです - イベントが受け入れられたかどうかに関わらず、リクエストはボディなしで 204 を返します。デバッグエンドポイント（検証セクションで説明）を使ってオーバーフローを検出してください。
user_id はオプションですが価値があります。サーバーサイドに永続的なユーザー識別子がある場合 - 注文テーブルのカスタマー ID、CRM のサブスクライバー ID - それを送信してください。GA4 はクロスデバイスアトリビューションにこれを使用し、サーバーサイドとクライアントサイドのイベント間の一致が向上します。
client_id のスティッチング：重要な理由と Elido での処理方法#
client_id は GA4 がサーバーサイドイベントをブラウザセッションに結びつけるために使用するフィールドです。gtag.js がページで実行されると、_ga クッキーを読み取り、その UUID を発火するすべてのイベントの client_id として使用します。サーバーサイドイベントが同じ client_id を持つ場合、GA4 はそれらのイベントを同じユーザージャーニーおよびセッションにまとめることができます。
課題はその UUID をサーバーサイドに持ち込むことです。_ga クッキーはあなたのドメインのファーストパーティクッキーであるため、サーバーはチェックアウト時にそれを読み取り、コンバージョンペイロードに含めることができます。しかしこれは、ユーザーのブラウザに _ga が設定されている場合にのみ機能します - それはまさに ITP とアドブロッカーで失う集団です。
Elido はこれをリダイレクト層で解決します。ユーザーがショートリンクをクリックすると、Elido のエッジハンドラーが UUID を生成し、リダイレクトレスポンスのファーストパーティ _elido_cid クッキーとして設定します - ユーザーがあなたのサイトに到達する前に。UUID は宛先 URL に ?elido_click=<uuid> としても追加されます（ワークスペースごとに設定可能）。フローは次のとおりです：
ランディングページまたはタグマネージャーが URL から elido_click を読み取り、注文のカスタム属性に書き込みます。コンバージョン時に、注文ウェブフックが UUID を運びます。Elido はそれを検索し、client_id をその UUID に設定した Measurement Protocol ペイロードを構築し、GA4 に転送します。
これは _ga をブラウザから読み取るよりも信頼性が高いです。UUID はクリック時、つまりユーザーのブラウザセッションがクッキーを受け入れるかどうかを決定する前にキャプチャされるからです。ITP が24時間以内に _ga クッキーを消去しても、Elido の _elido_cid クッキーはショートリンクドメインのファーストパーティクッキーとして保持され - 注文属性はデータベースに関係なく保持されます。
GA4 イベント送信ガイド（2026-05-12参照）では、クライアントとサーバーパスにおける client_id の動作を説明しています。
Elido の転送：実際の curl#
POST /v1/conversions が click_id 付きで届くと、Elido は Measurement Protocol ペイロードを組み立てて転送します。Elido をバイパスして GA4 MP 側の配線を直接テストするための curl は：
curl -X POST \
"https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET" \
-H "Content-Type: application/json" \
-d '{
"client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"user_id": "user-shop-12847",
"events": [
{
"name": "purchase",
"params": {
"transaction_id": "ord_98231",
"value": 89.50,
"currency": "EUR",
"engagement_time_msec": 1
}
}
]
}'
GA4 は有効なイベントにも無効なイベントにも 204 を返します。HTTP ステータスコードだけでは、不正なイベントと正常な取り込みを区別できません。イベントが実際に届いたかどうかを確認するには、開発中にデバッグエンドポイントを使用してください：
POST https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET
デバッグエンドポイントは、各イベントの検証エラーを列挙した JSON ボディを返します。パラメーター名が間違っているイベント、25パラメーターを超えるペイロード、または不正な client_id がここで表示されます。
Elido を使用している場合、同じ検証の可視性は GET /v1/conversions/{id} で利用できます - コンバージョンレコードには GA4 転送ステータスと、テストモード中のデバッグエンドポイントからのエラーレスポンスが表示されます。
検証：DebugView#
GA4 の DebugView はセットアップ中の最速のフィードバックループです。サーバーサイドイベントに対して有効にするには、イベントの params オブジェクトに "debug_mode": 1 を追加します。このフラグが付いたイベントはおよそ10秒以内に DebugView に表示されます。プロダクションレポートデータにはカウントされません。
DebugView（GA4 Admin → DebugView）では、各イベントにその名前、運んだパラメーター、拒否されたパラメーターが表示されます。ビューはイベントを client_id でグループ化するため、クリックからコンバージョンまでの完全なセッションをトレースできます。
debug_mode を削除する前に確認すること：
- イベント名が DebugView イベントストリームに期待通りに表示される（
purchase、Purchaseやecommerce_purchaseではない）。 transaction_idパラメーターが表示され、注文 ID の形式と一致している。client_idが UUID 形式の文字列である - 空でなく、フォールバックの"unknown"文字列でもない。currencyが正しい ISO 4217 コードである（EUR、eurでもEuroでもない）。
標準の GA4 レポートにサーバーサイドコンバージョンデータが反映されるまでには24〜48時間かかります。初日にレポートの精度を評価しないでください。DebugView がイベントの形を確認し、レポートがアトリビューションと合計を確認します。
一般的なエラー#
client_id の欠落。 client_id のないイベントは Measurement Protocol によってサイレントに破棄されます。これは最も一般的な単一の障害モードです。ドロップは不可視です - リクエストは 204 を返し、DebugView には何も表示されず、コンバージョンは一切表示されません。リクエストが発火する前に client_id フィールドが常に入力されていることを確認してください。Elido のセットアップでは、client_id の欠落は elido_click パラメーターがコンバージョン時に注文に書き込まれていないことを意味します - ランディングページのタグまたはウェブフックハンドラーを確認してください。
間違ったイベント名の形式。 Purchase は既存の gtag からの purchase イベントと並んで Purchase という名前のカスタムイベントを作成します。GA4 レポートの総購入数が2つのイベント名に分割されます。修正は Measurement Protocol エンドポイントに送信するすべてのイベント名に小文字のスネークケースを強制することです。GA4 イベントリファレンス（上記リンク）には ecommerce イベントの正規名が記載されています。
25 event_params の超過。 Measurement Protocol はイベントごとに25パラメーターを超えるペイロードをサイレントに拒否します。完全な注文メタデータ（すべての行項目、すべてのカスタム属性）を転送するチームは、気づかずにこの制限に達することがよくあります。開発中にデバッグエンドポイントを使ってオーバーフローを検出してください。プロダクションでは、不要なパラメーターを削除し、イベントペイロードをスリムに保ってください。
ページ設定ではなく注文から通貨を取得。 gtag セットアップのデフォルトが USD だが注文が EUR の場合、サーバーサイドイベントとクライアントサイドイベントは異なる通貨値を持ちます。GA4 は同じイベント名で記録しますが、値を集計できません。ページレベルの gtag 設定からではなく、バックエンドの注文レコードから通貨を取得してください。
クライアントサイド gtag との重複排除#
gtag.js をクライアントサイドで実行しながら Measurement Protocol をサーバーサイドで同時に実行する場合、重複排除が必要です。GA4 は client_id とタイムスタンプウィンドウを組み合わせてイベントを重複排除します。メカニズムは Meta CAPI の event_id フィールドほど明示的ではありませんが、実際のアプローチは同じです：両方のパスで purchase イベントに一貫した transaction_id を持たせます。
purchase イベントの場合、transaction_id を注文 ID に設定します。ブラウザサイドの gtag は確認ページが読み込まれるときに transaction_id: "ord_98231" 付きで purchase を発火します。サーバーサイドの Measurement Protocol イベントも同じ transaction_id: "ord_98231" を持ちます。GA4 は同じセッションウィンドウ内で重複排除します。同じ client_id + transaction_id の組み合わせが重複排除ウィンドウ内に2回届いた場合、2回目は無視されます。
上流のイベント - generate_lead、sign_up、add_to_cart - には使用できる注文 ID がありません。クリック ID がここで機能します：event_id を elido_click UUID に設定します。ブラウザサイドのピクセルとサーバーサイドの転送の両方が同じ値を参照します。これはエンドツーエンド UTM トラッキングチュートリアルで説明されているのと同じ規律で、ファネル全体でこの ID を利用可能にする広範なキャンペーンタギング設定を扱っています。
GA4 の重複排除ウィンドウは、Meta が CAPI のために公開している精度では公開されていません。実際には、同じセッションウィンドウ内に到着した一致する client_id + transaction_id を持つイベントは重複排除されます。両方のパスを同時に実行する方が安全な設定です - アドブロッカーが多いオーディエンスのフォールバックカバレッジを提供しながら、サーバーパスからアルゴリズムにクリーンなシグナルを与えます。
アトリビューションパイプラインにおける位置づけ#
Measurement Protocol は、CAPI が Meta シグナルギャップを閉じるのと同じ方法で GA4 シグナルギャップを閉じます。メカニズムは異なります - GA4 は Meta が event_id とマッチキーを使用するところで client_id と transaction_id を使用します - しかしアーキテクチャは同一です：ブラウザの状態に依存しないサーバーサイドイベントです。
どのプラットフォームに転送するか、およびファンアウトが大規模でどのように機能するかの全体像については、サーバーサイドコンバージョントラッキング概要で GA4、Meta CAPI、TikTok Events を並べて説明しています。UTM タギングが上流ステップのキャンペーンでは、エンドツーエンドでの UTM キャンペーントラッキングが前提となる読み物です。
このセットアップのプロダクトサーフェス：コンバージョントラッキング機能では、マルチプラットフォームファンアウト、返金イベント、リトライセマンティクスを含む完全な /v1/conversions API を文書化しています。マーケター向けソリューションでは、コンバージョンパイプラインが UTM テンプレートやスマートリンクルーティングと並ぶキャンペーンワークフローにどのようにフィットするかを示しています。
セットアップ自体 - ワークスペース設定へのクレデンシャル、ランディングページの elido_click のためのタグマネージャーステップ、注文ウェブフックの配線 - はほとんどのチームで半日かかります。DebugView の検証ステップにさらに30分追加します。出力は、キャンペーンが実際に推進しているものを反映した GA4 コンバージョンデータです。ブラウザサイドパスを生き残る65〜75%ではなく。
情報源
- Google Analytics 4: Measurement Protocol overview. developers.google.com/analytics/devguides/collection/protocol/ga4 (accessed 2026-05-12)
- GA4 Measurement Protocol: Event reference. developers.google.com/analytics/devguides/collection/protocol/ga4/reference/events (accessed 2026-05-12)
- GA4 Measurement Protocol: Sending events. developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events (accessed 2026-05-12)
Elidoを試す
URLを貼り付けて短縮リンクを取得
登録不要。リンクは30日間有効。永久に保存するには登録してください。
Free、登録不要 · 1日あたり2件