サーバーサイドGTMとは？仕組み・費用と、Shopifyで拾えない購入

サーバーサイドGTMは、計測の精度を上げる方法として名前が挙がることの多い仕組みです。ただ、当社がShopifyのストアの計測を手伝う中で受ける相談には、「サーバーサイドにすれば、GA4に入っていない購入も入るのでは」という期待が多く含まれています。サーバーサイドGTMで良くなるのはCookieの持ちや送るデータの整え方で、ブラウザを通らない購入は、一般的な構成では増えません。

この記事では、サーバーサイドGTMの仕組み、費用の目安、できることとできないこと、Shopifyで使うときの注意点、Googleタグゲートウェイなど中間的な手段との違い、導入するかどうかの判断の目安を説明します。広告や計測を担当しているEC事業者の方と、導入を検討している制作・開発の方に向けた内容です。仕様と料金は2026年10月時点のものです。

サーバーサイドGTMとは

サーバーサイドGTMは、Googleタグマネージャー（GTM）のサーバー用のコンテナを自社のサーバーで動かし、ブラウザから届いた計測データをGA4やGoogle広告、Meta広告などに送り直す仕組みです。Googleのドキュメントでは「サーバーサイド タグ設定」（server-side tagging）と呼ばれ、サーバーサイドタグ、サーバーサイドタギング、sGTMとも呼ばれます。

ウェブコンテナ（クライアントサイドのGTM）は、購入者のブラウザの中でタグを動かし、ブラウザから各社のサーバーに直接データを送ります。サーバーサイドGTMでは、ブラウザはまず自社のサーバーにデータを送り、そこから先の送り分けをサーバーが行います。

	ウェブコンテナ（クライアントサイド）	サーバーサイドGTM（サーバーコンテナ）
タグが動く場所	購入者のブラウザ	自社が用意したサーバー
データの送り先	ブラウザから各社へ直接	ブラウザ→自社のサーバー→各社
Cookie	主にJavaScriptで書く	サーバーの応答で発行できる（自社ドメインで動かした場合）
データの加工	ブラウザの中でできる範囲	サーバーで項目を足す・消すなどができる
費用	無料	サーバー代と運用の手間がかかる
必要なもの	GTMのアカウント	GTMのサーバーコンテナ、サーバー（Cloud Runなど）、できれば自社のサブドメイン

サーバーサイドGTMのメリット・デメリット

サーバーサイドGTMのメリットは、データを自社のサーバーで管理できることとCookieの持ちが良くなることで、デメリットは費用と運用の手間、そして拾えない購入が残ることです。

メリット	デメリット
データを自社の管理するサーバーで扱える（Googleが安全性の利点として挙げている）	サーバー代がかかる（Cloud Runの本番構成で月90ドル前後から）
送る前に、個人情報を消す・項目を足すなどの加工ができる	ブラウザのタグ、サーバーコンテナ、サーバーの3か所を管理・保守する人が要る
自社ドメインで動かせば、サーバーの応答でCookieを発行できる	Cookieの効果は、サイトと同じCDN・ドメインの構成で組めるかしだい
ブラウザで読み込む他社のタグを減らせる	ブラウザを通らない購入は、一般的な構成では拾えない

Googleは、サイトで動くタグが減ることによる表示の軽さも利点に挙げています。ただ、データの入口になるGoogleタグはブラウザに残るので、表示速度が大きく変わるのは、Meta広告などほかの会社のタグをいくつもサーバー側に移せた場合だと当社は見ています。サーバーコンテナが止まっても、サイトの表示には影響しないとGoogleは説明しています。

サーバーサイドGTMの仕組み

サーバーサイドGTMは、ブラウザのタグが送ったデータを、サーバーコンテナの「クライアント」が受け取ってイベントに変換し、「タグ」が各社の形式にして送る、という流れで動きます。最初のデータはブラウザで生まれます。流れを先に図で示します。

1. 購入者のブラウザで、GA4のタグ（Googleタグ）が動きます。送り先は、Googleではなく自社のサーバーコンテナのURLにしておきます
2. サーバーコンテナの「クライアント」がリクエストを受け取ります。クライアントは、届いたデータをイベントの形に変換する部品で、GA4用のクライアントが最初から入っています
3. トリガーの条件に合うと、サーバーコンテナの「タグ」が動きます。GA4のタグ、Google広告のコンバージョンのタグ、Meta広告のコンバージョンAPIのタグなどを置けます
4. 各タグが、イベントを各社の形式に変換して送ります

