GA4のMeasurement Protocolとは？サーバーから送る方法と48・72時間のルール

GA4に、ブラウザのタグでは取れないイベントを入れたいときに使うのが、Measurement Protocolです。当社はこれを使って、GA4に入らなかったShopifyの購入をあとから送るアプリを作りました。その中で分かった、ECで使うときに詰まりやすいところを中心にまとめます。

前半は、Measurement Protocolとは何か、使うべきかの判断、ECでの使いどころです。後半の「purchaseと返金を送るリクエストの例」からは、実装する人向けの内容です。仕様は2026年10月時点のGoogleのドキュメントに沿っています。

Measurement Protocolとは

Measurement Protocolは、サーバーからGA4に直接イベントを送るための、Googleの仕組みです。ふつうGA4のイベントは、サイトに置いたGoogleタグが購入者のブラウザで動いたときに送られます。Measurement Protocolは、ブラウザを通さずに、自社のサーバーから送ります。

Googleは、これを「タグの代わり」ではなく「タグを補うもの」と位置づけています。ドキュメントでは、うまく使うにはGoogleタグかタグマネージャーなどの設置が前提で、サーバーからだけ送るとレポートの一部しか使えないことがある、と説明しています。

	ブラウザのタグ（Googleタグ）	Measurement Protocol
送る場所	購入者のブラウザ	自社のサーバー
送るきっかけ	ページの表示やクリック	注文、返金、店舗での購入など、サーバーで起きたこと
訪問の情報（参照元・ページ・端末）	自動で付く	自分で付ける。元の訪問のIDを付ければ引き継げる
広告ブロッカーの影響	受ける	送信は受けない。ただし元の訪問のIDはブラウザで取るので、ブロックされた訪問には参照元が付かないことがある
エラーの返り方	—	中身が壊れていてもエラーを返さない

ユニバーサル アナリティクス（UA）にも同じ名前の仕組みがありましたが、送り先も書き方も別物です。GA4では /mp/collect という送り先に、APIシークレットを付けて送ります。

2026年10月時点のGoogleのドキュメントでは、Measurement Protocolは完成した状態にあり、廃止の予定はないとしたうえで、新しくサーバー間の連携を作るならData Manager APIを勧めています。違いは後の節で説明します。

サーバーサイドGTMとの違い

サーバーサイドGTMは、ブラウザで起きたイベントを自社のサーバーでいったん受けて、GA4などに送り直す仕組みです。最初のイベントはブラウザで起きる必要があるので、タグが動かなかった購入は拾えません。Measurement Protocolは、サーバーで起きたこと（注文の作成など）を直接送るので、ブラウザでイベントが起きなかった購入も送れます。

Measurement Protocolを使うべきかの判断

使うかを決める順番を、先に図で示します。

使うべきかは、GA4に入っていない購入がどれくらいあるかで決まります。判断の順番は次のとおりです。

1. 土台を確かめる：GA4の購入（purchase）が、購入の完了時に1回だけ送られているか。タグの二重設置や、完了ページで動いていないといった設定の問題は、Measurement Protocolではなくタグを直します
2. 漏れを確かめる：Shopifyの注文番号と、GA4のトランザクションID（注文番号にあたるID）を1件ずつ突き合わせます。手順はShopifyでGA4の購入が計測漏れする原因と埋め方にまとめています
3. 手段を選ぶ：漏れが見過ごせない量なら、自前で作る（エンジニアに頼む）、アプリを使う、のどちらかです

『ネット広告運用“打ち手”大全 第2版』は、計測を「基礎計測」「シグナル補完」「サーバーサイド」の3段階に分け、下から順に固めることを勧めています。1が基礎計測にあたり、Measurement Protocolはその上に足すものです。

自前で作る場合、エンジニアに伝える要件は次のとおりです。

• 注文の時点で、購入者のクライアントIDとセッションIDを控えて注文と結びつける
• 注文が入ったら、サーバーからMeasurement Protocolで送る
• 送る前に、GA4に同じ注文が無いかを確かめる（二重計上の防止）
• 分析への同意を拒否した人の注文は送らない
• 送れたかを確かめる仕組みを作る（エラーが返らないため）

ECでの使いどころ

ECでMeasurement Protocolを使うのは、注文はサーバーにあるのに、GA4にはブラウザから届かないイベントがあるときです。