1つの購入のイベントをブラウザから1回送るだけで、サーバー側でGA4、Google広告、Meta広告の3つに振り分けられます。ブラウザに置くタグが減るのは、この仕組みのためです。

『ネット広告運用“打ち手”大全 第2版』も、サーバーサイドGTMでも最初のシグナルはブラウザで取る、という前提で説明しています。同書は、サーバーサイドGTMを入れる目的を「タグを増やすこと」ではなく、CRMとの連携、媒体をまたいだイベントの定義の統一、厳格な同意の管理、多国展開などの「計測のガバナンス（統制）」に置いています。

1st party CookieとSafariのITP

サーバーサイドGTMを自社のサブドメインで動かすと、サーバーの応答で、自社ドメインのCookie（1st party Cookie）を発行できます。自社で集めるデータ全体の考え方はファーストパーティデータの記事にまとめています。Googleは、サーバーをサイトのサブドメイン（metrics.example.com など）か同じオリジン（www.example.com/metrics など）で動かすことを強く勧めていて、Cloud Runが最初に用意するドメイン（run.app）のままでは、サーバーから発行するCookieの利点は得られないとしています。

ULTRO NOTES｜計測・分析ファーストパーティデータとは｜ECで集める場所と使い道ファーストパーティデータは、自社がお客様から直接集めたデータです。ECではShopifyなどのカートにすでに溜まっています。ECで集まる場所、広告と計測での4つの使い道、顧客リストを広告に使うときの同意の考え方をまとめます。

これがITP対策と言われる理由です。SafariのITP（Intelligent Tracking Prevention）は、JavaScriptで書いたCookieの期限を最長7日に縮めます（7日以内に再訪すれば延びます）。さらに、トラッカーと判定されたドメインから、クリックIDなどのパラメータ付きのURLで来た場合は、そのページでJavaScriptで書いたCookieの期限を24時間にします。サーバーの応答で発行したCookieには、この制限がかかりません。

ただし、WebKitの説明では、サーバーの応答で発行したCookieでも、次の表の下の2行の条件に当たると期限が7日に縮められます。

Cookieの発行のされ方	Safariでの期限
JavaScriptで書いたCookie	期限が最長7日に縮められる
トラッカーと判定されたドメインからパラメータ付きのURLで来たページで、JavaScriptで書いたCookie	24時間
サイトと同じインフラ（同じCDN・ドメインの構成）のサーバーが応答で発行したCookie	上限なし
CNAMEで別の会社のサーバーに向けたサブドメインが発行したCookie	7日
サイトと違う会社のIPアドレスのサーバーが発行したCookie	7日

サブドメインのDNSをCNAME（サブドメインを別のサーバーに向ける設定）でCloud Runに向けただけでは、下の2行に当たる可能性があります。Googleが「同じオリジン」の方式（CDN＝ページを各地のサーバーから配る仕組みや、ロードバランサで、www.example.com/metrics のようにサイトのドメインの中のパスをサーバーに転送する）を最も勧めているのは、このためと考えられます。どのIPアドレスを「違う会社」と判定するかの細かい基準は、WebKitの公開ページでは確認できませんでした。

サーバーサイドGTMでできること・できないこと

サーバーサイドGTMでできるのは、ブラウザで起きたイベントの届け方と中身を良くすることです。ブラウザでイベントが起きなかった購入を、新しく作り出すことはできません。

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

場面	サーバーサイドGTMで	理由
ブラウザで読み込むタグ（他社のスクリプト）を減らしたい	できる	1回の送信をサーバーで複数の送り先に振り分けられる
送るデータを整えたい（個人情報を消す、項目を足す）	できる	サーバーで変換してから送れる
Cookieを長く保ちたい（Safari）	条件つきでできる	サイトと同じCDN・ドメインの構成の中でサーバーを動かした場合
広告ブロッカーによる漏れを減らしたい	一部できる	自社ドメインへの送信はブロックされにくい。ただしGTMやGoogleタグの読み込み自体が止められると送れない
外部の決済サービスから戻らない購入を拾いたい	できない	完了ページが開かれず、ブラウザでイベントが起きない
AIアシスタントやSNSアプリの中で完結した購入を拾いたい	できない	ストアのページが開かれない
定期購入の2回目以降を入れたい	できない（そのままでは）	注文が自動で作られ、購入者はストアに来ない
完了ページを開く前に閉じた購入を拾いたい	できない	タグが送る前に閉じられている