場面	送るイベント	元の訪問とつなぐか	気をつけること
タグが動かなかった購入（外部決済から戻らない、広告ブロッカーなど）	purchase	つなぐ（IDが取れた場合）	すでにGA4にある注文を送ると二重になる
返金	refund	元の購入と同じトランザクションID	返金日に計上される
店舗（POS）や電話での購入	purchase	会員ID（user_id）でつなげる場合だけ	訪問の無い購入なので、購入率が上がって見える
定期購入の2回目以降	purchase	基本はつながない	広告の成果として数えるかを先に決める
AIアシスタントやSNSアプリの中で完結した購入	purchase	つながない（訪問が無い）	参照元を自分で付ける

訪問の無い購入に参照元を付ける考え方は、UTMパラメータの記事が参考になります。

ULTRO NOTES｜計測・分析UTMパラメータの付け方｜生成ツールとGA4での確認方法、命名ルール表UTMパラメータは utm_source・utm_medium・utm_campaign の3つを小文字で付けます。パラメータ付きURLの生成ツール、ECで使える命名ルール表、GA4で値を確認する方法、自動タグ設定との優先順位までまとめます。

送る前に用意するもの

送るのに必須なのは、測定ID、APIシークレット、クライアントIDの3つです。元の訪問のセッションにつなぐなら、セッションIDも要ります。

用意するもの	どこで手に入るか	例
測定ID（measurement_id）	GA4のウェブ ストリームの詳細	G-XXXXXXXXXX（ストリームIDとは別）
APIシークレット（api_secret）	ウェブ ストリームの詳細で作成	ストリームごとに作る
クライアントID（client_id）	購入者のブラウザのGoogleタグ。GA4がブラウザごとに振る識別番号	1234567890.1712345678
セッションID（session_id）	同上。1回の訪問の番号	1712345678

APIシークレットの作り方

1. GA4の左下の「管理」を開き、「データの収集と修正」の「データ ストリーム」を押します。
2. ウェブ ストリームを選び、「ウェブ ストリームの詳細」の「イベント」にある「Measurement Protocol API secret」を押します。

3. 開いた「Measurement Protocol API シークレット」で「作成」を押し、ニックネームを入れて「作成」を押します。
4. 一覧の「シークレットの値」をコピーして、サーバーの設定に保存します。

APIシークレットは、サイトのHTMLやアプリの中に書いてはいけません。Googleのドキュメントも、クライアント側のコードに出さないこと、スパムを防ぐために定期的に作り直すことを求めています。シークレットは大文字と小文字が区別され、あとから取り消すこともできます。

purchaseと返金を送るリクエストの例

ここからは実装する人向けの内容です。送り先は https://www.google-analytics.com/mp/collect で、URLに測定IDとAPIシークレットを付けて、JSONをPOST（HTTPでデータを送る方式）します。データをEUで収集したい場合は https://region1.google-analytics.com/mp/collect を使います。

次は、Shopifyの注文1件をpurchaseとして送る例です。client_id と session_id は、注文の時点で控えた元の訪問の値に置き換えます。

curl -X POST "https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXXXX&api_secret=YOUR_API_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "1234567890.1712345678",
    "events": [{
      "name": "purchase",
      "params": {
        "transaction_id": "1001",
        "currency": "JPY",
        "value": 11636,
        "tax": 1164,
        "shipping": 0,
        "session_id": 1712345678,
        "engagement_time_msec": 100,
        "items": [{
          "item_id": "SKU-001",
          "item_name": "アートポスター A2",
          "price": 11636,
          "quantity": 1
        }]
      }
    }]
  }'

• value：Googleのイベントのリファレンスでは、items の価格×数量の合計で、税と送料は含めません。ただし既存のタグが税込で送っているなら、収益の定義がずれないよう、そちらに合わせます
• 日時：この例では timestamp_micros を省いているので、届いた時刻で記録されます。注文の時刻で記録したいときは、マイクロ秒（ミリ秒ではない）の値を付けます。72時間より前の日時は付けられず、セッションにつなぐなら、そのセッションの間の日時にします
• 同意：広告への利用の同意は、リクエストのいちばん外側に "consent": {"ad_user_data": "GRANTED", "ad_personalization": "DENIED"} のように付けます。値は、注文のときに控えた実際の状態を入れます。省くと、元の訪問の同意の状態が使われます。分析への同意を表す項目は無いので、分析を拒否した人の注文は、送らないことで扱います

返金は、元の購入と同じトランザクションIDで refund を送ります。全額の返金は transaction_id と value で足ります。一部の返金は、items に返金した商品の item_id と quantity を入れます。

{
  "client_id": "1234567890.1712345678",
  "events": [{
    "name": "refund",
    "params": {
      "transaction_id": "1001",
      "currency": "JPY",
      "value": 11636,
      "items": [{ "item_id": "SKU-001", "price": 11636, "quantity": 1 }]
    }
  }]
}

返金は購入から72時間より後に起きることが多く、その場合は過去の日時を付けられないので、返金した日に計上されます。部分返金を何回かに分けて行ったときは、返金1回につき1回だけ送り、同じ返金を送り直さないようにします。

主な項目

項目	意味	注意
client_id	購入者のブラウザを表すID	必須。サイトのGoogleタグが作ったIDとそろえる
user_id	会員ID	任意
timestamp_micros	イベントが起きた日時（マイクロ秒）	72時間前まで
consent	広告への利用の同意（ad_user_data、ad_personalization）	リクエストのいちばん外側に置く
user_location、ip_override、device、user_agent	地域と端末の情報	訪問の無いイベントに付ける。2025年に追加された
events[].name	イベント名	session_start など、予約された名前は使えない
params.session_id	元の訪問のセッションID	数値。セッションにつなぐなら必要
params.engagement_time_msec	前のイベントからのエンゲージメント時間（ミリ秒）	付けないと、リアルタイムの人数やエンゲージメントの指標に反映されないことがある

non_personalized_ads という項目は非推奨になり、consent の ad_personalization を使うよう案内されています。同意バナーと同意モードの考え方は、Cookie同意バナーの記事にまとめています。

ULTRO NOTES｜計測・分析Cookie同意バナーは必要？ECの判断基準とGA4の同意モードCookie同意バナーが必要かどうかは、どの国のお客様に販売しているかで変わります。日本向けの自社ECに関係する法律、同意バナーを出したときにGA4の数字がどう変わるか、同意モードの基本と高度の違い、Shopifyでの設定をまとめます。

上限と、使えない名前

上限	値
1回のリクエストのイベント数	25まで
1つのイベントのパラメータ数	25まで
items の中の独自のパラメータ	10まで
イベント名・パラメータ名	40文字以内。英数字とアンダースコアだけで、英字から始める
パラメータの値	100文字以内（アナリティクス 360のプロパティは500文字）
ユーザー プロパティ	1回のリクエストで25まで。名前は24文字、値は36文字以内
リクエストの大きさ	130KB未満
送れる量	1プロパティで1時間あたり1億件まで（コンバージョン以外。超えた分はその1時間、黙って捨てられる）

パラメータ名は _、firebase_、ga_、google_、gtag. で始められません。session_start、first_visit、user_engagement などのイベント名は予約されていて送れません。新しいセッションを作るのに session_start は要らず、新しいsession_idを付ければ別のセッションになります。

Measurement Protocolで送る期限（48時間・72時間・63日）

Measurement Protocolで送るイベントは、過去の日時は72時間前まで、Google広告への書き出しは最後のオンラインの行動から63日以内です。何をしたいかによって期限が違うので、Googleのドキュメントの使い方別の一覧に沿って整理します。

表にすると、次のとおりです。

したいこと	期限	必要なもの
会員IDを付ける	オンラインのセッションと同じ日のうち（プロパティのタイムゾーン）	session_id
Google広告などに書き出す	最後のオンラインの行動から63日以内、かつキーイベントのアトリビューション期間内	GA4とGoogle広告のリンク
オーディエンスに使う	最後のオンラインの行動から30日以内（アプリは42日）	—

どの使い方にも共通する決まりが2つあります。

• 72時間：過去の日時を付けられるのは72時間前までです。それより前の日時は、既定の設定（validation_behavior を付けないか RELAXED）では受け付けられたうえで72時間前に置き換えられ、ENFORCE_RECOMMENDATIONS では拒否されます
• 48時間：ブラウザのタグのイベントと合わせて処理されるイベント（成果の紐づけなど）は、元のイベントから48時間以内に届けることが勧められています。それより遅いと、想定どおりに処理されないことがあります

セッションが切れる条件はGA4のセッションとユーザー数の記事に、成果をどのチャネルに付けるかのルールはアトリビューションの記事にまとめています。