下の4行は、タグの設定の問題ではなく、購入者のブラウザでタグが動く機会がそもそも無い購入です。当社が支援しているあるShopifyストアで、Shopifyの注文とGA4の購入を1件ずつ突き合わせたところ、GA4に入っていない注文は全体の21%で、コンビニ決済では約8割が欠けていました。くわしくはアトリビューションの記事に載せています。この種類の漏れは、サーバーサイドGTMに切り替えても縮まりません。

ULTRO NOTES｜計測・分析アトリビューションとは？GA4・広告・Shopifyで数字が合わない理由アトリビューションは、購入までに触れた広告やチャネルのうち、どれの成果とするかを決めるルールです。GA4・Google 広告・Meta広告・Shopifyで既定のルールがどう違うか、同じ購入が別々に数えられる仕組み、ECでどの数字を何に使うかをまとめます。

Shopifyの注文の通知（Webhook。注文が入るとShopifyがサーバーに自動で知らせる仕組み）をサーバーコンテナで受ければ、ブラウザを通らない購入も送れます。StapeのShopify向けアプリには、購入と返金のWebhookをサーバーコンテナに送る設定があります。ただしWebhookにはブラウザのCookieが含まれないので、どの訪問の購入かが分かりません。Stape自身も、Webhookは電話やオフラインの販売など、通常のオンラインの計測ができない場面の補助として勧めています。元の訪問のクライアントIDとの結びつけ、ブラウザのタグの購入との二重の排除、同意の確認は、別に組む必要があります。漏れの原因と確かめ方は、ShopifyでGA4の購入が計測漏れする原因と埋め方にまとめています。

ULTRO NOTES｜計測・分析ShopifyでGA4の購入が計測漏れする原因と埋め方ShopifyとGA4の購入数・売上が合わない、購入が計測されないときの原因と確かめ方を説明します。注文番号での突き合わせ手順、タグの見直し・サーバーサイドGTM・Measurement Protocolの比較、当社が作ったアプリ「GapFill」での埋め方まで。

サーバーサイドGTMの費用（Cloud Run・Stape）

サーバーサイドGTMの費用は、Google Cloud（Cloud Run）で自分で動かすなら、Googleの目安でサーバー1台あたり月30〜50ドルほどで、本番は2〜3台以上が勧められています。

GTMの画面から自動でサーバーを用意する方法（自動プロビジョニング）を選ぶと、Google Cloudのプロジェクトと、Cloud Runのサーバーが1台作られます。この構成はほとんどの場合無料ですが、Googleはテストの少量のトラフィック向けで、実際の訪問を流すなら台数を増やすよう案内しています。Googleのドキュメントは、ページによって勧める台数と金額が少しずつ違います。

Googleのドキュメント	本番で勧める台数	1台あたりの月額の目安
Cloud Run の設定ガイド	最低2台（2〜10台で自動増減）	約45ドル（1 vCPU・メモリ0.5GB、CPUを常に割り当てる料金）
サーバーサイド タグ設定の概要	最低3台	30〜50ドル
学習コース（日本語版、7章・8章）	最低3台（3〜6台で毎秒50〜200件に対応。8章）	約50ドル（7章）

台数を掛けると、2台×45ドルで90ドル、3台×30〜50ドルで90〜150ドルで、サーバー代だけで月90〜150ドル前後が出発点です。このほかに、次の費用がかかることがあります。

• ログ：Cloud Runは既定で、届いたリクエストを1件ずつ記録します。Googleは、月100万件を超えるような場合はログの料金が大きくなりうるとして、記録を止めることを勧めています
• 外向きの通信：サーバーから各社に送るデータと、ブラウザに返す応答の量に応じてかかります。Googleのスクリプトをサーバー経由で配信すると増えます
• プレビュー用のサーバー：GTMのプレビュー機能を使うには、プレビュー用のサーバーを別に1つ用意します
• セールの時期：Googleは、ブラックフライデーのような大きなセールの前に、最低台数を増やしておくことを勧めています。台数が足りないと、そのあいだのデータは失われ、取り戻せません

予算の上限で請求を自動で止める設定にしていると、上限に達した時点で、その請求先アカウントにつながるサービスがすべて止まります。計測も止まるので、上限ではなく予算の通知（アラート）で見ておくほうが安全です。

Stapeなどのホスティングサービス

月50万リクエストに収まる規模のストアなら、StapeのProプラン（年払いで月17ドル）は、Cloud Runの本番構成の目安（月90ドル前後から）より安く、サーバーの保守も任せられます。Stapeは、サーバーサイド タグ設定専用のホスティングサービスで、料金表（2026年10月時点）は次のとおりです。

プラン	月額（年払い）	月のリクエスト数
Free	無料	1万まで
Pro	17ドル（月払いの表示は20ドル）	50万まで
Business	83ドル（同100ドル）	500万まで
Enterprise	167ドル（同200ドル）	2,000万まで

リクエスト数は、注文の件数ではなく、ブラウザからサーバーに届いた送信の数です。1回の訪問で、ページビューや商品の閲覧、カートへの追加などのイベントごとに送信が起きるので、月のセッション数より大きな数字になります。プランを選ぶ前に、今のGA4のイベント数を見ておくと見当がつきます。

見落としやすいのは運用の手間

サーバー代より大きいのは、設計と運用の手間です。サーバーサイドGTMに切り替えると、ブラウザのタグ、サーバーコンテナ、Cloud RunやStapeの設定の3か所を管理することになり、イベントが届かないときの切り分けも3か所で行います。『ネット広告運用“打ち手”大全 第2版』は、サーバーサイドGTMへの投資の対象は「タグの実装」から「アーキテクチャとガバナンス」に移るとして、長期の運用体制まで計画するよう勧めています。制作会社や代理店に頼む場合も、作って終わりにせず、保守の担当者を決めてから発注します。

サーバーサイドGTMの導入手順

サーバーサイドGTMの導入は、サーバーコンテナを作るところから本番の準備まで、次の6つの手順です。ここでは概要だけを示し、設定の詳しい手順はGoogleの学習コース（参考にした情報を参照）に譲ります。

1. サーバーコンテナを作る：GTMの「管理」でアカウントの「コンテナを作成」を選び、「コンテナの設定」の「ターゲット プラットフォーム」で「Server」（ここだけ英語表記）を選んで作成します

2. タグ設定サーバーを用意する：作成のあとに出るダイアログで「タグ設定サーバーを自動的にプロビジョニングする」を選ぶか、既存のGoogle Cloudのプロジェクトに手動でCloud Runを立てるか、Stapeなどのサービスを使います
3. 自社のドメインを向ける：サイトのサブドメイン、できれば同じオリジンのパスを、タグ設定サーバーに向けます。サブドメインなら、ドメインを管理している会社のDNSの設定にレコードを足します
4. ブラウザのタグの送り先を変える：ウェブコンテナのGoogleタグの設定パラメータに server_container_url を足し、値にサーバーコンテナのURL（https://metrics.example.com など）を入れます
5. 送り先のタグを置く：サーバーコンテナに、GA4のタグなど送り先ごとのタグとトリガーを置き、プレビューでクライアントがリクエストを受け取り、タグが動いているかを確かめます
6. 本番の準備をする：本番の訪問を流す前に、Cloud Runで「新しいリビジョンの編集とデプロイ」から台数を増やし、ログの記録を止めるかを決めます

サーバーコンテナのGA4クライアントには、「Cookie とクライアントの識別」という設定があり、「JavaScript 管理」と「サーバー管理」から選びます。Googleの学習コースは、最初は「JavaScript 管理」を選び、サーバーのドメインを自社のものにしてから「サーバー管理」を検討する流れで説明しています。この設定は、次の節で説明するとおり、過去のデータとのつながりに関わります。サーバーコンテナを作るには、GTMのアカウントで管理者の権限が要ります。権限の付け方はGTMの権限の記事にまとめています。

ULTRO NOTES｜計測・分析GTMの権限付与の手順｜6つの権限の違いとアカウント削除の方法GTMの権限は、アカウントの2つ（管理者・ユーザー）とコンテナの4つ（公開・承認・編集・読み取り）の組み合わせです。付与と削除の手順、外部に渡すときの目安、アカウントやコンテナを削除したときの30日間の扱いまでまとめます。

サーバーコンテナからGoogle広告のコンバージョンを送るときは、「Google 広告のコンバージョン トラッキング」タグに加えて、「コンバージョン リンカー」タグもサーバーコンテナに置きます。拡張コンバージョンもサーバーコンテナから送れます。考え方は拡張コンバージョンの記事にまとめています。

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

同意モードは、ウェブコンテナ側だけで設定します。Googleのドキュメントでは、同意バナーで選ばれた内容をGoogleタグが受け取り、サーバーコンテナへのリクエストに同意の状態を付けて送り、サーバーコンテナのGoogleのタグはそれに合わせて送る内容を変えます。地域ごとに同意の扱いを変える高度な同意モードを使うなら、タグ設定サーバーで「地域ごとの設定」も有効にします。

ShopifyでサーバーサイドGTMを使うときの注意点

ShopifyでサーバーサイドGTMを使うときに気をつけるのは、カスタムピクセルのサンドボックス、Shopifyの公式アプリとの二重送信、クライアントIDの切り替え、ストアのCDN・ドメインの構成の4つです。