ULTRO NOTES｜計測・分析GA4のセッションとユーザー数｜合計が合わない理由と切れる条件GA4のセッションは操作のない時間が30分を超えると切れます。日別の和や表の行の和が合計と合わないのは、重複を除いて数えることとHyperLogLog++による推定、しきい値のためです。4つのユーザー数の違いと、月曜始まりの週の見方まで。ULTRO NOTES｜計測・分析アトリビューションとは？GA4・広告・Shopifyで数字が合わない理由アトリビューションは、購入までに触れた広告やチャネルのうち、どれの成果とするかを決めるルールです。GA4・Google 広告・Meta広告・Shopifyで既定のルールがどう違うか、同じ購入が別々に数えられる仕組み、ECでどの数字を何に使うかをまとめます。

クライアントIDとセッションIDの取り方

元の訪問とつなぐには、購入者のブラウザでGoogleタグが作ったクライアントIDとセッションIDを、注文の時点で控えておきます。自分で作ったランダムなIDを送ると、GA4では別の人の、訪問の無い購入になります。

• gtag.jsで取る：gtag('get', 'G-XXXXXXXXXX', 'client_id', callback) と、同じ形で session_id を取れます
• タグマネージャーで取る：2025年12月から、クライアントIDとセッションIDの組み込み変数（英語名は Analytics Client ID、Analytics Session ID）の値をそのまま送れるようになりました
• Cookieの値：2026年2月から、クライアントIDのCookie（_ga）とセッションIDのCookie（_ga_ に測定IDが続くもの）の値をそのまま送っても受け付けられるようになりました。ただしGoogleは、Cookieの形ではない値を送ることを勧めています

Shopifyでは、チェックアウトに直接スクリプトは入れられません。管理画面の「顧客イベント」に入れるカスタムピクセルかアプリピクセルは、チェックアウトや購入完了のページでも動くので、そこでIDを読み、自社のサーバーに渡して注文と結びつけるのが一般的です。

送れたかの確かめ方（検証用サーバー・DebugView）

Measurement Protocolは、リクエストの中身が壊れていても、データが処理されなくても、エラーを返しません。送信を受け付けたという応答（2xx）が返っても、正しく記録されたとは限らないので、別の方法で確かめます。

手順は、次のとおりです。

1. 検証用サーバーに送る：送り先を /debug/mp/collect に変えて同じリクエストを送ると、validationMessages で形式の問題が返ります。開発中は "validation_behavior": "ENFORCE_RECOMMENDATIONS" を付けると、より厳しく確かめられます。検証用サーバーに送ったイベントはレポートに入りません
2. リアルタイムで見る：本番に送ったイベントは、ふつう数秒でGA4の「リアルタイム」に出ます
3. DebugViewで見る：イベントのパラメータに "debug_mode": true を付け、engagement_time_msec を正の値にして本番に送ると、DebugViewに出ます

検証用サーバーが確かめるのは形式だけです。APIシークレットや測定IDが正しいか、purchaseに transaction_id や items、currency が入っているかは、何も返らなくても確かめていません。本番に少量送って、リアルタイムかDebugViewで中身まで見ます。

DebugViewに出ないとき

• イベントのパラメータに debug_mode を付けていない（リクエストのいちばん外側に置くと受け付けられない）
• engagement_time_msec が0か、付いていない
• 検証用サーバーに送っている（検証用サーバーのイベントはDebugViewにも出ない）
• APIシークレットが別のストリームのもの（エラーは返らない）

送ったイベントに gapfill=1 のような独自のパラメータを付けておくと、あとでGA4の探索で、タグから来た購入と分けて見られます。探索の使い方は探索レポートの記事にまとめています。

ULTRO NOTES｜計測・分析GA4の探索レポートの使い方｜ECでよく使う4つの型と経路データ探索GA4の探索レポート（データ探索）の使い方を、ECでよく使う4つの型に絞ってまとめます。標準レポートとの違い、7つの手法、ファネルデータ探索・経路データ探索・セグメントの重複・コホートデータ探索の設定、データ保持期間やサンプリングなど数字が合わないときの確認点まで。

二重計上と、Google広告への影響

Measurement Protocolで送った購入とブラウザのタグの購入が、同じトランザクションIDでも1件にまとまるとは限りません。GA4のヘルプは、ウェブ ストリームで同じユーザーから同じトランザクションIDの購入が届いたときに重複を除くと説明していますが、Measurement Protocolにも同じ処理が効くかは書いていません。アプリのストリームでは重複は除かれず、トランザクションIDを空のまま送ると、空のもの同士が重複として扱われます。