カスタムピクセルのサンドボックス

ShopifyではGTMをカスタムピクセルの中で動かすため、ページの要素を読む計測は使えず、Shopifyの顧客イベントを受けて組む必要があります。チェックアウトや購入完了のページには、テーマのようにスクリプトを直接書けないので、管理画面の「顧客イベント」に入れるカスタムピクセルでGTMを動かすのが、Shopifyが案内している方法です。カスタムピクセルは「Laxサンドボックス」という、外部に送るデータを制限するための環境で読み込まれます。

Shopifyのヘルプでは、サンドボックスの中ではページの要素を読み取ってイベントや購入者の情報を拾うこと、外部リンクのクリックやスクロールを自動で拾うことができず、ページのURLも自動では正しく取れないと説明しています。GTMで計測するには、Shopifyが用意する顧客イベント（page_viewed、checkout_completed など）を受けて、データレイヤーに渡す形で組みます。GoogleのTag Assistantの「Troubleshoot tag」はカスタムピクセルでは使えず、確認にはShopify Pixel Helperを使うよう案内されています。カスタムピクセルの組み方は、Shopifyのカスタムピクセルの記事にまとめています。

ULTRO NOTES｜計測・分析Shopifyのカスタムピクセルとは？顧客イベントでの設定方法とGA4・GTMの注意点Shopifyのカスタムピクセルは、［設定］＞［顧客イベント］で計測タグを入れる仕組みです。追加の手順、GA4のイベント対応表、GTMを入れるときの注意（プレビュー・page_location・二重計上）、同意の設定まで解説します。

Shopifyのドキュメントでは、購入完了のイベント（checkout_completed）は購入完了のページが読み込まれないと発生しません。購入後のアップセルを出しているストアでは、最初のオファーのページで発生し、完了ページでは発生しません。サーバーサイドGTMは、このイベントが起きたあとの届け方を変えるもので、イベントが起きなかった購入には効きません。

Google & YouTubeアプリ・Facebook & Instagramアプリとの二重送信

Google & YouTubeアプリでGA4を入れたままサーバーサイドGTMのGA4を足すと、同じ購入が二重に入ります。Google & YouTubeアプリの設定画面に、送り先をサーバーコンテナに変える項目は、当社では確認できませんでした。サーバーサイドGTMに切り替えるなら、GA4はどちらか一方の経路だけにします。

アプリで連携していても、ブラウザのタグで計測できない購入は残ります。「できること・できないこと」の節で触れた21%の実測も、Google & YouTubeアプリで連携しているストアのものです。自分のストアで注文とGA4を突き合わせて確かめてから、経路を決めます。

Google広告のコンバージョンも同じです。アプリのコンバージョン アクションと、サーバーコンテナのGoogle広告のタグが別々に購入を数えると、自動入札が二重の数字で学習します。二重になったときの見分け方は、GA4の購入が二重に入るときの記事で説明しています。アプリでの連携の仕方はShopifyとGA4の連携方法が参考になります。

ULTRO NOTES｜計測・分析GA4で購入が二重計測（重複）される原因と確かめ方｜Shopifyのアプリ・GTM併用GA4の購入がShopifyより多いのは、同じ注文が2つ以上の経路から送られているためです。トランザクションIDごとの購入数を探索で出す確かめ方、アプリとGTMの重なり、重複除外の仕様、直し方を説明します。ULTRO NOTES｜計測・分析ShopifyとGA4の連携方法｜Google & YouTubeアプリの設定と、計測の限界ShopifyとGA4はGoogle & YouTubeアプリで接続するのが基本です。接続手順、自動で送られるイベント、連携後に確かめる7項目、Shopifyと数字が合わない理由、GTMで入れる場合の注意、よくあるトラブルまで説明します。

Meta広告も同じです。Facebook & Instagramアプリはピクセルとコンバージョン APIの両方を送るので、アプリを入れたままサーバーコンテナからMetaのコンバージョンAPIのタグで購入を送ると、二重になります。サーバーコンテナから送る場合は、ブラウザのピクセルと同じイベント名とイベントID（event_id）を付けます。Metaは、この2つが一致するイベントが48時間以内に届けば、あとから届いた分を除きます。

クライアントIDの切り替えで過去とつながらなくなる

GA4クライアントの「Cookie とクライアントの識別」を「サーバー管理」にすると、サーバーがFPID（サーバーが発行するGA4用のCookie）を発行し、その値をクライアントID（GA4がブラウザごとに振る識別番号）として使います。FPIDは、ブラウザのJavaScriptからは読めないCookie（HttpOnly）です。