二重になると、GA4の売上と広告の成果が実際より多く出ます。送る前に、GA4のData API（レポートの数字を取り出すAPI）でそのトランザクションIDの購入がすでにあるかを照会し、無いものだけを送ります。キーイベントの数え方は、GA4のキーイベントの記事で説明しています。

ULTRO NOTES｜計測・分析GA4のキーイベントとは｜ECで設定するイベントと、数え方・Google広告との違いGA4のキーイベントは、購入など成果として数えると決めたイベントで、以前の「コンバージョン」です。Google広告のコンバージョンとの違い、ECでキーイベントにするイベント、設定のしかた、カウント方法の違い、Google広告への取り込み、数字が合わない理由、レポートでの見方まで。

Measurement Protocolで送ったキーイベントは、GA4とGoogle広告をリンクしていれば、Google広告にも書き出されます。ShopifyにGoogle & YouTubeアプリを入れている場合、Google広告に、アプリが作った購入のコンバージョン アクションと、GA4から取り込んだ購入の2つがあることがあります。両方を「メイン」にしていると、後から補った分が二重に数えられ、自動入札がその数字で学習します。Google広告のコンバージョン アクションの一覧で、購入が2つ「メイン」になっていないかを確かめ、片方を「サブ」にしておきます。Google広告側で計測を補う方法には拡張コンバージョンもあり、違いは拡張コンバージョンの記事にまとめています。

ULTRO NOTES｜計測・分析拡張コンバージョンとは？Google広告での仕組みとShopifyでの設定、2026年の変更点拡張コンバージョンは、購入者のメールアドレスなどをハッシュ化してGoogleに送り、Cookieで広告とつながらなかったコンバージョンを補う機能です。gclidとの関係、Googleタグ・GTM・ShopifyのGoogle & YouTubeアプリでの設定、2026年に始まった設定の統合、補えないものをまとめます。

Meta広告で、同じようにサーバーから成果を送る仕組みはコンバージョンAPIです。こちらはブラウザのピクセルと二重に送ることが前提で、イベントIDで重複を除く仕組みがあります。考え方の違いはコンバージョンAPIの記事にまとめています。

ULTRO NOTES｜計測・分析コンバージョンAPIとは？ピクセルとの違いとShopifyでの設定コンバージョンAPI（CAPI）は、購入などのデータをサーバーからMetaに送る仕組みです。Metaピクセルとの違い、併用したときの重複除外の条件、設定方法の比較、Shopifyの公式アプリでの設定と、二重計測の確認点をまとめます。

Data Manager APIとの違い

ECのストアが自前でGA4に購入を足すだけなら、Measurement Protocolで足ります。Google広告への送信も同じ仕組みでまとめたい場合に、Data Manager APIを検討します。

Data Manager APIは、Google広告やGA4などにデータを送るための、Googleの新しいAPIです。2026年5月に、GA4のウェブとアプリのデータ ストリームに、予約された名前以外のイベントを送れるようになりました。

	Measurement Protocol	Data Manager API
始めるのに要るもの	APIシークレットだけ	Google Cloudのプロジェクト、OAuthの設定（ユーザーまたはサービス アカウント）。一部の機能は許可リストへの登録
送り先	1回に1つのストリーム	1回で複数の送り先（GA4・Google広告など）
データの形	GA4専用	Googleの広告製品と共通
送るデータ自体の暗号化（通信はどちらもHTTPS）	対応していない	対応
エラー	検証用サーバーに送ったときだけ分かる	1件でもエラーがあると、そのリクエストは全部失敗する
重複の除去	書かれていない	許可リストに入ると、トランザクションIDでタグの分と重複を除ける（最初に届いた分が使われる）
今後	廃止の予定はない	Googleが新規の連携に勧めている

Data Manager APIの重複の除去は、誰でもすぐ使えるものではありません。許可リストへの登録が必要で、ウェブ ストリームに送ったデータは、最初の14日間はGoogle広告の入札に使われないと説明されています。また、GA4とGoogle広告の両方を送り先にしたうえで、GA4のキーイベントもGoogle広告に書き出していると、広告側で二重に数える経路ができます。

よくある失敗