既存のサイトで移行の設定をせずに切り替えると、これまでのクライアントIDの代わりに新しいIDが使われ、既存のユーザーが新しいユーザーとして数え直されます。新規ユーザー数やリピートの分析が、切り替えの日を境に続かなくなります。GTMの画面には、それまでのJavaScriptのクライアントIDを引き継ぐ移行の設定がありますが、Googleの公開ドキュメントでは、この設定のくわしい動きは確認できませんでした。切り替える前に、検証用の環境で確かめることを勧めます。

もう1つ、当社が気にしているのは、後から購入を送る仕組みへの影響です。Measurement Protocolで購入を送るときは、ふつうブラウザの _ga Cookie からクライアントIDを読んで注文と結びつけます。サーバー管理に切り替えたあとは、GA4に届くIDと _ga の値が一致しない場合があり、後から送った購入が別の人の購入として入るおそれがあります（Googleの公開ドキュメントには、この点の記載は見つかりませんでした）。

ストアのCDN・ドメインの構成を変えられない

Shopifyのストアは、ページの配信（CDN）をShopifyが管理しています。Googleが最も勧める「同じオリジン」の方式は、ストアのドメインのパスをタグ設定サーバーに転送する設定が必要ですが、標準のShopifyストアでこれを組む公式の設定方法は見当たりません。サブドメインをCloud RunやStapeに向ける方式は組めますが、前の節で触れたとおり、SafariのITPではCookieの期限が7日に縮む条件に当たる可能性があります。Stapeは、この対策の機能（Cookie Keeper など）をShopify向けアプリでも案内しています。

Googleタグゲートウェイ・Meta CAPI Gatewayなど中間的な手段との比較

サーバーサイドGTMを入れる前に、もっと手軽な「中間的な手段」で目的が足りないかを確かめます。Meta広告の成果をサーバーからも送りたいなら、Shopifyでは公式連携で足りることが多くあります。

『ネット広告運用“打ち手”大全 第2版』は、計測を「基礎計測」「シグナル補完」「サーバーサイド」の3段階に分け、下から順に固めることを勧めています。Googleタグゲートウェイ（難易度は低〜中、Cloudflare経由の自動設定が最も簡単）やMetaのコンバージョンAPIゲートウェイ（難易度は低いが、CRMとの連携や長いアトリビューションは直接のコンバージョンAPIほど柔軟ではない）は、2段めの「中間的な手段」に入ります。

手段	何をするか	サーバーの用意	拾えない購入（ブラウザでタグが動かない）を補えるか	向いている場面
Googleタグゲートウェイ	Googleのタグの読み込みと送信の一部を、自社ドメイン経由にする	不要（CDNやロードバランサの設定）	補えない	Shopify以外のサイトで、Googleのタグを自社ドメインから届けたい。標準のShopifyストアには公式の設定方法がない（2026年10月時点）
サーバーサイドGTM	ブラウザのデータを自社のサーバーで受け、加工して複数の送り先に送る	必要（Cloud Run、Stapeなど）	一般的な構成では補えない	計測のガバナンスを固めたい（同意、定義の統一、多国展開）
MetaのコンバージョンAPIゲートウェイ	Metaピクセルのイベントを、自社のクラウド環境からMetaにも送る	必要（AWSなど。Stapeなどのホスティングもある）	補えない	公式連携がないサイトで、Meta広告だけをサーバー経由にしたい
Shopifyの公式連携（Facebook & Instagramアプリ）	Shopifyがピクセルとコンバージョン APIの両方を送る	不要	Meta広告については補える	Shopifyのストアで、Meta広告の成果を送りたい
注文データからMeasurement Protocolで送る	Shopifyの注文を起点に、GA4に無い購入を送る	自前なら必要。アプリなら不要	補える	GA4の計測漏れを埋めたい

Googleのドキュメントは、Googleタグゲートウェイを耐久性の高いタグ設定として勧め、サーバーサイドGTMと組み合わせることも勧めています。ただし、Shopifyのヘルプにもタグゲートウェイのドキュメントにも、標準のShopifyストアでの設定方法は見当たりません。海外の計測会社も、ストアの前にCloudflareを置く標準の方式は、Shopifyがホストするストアでは使えないと伝えています。また、タグゲートウェイもサーバーサイドGTMも、最初のデータはブラウザで取る仕組みです。ShopifyでのMeta広告の送り方はShopifyのMetaコンバージョンAPI 3つの経路に、コンバージョンAPIそのものはコンバージョンAPIの記事にまとめています。