• ランダムなクライアントIDを送る：GA4では、訪問の無い新しいユーザーの購入になり、参照元が付きません
• 別のストリームのAPIシークレットを使う：シークレットはストリームごとです。エラーは返らないので、気づきにくいところです
• timestamp_microsをミリ秒で送る：桁が3つ足りず、意図しない日時になります
• session_idやengagement_time_msecを付けない：リアルタイムの人数や、エンゲージメントの指標に反映されないことがあります
• すでにGA4にある購入をもう一度送る：同じトランザクションIDでも、重複が除かれるとは限りません
• 同意の値を固定で送る：例のコードの GRANTED をそのまま全注文に付けると、同意していない人のデータも広告に使える形で送られます
• イベント名の変更やカスタム イベントの作成に頼る：GA4の管理画面の「イベントの変更」「カスタム イベントを作成」は、Measurement Protocolで送ったイベントには効きません。名前は自社のコードで決めて送ります

ShopifyでMeasurement Protocolを使うには

Shopifyで自前で作る場合は、カスタムピクセルでクライアントIDとセッションIDを控え、注文の通知（Webhook。注文が入るとShopifyがサーバーに自動で知らせる仕組み）を受けたサーバーから送る構成になります。作るときは、次の点も決めておきます。

• どの時点で送るか：コンビニ決済、銀行振込、後払いなどは、注文が作られた時点では支払いが済んでいません。注文の作成で送るか、支払いの完了で送るかは、GA4の売上の定義に直結します
• 同じ通知の重複：Webhookは同じ通知が2回届くことがあり、届く順番も保証されません。通知のIDで重複を除きます
• 取りこぼしの拾い直し：Webhookが届かなかった注文を、定期的に注文の一覧と照合して拾います
• 顧客データの扱い：注文のWebhookを受けるアプリには、Shopifyの保護された顧客データの承認が必要です

Shopifyのドキュメントでは、購入完了のイベント（checkout_completed）は、ふつう購入完了のページで、アップセルがある場合は最初のアップセルのページで発生し、そのページが読み込まれないと発生しません。タグが動かなかった購入が出るのは、この仕組みのためです。

当社は、この一連の処理をShopifyアプリ「GapFill」にしました。自社の製品なので、その前提で読んでください。GA4で漏れた購入データだけを、元の訪問のIDを付けてMeasurement Protocolで補完します。既存のタグ設定はそのままで、計測漏れレポートは無料です。仕組みと、ほかの方法との比較はShopifyでGA4の購入が計測漏れする原因と埋め方で説明しています。GA4で最初に確かめておく設定は、GA4の使い方の記事にまとめています。

ULTROのShopifyアプリGapFill｜GA4で漏れた購入データを、サーバーサイドで補完既存のタグ設定はそのまま。計測漏れレポートは無料です。GapFillを見る →ULTRO NOTES｜計測・分析ShopifyでGA4の購入が計測漏れする原因と埋め方ShopifyとGA4の購入数・売上が合わない、購入が計測されないときの原因と確かめ方を説明します。注文番号での突き合わせ手順、タグの見直し・サーバーサイドGTM・Measurement Protocolの比較、当社が作ったアプリ「GapFill」での埋め方まで。ULTRO NOTES｜計測・分析GA4の使い方｜ECで最初に見るレポートと、設定を直す順番GA4の使い方を、ECサイトで先に押さえる主要な指標8つ、最初に見るレポート4つと、最初に直しておく設定に絞ってまとめます。売上の概要、トラフィック獲得、e コマース購入数、ランディング ページの見方、ユーザー獲得との違い、データの保持・内部トラフィック・キーイベント・サービス間のリンクの設定、Shopifyとのつなぎ方まで。

参考にした情報

• Measurement Protocol（Google for Developers）
• Send Measurement Protocol events to Google Analytics（Google for Developers）
• Measurement Protocol reference（Google for Developers）
• Measurement Protocol events reference（Google for Developers）
• Validate events（Google for Developers）
• Verify implementation（Google for Developers）
• Measurement protocol use cases（Google for Developers）
• Troubleshooting（Google for Developers）
• Measurement Protocol changelog（Google for Developers）
• Upgrade from Measurement Protocol to Data Manager API（Google for Developers）
• Send events to Google Analytics with Data Manager API（Google for Developers）
• Data Manager API: Introducing support for Google Ads store sales and more event ingestion use cases for Google Analytics（Google Ads Developer Blog, 2026年5月）
• [GA4] Minimize duplicate key events with transaction IDs（Google アナリティクス ヘルプ）
• checkout_completed（Shopify.dev）
• Webhooks（Shopify.dev）
• ネット広告運用“打ち手”大全 第2版 AI時代に成果を上げる 最強の戦略103（寳洋平・釜周平・ザンノーニ ダリオ）