ULTRO NOTES｜計測・分析ShopifyでMetaのCAPI（コンバージョンAPI）を使う3つの方法｜公式アプリ・Gateway・自前の送信ShopifyでMetaのコンバージョンAPI（CAPI）を使う方法は、公式アプリ、CAPI Gateway、自前の送信の3つ。ほとんどのストアは無料の公式アプリで足ります。費用・手間・拾える購入の違いと、重複排除・イベントマッチ品質・注文数との差の確かめ方まで。ULTRO NOTES｜計測・分析コンバージョンAPIとは？ピクセルとの違いとShopifyでの設定コンバージョンAPI（CAPI）は、購入などのデータをサーバーからMetaに送る仕組みです。Metaピクセルとの違い、併用したときの重複除外の条件、設定方法の比較、Shopifyの公式アプリでの設定と、二重計測の確認点をまとめます。

サーバーサイドGTMが必要なストア・要らないストア

サーバーサイドGTMが必要かは、ブラウザの計測と中間的な手段では要件を満たせなくなったかどうかで決めます。同書もこの基準を示しています。当社の目安は次のとおりです。

ストアの状況	サーバーサイドGTM	先にやること・代わりの方法
複数の国でサイトを運営し、国ごとに同意の扱いを変えたい	向いている	同意バナーと同意モードの設定を先に固める
自社のCRMや基幹システムのデータを、計測データと合わせて広告媒体に送りたい	向いている	送る項目と同意の範囲を先に決める
社内か外部に、サーバーと計測を見続けられる人がいる	前提を満たしている	—
GA4とGoogle広告、Meta広告を、Shopifyの公式アプリで入れている	多くの場合は要らない	基本の計測（1アクション1回、完了ページで動くか）を確かめる
GA4の購入がShopifyの注文より少ないのを直したい	これだけが目的なら合わない	注文番号で突き合わせ、漏れた購入をMeasurement Protocolで送る
Safariの割合が高く、Cookieの期限が気になる	効くかはCDN・ドメインの構成しだい	同じオリジンで組めるかを先に確かめる

当社が支援する国内のShopifyストアの多くは、表の下の3行に当たります。GA4やGoogle広告、Meta広告をShopifyの公式アプリで入れていて、困っているのは「GA4の購入が少ない」ことです。この場合、サーバーサイドGTMに切り替えても、困りごとの大きな部分は残ります。基本の計測の確かめ方はGA4の使い方の記事に、同意の扱いはCookie同意バナーの記事にまとめています。

ULTRO NOTES｜計測・分析GA4の使い方｜ECで最初に見るレポートと、設定を直す順番GA4の使い方を、ECサイトで先に押さえる主要な指標8つ、最初に見るレポート4つと、最初に直しておく設定に絞ってまとめます。売上の概要、トラフィック獲得、e コマース購入数、ランディング ページの見方、ユーザー獲得との違い、データの保持・内部トラフィック・キーイベント・サービス間のリンクの設定、Shopifyとのつなぎ方まで。ULTRO NOTES｜計測・分析Cookie同意バナーは必要？ECの判断基準とGA4の同意モードCookie同意バナーが必要かどうかは、どの国のお客様に販売しているかで変わります。日本向けの自社ECに関係する法律、同意バナーを出したときにGA4の数字がどう変わるか、同意モードの基本と高度の違い、Shopifyでの設定をまとめます。

GA4の計測漏れだけを直したいなら：Measurement Protocol

GA4の計測漏れを埋めることが目的なら、計測をまるごとサーバー経由に切り替えるより、注文データを起点にMeasurement ProtocolでGA4に送るほうが、目的に直結します。Measurement Protocolは、サーバーからGA4に直接イベントを送るGoogleの仕組みで、ブラウザを通らない購入も送れます。

送るときは、チェックアウトの時点で控えた元の訪問のクライアントIDとセッションIDを付けます。こうすると、後から送った購入にも元の訪問の参照元が付きます。仕様と期限はMeasurement Protocolとはにまとめています。

ULTRO NOTES｜計測・分析GA4のMeasurement Protocolとは？サーバーから送る方法と48・72時間のルールMeasurement Protocolは、サーバーからGA4に直接イベントを送るGoogleの仕組みです。ECでの使いどころ、purchaseと返金の送り方、48時間・72時間などの期限、検証とDebugView、Data Manager APIとの違いまで。

当社は、この方法をShopifyアプリ「GapFill」にしました。当社の製品なので、その前提で読んでください。サーバーサイドGTMのように計測を切り替えるのではなく、GA4で漏れた購入データを、サーバーサイドで補完します。既存のタグ設定はそのままで、Shopifyの注文とGA4の購入をトランザクションIDで照合し、注文から26時間たってもGA4に無い注文だけをMeasurement Protocolで送ります。計測漏れレポートは無料です。

ULTROのShopifyアプリGapFill｜GA4で漏れた購入データを、サーバーサイドで補完既存のタグ設定はそのまま。計測漏れレポートは無料です。GapFillを見る →

サーバーサイドGTMとGapFillは、どちらか一方を選ぶものではありません。計測のガバナンスのためにサーバーサイドGTMを入れているストアでも、拾えない購入は残るので、その分だけを足す使い方ができます。

導入後に確かめること

サーバーサイドGTMを入れたあとは、イベントが届いているか、二重になっていないか、漏れが減ったかの3点を確かめます。同書も、中間的な手段を入れたあとは、イベントの受信、ブラウザとサーバーの重複の除去、欠損の改善を確かめるよう勧めています。

• 届いているか：GA4の「リアルタイム」やDebugViewで、サーバーコンテナから送ったイベントが出るか。サーバーコンテナのプレビューで、クライアントがリクエストを受け取り、タグが動いているか
• 二重になっていないか：GA4の探索で、ディメンション「取引 ID」（トランザクションIDのGA4の画面での名前）ごとの指標「トランザクション」が2以上になっていないか。Google広告で購入のコンバージョン アクションが2つ「メイン」になっていないか（キーイベントの扱いはキーイベントの記事を参照）
• 漏れが減ったか：Shopifyの注文番号とGA4のトランザクションIDを1件ずつ突き合わせ、切り替えの前後で、GA4に無い注文の割合と決済方法ごとの偏りを比べる
• ユーザー数が急に増えていないか：切り替えの日に新規ユーザーが跳ねていれば、クライアントIDが入れ替わっています。GA4のユーザー数とセッションの記事の数え方と見比べます
• 参照元が崩れていないか：(not set) や direct が急に増えていないか。原因の探し方はGA4の(not set)・directが多い原因にまとめています

探索でディメンションを足すときは、「ディメンションの選択」で「e コマース」の中の「取引 ID」を選び、右上の「確認」を押します。

切り替えの前後で数字を比べるときは、切り替えた日を記録しておきます。『クッキー規制を乗り越える！ 新しいデジタルマーケティングの本』は、計測の条件が変わった期間をそのまま比べないこと、代わりの計測を入れても欠測がなくなったとは扱わないことを勧めています。

参考にした情報

• Server-side tagging（Google for Developers）
• An introduction to server-side tagging（Google for Developers）
• Cloud Run setup guide（Google for Developers）
• Custom domain configuration（Google for Developers）
• Send data to server-side Tag Manager（Google for Developers）
• Prepare for high traffic events（Google for Developers）
• Google アナリティクス 4 データ ストリームの設定（Server-side tagging fundamentals、Google for Developers）
• インフラストラクチャの計画（Server-side tagging fundamentals、Google for Developers）
• ライブ トラフィック対応に向けたサーバーのアップグレード（Server-side tagging fundamentals、Google for Developers）
• 広告主様向け Google タグ ゲートウェイとは（Google for Developers）
• 広告主様向け Google タグ ゲートウェイを設定する（Google for Developers）
• Tracking Prevention in WebKit（WebKit）
• Intelligent Tracking Prevention 2.1（WebKit）
• Implement consent mode with server-side Tag Manager（Google for Developers）
• Google Ads conversions（server-side Tag Manager、Google for Developers）
• カスタムピクセル（Shopify ヘルプセンター）
• ピクセルの概要（Shopify ヘルプセンター）
• Google タグマネージャーのカスタムピクセルを作成する（Shopify ヘルプセンター）
• Web Pixels API（Shopify.dev）
• checkout_completed（Shopify.dev）
• Handling Duplicate Pixel and Conversions API Events（Meta for Developers）
• Conversions API Gateway setup（Meta for Developers）
• 料金（Stape）
• Shopify 向け Stape Conversion Tracking アプリ（Stape）
• Server-side Google Analytics 4 for Shopify（Stape）
• Google Tag Gateway for Shopify（Analyzify、2026年8月）
• ネット広告運用“打ち手”大全 第2版 AI時代に成果を上げる 最強の戦略103（寳洋平・釜周平・ザンノーニ ダリオ）
• クッキー規制を乗り越える！ 新しいデジタルマーケティングの本（広瀬安彦）