サーバーサイドGTMを入れても、Cookieの利用に同意しなかったユーザーのコンバージョンは取り戻せる対象になりません。戻せるのは、SafariのITPなどで寿命を削られたCookieに起因する欠損が中心です。それでも「入れれば広告の数字が元に戻る」と期待して導入を決め、クラウドの請求だけが毎月届く状態に陥る企業があります。
期待と結果がずれるのは、欠損の中身を分けないまま仕組みの話から入ってしまうためです。株式会社Grillが計測診断に入る現場でも、サーバー化より先に直すべきタグの不具合が見つかる例が目立ちます。
ここでは、2026年時点のGoogle・WebKit・Metaの公式情報を根拠に、サーバーサイドGTMで取り戻せる計測の見極め方を整理しました。Cloud RunやStapeなどの構成と費用、Cookie寿命を決めるドメイン設計、移行の順序と導入後の数値の読み方まで順に扱います。
GRILLは支援実績500社以上のマーケティング会社です。広告運用の専門家が御社の課題に合わせた具体的な施策をご提案します。
初回相談は完全無料!まずはお気軽にご相談ください。

導入の可否は、いま起きている計測の欠損を「サーバー化で改善を狙えるもの」「サーバー化しても戻らないもの」「移行前に直すべきもの」の3つに分けてから判断します。分類を飛ばすと、効果の出ない導入や、不具合ごと新環境へ移す事態を招きます。
WebKitの公式ドキュメントによれば、SafariのITPはJavaScriptで作られたCookieを、サイトとのやり取りがないまま7日が過ぎると削除します。8日後に再訪したユーザーは新規として数えられ、広告経由の購入も最初の接点と結び付きません。
サーバーサイドGTMを自社ドメインで動かすと、CookieをブラウザのスクリプトではなくサーバーのHTTPレスポンスで発行できます。この設定によって、7日で切れていた識別子の寿命を延ばせる可能性があります。ただし効果はドメインの組み方で大きく変わるため、詳細は第4章で扱います。
Cookieバナーで計測を拒否したユーザーのデータは、サーバーへも送信しないことが正しい状態です。サーバー経由なら送れてしまうとしても、それは同意の仕組みを迂回する行為であり、プライバシー上の信頼を失います。同意拒否分の穴埋めを目的にした導入計画は、最初から成り立ちません。
広告ブロッカーも同じ扱いです。独自ドメインにすると一部の遮断を避けられる場合はありますが、ブロッカーの利用もユーザーのプライバシー上の選択であり、判定も随時更新されます。株式会社Grillでは、ブロッカー由来の欠損を回復の見込み額に含めない前提で試算しています。
サンクスページの読み込みごとに購入が発火する、決済サービスを経由するとセッションが途切れる、といった不具合はタグの設計の問題です。サーバーコンテナは届いたデータを加工して振り分ける場所なので、壊れた状態で届けばそのまま各媒体へ流れます。
移行後に数値がずれると、原因がサーバー化にあるのか元の不具合にあるのかを切り分けられなくなります。二重計測とクロスドメインの問題は、今のウェブ側の設定で先に直しておくのが、導入を成功させる近道です。「リスティング広告のコンバージョン設定」も、この段階で見直す対象です。
サーバーサイドGTMで直接改善できる欠損は、全体の一部にとどまると考えておくべきです。株式会社Grillが計測診断を実施した広告主(EC・美容クリニック・人材、2025年10月〜2026年6月、N=23社)で、コンバージョン計測の欠損原因を件数ベースで分類した結果は以下のとおりです。
| 欠損の原因 | 割合 | サーバーサイドGTMとの関係 |
|---|---|---|
| タグの設置ミス・二重計測 | 39% | 移行前に直す |
| ITPなどによるCookieの短命化 | 30% | 改善を狙える |
| 同意拒否・広告ブロッカー | 18% | 戻らない |
| クロスドメインなどその他 | 13% | 個別に対処 |
サーバー化で改善を狙えるのは3割ほどで、最も多いのは設置ミスでした。移行の前にタグの棚卸しをするだけで、欠損の4割近くに手が届く計算です。計測の精度を上げる作業は、サーバー化の前から始められます。
\ 正しい効果計測と分析設計に強い /
【無料】計測と広告運用を無料相談>
3分類で期待値をそろえたところで、サーバーサイドGTMがどのような仕組みで動くのかを整理します。データの流れを押さえると、表示速度・セキュリティとプライバシーの保護・Cookie寿命という3つのメリットがどこから生まれるのかが見えてきます。
従来のGTMは、ページ内のコンテナがGA4やMeta、Google広告の収集サーバーへそれぞれ直接データを送る構成です。Googleの開発者向けドキュメントでは、サーバーサイドのタグ設定を「ユーザーのブラウザやスマートフォンではなく、自社が管理するサーバー上で動くコンテナ」と説明しています。
サーバーサイドGTMでは、ブラウザは自社サーバーへ1本だけ送信し、そこから各媒体へ振り分けます。サーバーは自社のGoogle Cloudプロジェクトのほか、自社で選んだ別の環境でも動かせると公式に記載されています。
サーバーコンテナのタグ・トリガー・変数という考え方は、通常のGTMと変わりません。新しく加わるのが「クライアント」で、公式ドキュメントでは端末上のソフトウェアとサーバーコンテナをつなぐアダプターと定義されています。
処理の順序は次のとおりです。
ページ上で動く計測タグが少なければ、ブラウザで実行するコードも減ると、Googleの公式ページは説明しています。媒体ごとのスクリプトを読み込む代わりに、データの送信先を1本にまとめられるためです。
とくに複数の広告媒体へ出稿しているECサイトでは、商品ページに媒体の数だけスクリプトが並びがちです。表示速度の改善はコンバージョン率にも関わるため、LPの改善と並行して検討する価値があります。
Googleの公式ドキュメントには、サーバー内のデータには外部へ送ると決めるまで自社しかアクセスできない、という趣旨の記載があります。ブラウザから媒体へ直接送る構成では、どの項目が渡るかをタグの提供元に委ねる部分が残り、セキュリティの管理が行き届きにくくなります。
サーバーを経由させれば、IPアドレスの削除やURLに紛れ込んだメールアドレスの除去を、媒体への送信の手前でまとめて設定できます。プライバシーへの配慮とセキュリティの強化を同じ場所で管理できる点が、この構成の実務上の利点です。
サーバーサイドGTMを入れると通常のGTMは要らなくなる、と考える担当者は多いのですが、ウェブコンテナは残ります。ブラウザ上でクリックや購入を検知し、そのデータをサーバーへ送る役目は引き続きウェブ側が担うためです。
株式会社Grillの支援経験上、移行後に変わるのは「ウェブコンテナの送り先が1本になる」点です。ウェブコンテナとサーバーコンテナの2つを運用する体制を前提に、編集権限と設定変更のルールを決めておく必要があります。権限を絞っておくことは、セキュリティ対策にもなります。

サーバーサイドGTMのツール自体は無料ですが、導入するとサーバーを動かすインフラの費用は必ず発生します。月々のコストと手間、セキュリティの管理範囲は、どこでサーバーを動かすかでほぼ決まるため、代表的な4構成を比較します。
| 構成 | 月額の目安 | 構築の難しさ | 扱える範囲 | 運用の責任 |
|---|---|---|---|---|
| Google CloudのCloud Run | 推奨構成で約90ドル〜 | 高い | GA4・広告媒体など全般 | 自社(または支援会社) |
| Stape | 年払いで月17ドル〜 | 中程度 | GA4・広告媒体など全般 | Stapeと自社で分担 |
| Googleタグ ゲートウェイ | CDNの利用料による | 比較的低い | Googleタグのみ | 自社(CDN側) |
| コンバージョンAPIへ直接送信 | 実装方法による | 実装次第 | 対象の媒体のみ | 自社(開発側) |
金額は2026年9月時点の各社公式ページにもとづく目安です。ドル建ての料金は為替で円換算額が動くため、見積もりでは換算の時点をそろえて比較してください。
Googleの構築ガイドは、サーバー停止時のデータ消失を防ぐため、Cloud Runで最低2つのインスタンスを動かす構成を推奨しています。1台あたり1vCPU・0.5GBメモリでCPUを常時割り当てる設定で、費用は1台約45ドル/月です。推奨どおり2台で組むと、月90ドル前後が出発点になります。
アクセスが増えれば自動で台数が増え、公式ガイドでは2〜10台で毎秒35〜350リクエストを処理できる見込みとしています。Google Cloudの無料トライアルでは90日間使える300ドル分のクレジットが付与され、Cloud Runにも月200万リクエストまでの無料枠があります。
CPUを常時割り当てる推奨構成は、この無料枠に収まりません。無料トライアルの終了後に請求が始まる点を見落とし、Cloud Runの月額を予算に入れていなかったという相談は、株式会社Grillにも繰り返し寄せられています。Cloud Run以外のサーバーで動かしたい場合は、Googleが公開しているDockerイメージを使った手動構築も選べます。
Stapeは、サーバーコンテナのホスティングを専門に提供する海外の事業者です。2026年9月時点の公式料金ページでは、年払いの月額換算で次のように掲載されています。
| プラン | 月額(年払い換算) | 月間リクエスト上限 |
|---|---|---|
| Free | 0ドル | 1万 |
| Pro | 17ドル | 50万 |
| Business | 83ドル | 500万 |
| Enterprise | 167ドル | 2,000万 |
StapeはサーバーGTMのホスティングを提供しているため、Google Cloudでサーバーを自前で用意しなくても導入しやすい構成です。一方、公式サイトで日本語サポートの記載は確認できなかったため、問い合わせ対応は英語になる前提で考えておくと安全です。
広告主向けのGoogleタグ ゲートウェイは、Googleタグを自社のドメインから配信できるようにする仕組みです。公式ドキュメントでは、任意のCDNを使って設定できると説明されています。Google Cloudなどでサーバーを自前で持たずに済むため、構築やセキュリティ更新の負担は小さくなります。
ただし扱えるのはGoogleのタグに限られ、Metaなど他媒体のタグはそのままです。Googleは、ゲートウェイとサーバーサイドのタグ設定の両方を組み合わせる形を最も耐久性の高い構成として推奨しています。どちらか一方を選ぶものではない点に注意してください。
MetaのコンバージョンAPIは、広告主のサーバーやCRMから購入などのイベントをMetaへ直接送る仕組みです。ECカートや予約システムが連携機能を持っていれば、サーバーサイドGTMを介さずに導入できます。
送り先がMeta1社で、カート側の連携で足りるなら、この方法が最も手軽です。反対に、複数の媒体へ同じ購入データを送りたい場合や、送る項目を自社で統一したい場合は、サーバーコンテナで一元管理するほうが運用しやすくなります。「Instagram広告の効果測定」でも、計測を補う手段としてコンバージョンAPIが使われています。
\ 正しい効果計測と分析設計に強い /
【無料】計測と広告運用を無料相談>
どの構成を選んでも、Cookieの寿命を延ばせるかどうかはドメインの設計と設定で決まります。サーバーを導入しただけではITPへの効果は出ないため、方式ごとの違いを押さえておきましょう。
Google CloudのCloud Runなどで発行される初期のURLのまま使うと、タグ設定サーバーはサイトから見て第三者の立場で動きます。Googleのカスタムドメインに関する公式ドキュメントでは、この状態のサーバーはJavaScriptのCookieしか扱えないと説明されています。
つまり初期URLのままでは、ITPで7日に制限されるCookieの扱いは変わりません。公式ドキュメントも、Cookieの耐久性を得るにはタグ設定サーバーとサイトを同じドメインで動かす必要があるとしています。
同じドメインで動かす方法は2つあります。「metrics.example.com」のようなサブドメインをDNSの設定で割り当てる方式と、「www.example.com/metrics」のように同じオリジンのパスで受ける方式です。
注意したいのはサブドメイン方式です。WebKitの公式ドキュメントでは、第三者のIPアドレスを使った偽装を検知すると、HTTPレスポンスで発行したCookieの有効期限も7日に制限すると明記されています。サブドメインの接続先がサイト本体と大きく異なるIPアドレスだと、この判定を受けてITPの影響が残る可能性があります。
Googleは、同じオリジンのパスで配信する方式をベストプラクティスとして推奨しています。この方式では、CDNやロードバランサの設定で特定のパスへのリクエストだけをタグ設定サーバーへ転送します。
次の条件に当てはまるサイトほど、同一オリジン方式を選ぶ価値が高くなります。
株式会社Grillの支援経験上、サブドメインを切っただけで「ITP対策は完了した」と判断している事例が目立ちます。Safariの開発者ツールでCookieの有効期限を実際に確かめるまでは、対策済みとは言い切れません。

サーバーサイドGTMの価値は、GA4の数字を整えることより、広告媒体へ届くコンバージョンの質を上げることで大きく表れます。ここではMetaとGoogle広告に絞って、連携の設計と導入時の注意点を見ていきます。
Metaの開発者向けドキュメントは、広告成果を最大化するため、コンバージョンAPIをMetaピクセルと併用するよう推奨しています。サーバーからの送信だけに切り替えるのではなく、ブラウザとサーバーの2経路で同じイベントを送る形です。
2経路で送ると、同じ購入が2回数えられるおそれがあります。Metaは、ピクセルの「eventID」とコンバージョンAPIの「event_id」、イベント名の一致をもとに重複を判定すると説明しています。サーバーサイドGTMでは、ウェブコンテナで発行したイベントIDを両方の経路へ同じ値で渡す設定が欠かせません。
購入者をもとにした除外や類似オーディエンスの精度も、この重複処理の出来に左右されます。詳しい使い分けは「Meta広告のターゲティングの種類と設定方法」で整理しています。
Googleの開発者向けドキュメントによれば、サーバーサイドのタグ設定では、Google広告のコンバージョントラッキングタグをページからサーバーへ移せます。その際は、Google広告との間でデータを受け渡すため、コンバージョンリンカーの設定が必要とされています。
Google広告ヘルプでは、拡張コンバージョンを、ハッシュ化したファーストパーティのデータを送って既存のコンバージョン計測を補い、計測の精度を高める機能と説明しています。メールアドレスなどの顧客データは、SHA256という一方向のハッシュ処理をしてからGoogleへ送信される仕組みです。実装する場合は、同意を得たユーザーのデータだけを送る条件を必ず組み込み、プライバシーへの配慮を設計の前提にしてください。
株式会社Grillの運用経験上、自動入札の成果を左右するのは、送るコンバージョンの件数より偏りの少なさです。Safariで検討期間の長いユーザーの購入だけが抜け落ちると、入札の学習はAndroidや即決型のユーザーに寄っていきます。
サーバーサイドGTMで欠損を減らす目的は、管理画面の数字を増やすことではありません。購入に至ったユーザーの姿を学習に正しく渡し、入札の精度を戻すことです。Meta広告であれば、「機械学習を活かす配信設定」と組み合わせることで、戻った購入データが学習に生きてきます。
\ 正しい効果計測と分析設計に強い /
【無料】計測と広告運用を無料相談>
構成とドメイン方式が決まると、次は誰が導入を担い、誰が保守するかの判断です。費用の見積もり方と自社運用・外注の違い、外注先に確認すべき4つの判断基準を順に取り上げます。
サーバーサイドGTMの費用は、毎月のインフラ費と、構築・保守にかかる人件費や委託費の2つに分けて考えます。インフラ費は第3章のとおり、Cloud Runの推奨構成で月90ドル前後から、Stapeなら年払いで月17ドルからが目安です。
構築を外注すると、数十万〜百万円規模の初期費用がかかる例もあります(料金を公開している支援会社は第7章で紹介します)。クラウドの費用について、株式会社プリンシプルは一般的な規模のサイトで月額数千円〜数万円程度を目安としています。
導入すべき規模の目安は、月間の広告費とSafariの利用比率で判断します。広告費が月数十万円で、iPhone経由の購入がデータ全体の一部にとどまるなら、まずはタグの棚卸しとコンバージョンAPIの直接連携で足りる場合もあります。サーバー化の費用も、「広告予算の決め方」と同じく売上への寄与から逆算すると判断しやすくなります。
マーケティング担当者だけでの導入は、StapeでGA4のみを移す範囲なら現実的です。一方、サブドメインのDNS設定やCDNの転送ルール、Google Cloudの権限管理には、サイトのインフラを管理するエンジニアの協力が欠かせません。
| 比較軸 | 自社で構築・運用 | 外注する |
|---|---|---|
| 工数 | 構築に数週間、以降も更新対応が続く | 要件の確認と検証の立ち会いが中心 |
| 品質 | 担当者の知識に依存し、属人化しやすい | 他社事例をもとに設計の抜け漏れを防げる |
| コスト | 人件費とインフラ費のみ | 構築費と保守費が上乗せされる |
| 向いている企業 | 社内にGTMとGoogle Cloudの経験者がいる | 広告の成果改善まで一体で進めたい |
広告の運用ごと外部に任せるかどうかも同時に考える場合は、「Web広告代理店おすすめ32社|手数料の内訳と選び方」で手数料の構造を比べておくと判断しやすくなります。
見積もりの金額を比べる前に、次の4つを質問して回答をそろえてください。
4つ目の引き継ぎ資料がないと、担当者が替わった時点で誰もサーバーコンテナを触れなくなります。契約を切り替える可能性まで見据えて、Google Cloudのプロジェクトの所有権を自社に置く形で進めるのが安全です。

導入を外注する場合に候補となる、サーバーサイドGTMの導入支援を公式に掲げる4社を紹介します。比較では金額の大小より、構築後の運用と、広告へデータを届ける設計、セキュリティ面の保守まで含まれるかを見てください。
実際、料金の開示はまだ進んでいない領域です。株式会社Grillが2026年9月にサーバーサイドGTMの導入支援を掲げる他社3社の公式サイトを確認したところ、具体的な金額まで載せていたのは1社でした。見積もりの際は、第6章の4つの質問で含まれる範囲をそろえてから比べるのが確実です。
| 会社名 | 支援範囲 | 料金の目安 | 向いている企業 |
|---|---|---|---|
| 株式会社Grill | 欠損診断・構築・広告媒体連携・入札改善 | 月額数万円〜 | 広告の成果改善まで一体で進めたい企業 |
| アユダンテ株式会社 | 導入検討・構築・社内運用のトレーニング | 要問い合わせ | 将来は自社で運用したい企業 |
| 株式会社プリンシプル | クラウド環境の構築・GA4や広告タグの実装 | Stape利用で90万円〜 | 予算と期間を先に固めたい企業 |
| 株式会社イー・エージェンシー | 導入検討・環境構築・運用支援 | 要問い合わせ | GA4の分析基盤とあわせて整えたい企業 |
料金は2026年9月時点の各社公式サイトの記載にもとづきます。

【広告のコンバージョン計測を欠損原因から組み直す、サーバーサイドGTMの実装パートナー】
株式会社Grillは、サーバーサイドGTMを「広告の入札に正しい購入データを届ける手段」として設計する会社です。最初にタグの設置ミス・Cookieの短命化・同意拒否の3つに欠損を分け、サーバー化で戻る範囲を数値で示してから構築に入ります。MetaのコンバージョンAPI連携やevent_idによる重複排除、同一オリジン方式のドメイン設計まで、第4章・第5章で挙げた論点を1つの体制で担います。
EC・人材などの広告主で、GA4から広告タグへと段階的に移す支援を重ねてきました。移行後は管理画面の数字の変化を読み解き、どのキャンペーンへ予算を寄せるかの判断までつなげます。GA4と広告管理画面の計測データの差分をAIで日次に集計するため、検証と改善のサイクルを短い間隔で回せる点も強みです。
サーバーサイドGTMの構築・運用支援は月額数万円〜で、広告運用とあわせる場合の手数料は10%〜と、業界標準とされる20%の半額水準です。計測の改善と並行して、LPの改善や広告クリエイティブの制作にも対応できます。
| 会社名 | 株式会社Grill |
| 所在地 | 東京都渋谷区東3丁目22−14 グランファースト恵比寿 5階 |
| 公式サイト | https://grill.co.jp/ |

【社内で運用を続けられる体制づくりまで見据えたサーバーサイドGTM支援】
アユダンテ株式会社は、サーバーサイドGTMの導入検討から構築、さらに顧客自身で運用していくためのトレーニングまでを支援メニューとして公開しています。
構築後に社内でコンテナを触れる人材を育てたい企業に向いています。料金は支援内容によって異なるとして、問い合わせ制をとっています。
| 会社名 | アユダンテ株式会社 |
| 所在地 | 東京都千代田区麹町2丁目2−4 麹町セントラルビル6階 |
| 公式サイト | https://ayudante.jp/ |

【Google CloudとStapeの両方に対応するワンストップ型の導入支援】
株式会社プリンシプルは、Google Cloudなどのサーバー環境の構築から、GA4や各種広告媒体タグのサーバーサイド実装までをワンストップで支援しています。
Stapeを利用する場合の料金を90万円〜、提供期間を3カ月〜と公式サイトに明記しており、社内稟議の前に予算感をつかみやすい会社です。
| 会社名 | 株式会社プリンシプル |
| 所在地 | 東京都千代田区神田駿河台4-2-5 トライエッジ御茶ノ水10階 |
| 公式サイト | https://www.principle-c.com/ |

【GA4の分析基盤とあわせてサーバーサイドGTMを整える支援】
株式会社イー・エージェンシーは、サーバーサイドGTMの導入検討から環境構築、運用のサポートまでを提供中と公式サイトで案内しています。2026年9月にはGoogleタグ ゲートウェイとサーバー側のタグ設定を扱うセミナーの告知も掲載されていました。
GA4を中心とした分析環境の整備と、サーバー化を同時に進めたい企業の候補になります。料金は公式サイトに記載がないため、問い合わせが必要です。
| 会社名 | 株式会社イー・エージェンシー |
| 所在地 | 東京都千代田区有楽町1-9-4 蚕糸会館4階(株式会社イー・エージェンシーグループ本社) |
| 公式サイト | https://www.e-agencygroup.co.jp/ |
\ 正しい効果計測と分析設計に強い /
【無料】計測と広告運用を無料相談>
依頼先が決まり導入に進む段階でも、すべてのタグを一度に切り替えるのは避けてください。数値がずれたときに原因を特定し、計測の精度を確かめられるよう、GA4、広告タグ、残りのタグの順に3段階で移します。
段階を分けると時間はかかりますが、その分だけ広告の数字に確かな変化が出やすくなります。株式会社Grillが移行を支援した広告主(EC・人材、2025年11月〜2026年7月、N=9社)では、第1段階の開始から第2段階の完了まで平均6.5週間でした。同じ9社で同一オリジン方式へ移した後の4週間は、移行前の4週間と比べ、Meta広告の管理画面上の購入コンバージョンが平均14%増えています。
最初に移すのはGA4です。広告の入札に直接影響しないため、ずれが出ても損失が小さく済みます。既存の計測は止めず、サーバー経由のデータを検証用のプロパティへ送り、両方の数字を並べて比べます。同意状態の受け渡しもこの段階で確かめ、プライバシーの設定がサーバー側でも守られているかを見ておきます。
この段階で、サーバーコンテナのプレビューが動くかも確認しておきます。Googleの手動構築ガイドによると、Cloud Run以外の環境ではタグ設定サーバーとプレビュー用サーバーを別々に用意する必要があります。プレビューが使えないと、以降の段階で不具合を見つけにくくなります。
GA4で数値差の原因を説明できるようになったら、MetaとGoogle広告のコンバージョンタグを移します。Metaはピクセルを残したままコンバージョンAPIを追加し、第5章のevent_idによる重複排除が効いているかをイベントマネージャで確認します。
入札の学習は、計測の変化にも反応します。キャンペーンの大幅な予算変更やクリエイティブの入れ替えは、この段階の前後で重ねないようにしてください。
ヒートマップやチャットツールなど、画面上で動くこと自体が役割のツールはブラウザ側に残します。サーバーへ移すのは、データを送るだけの計測タグに限るのが原則です。個人情報を扱うフォーム周りのタグは、セキュリティの観点から、サーバー側で送るデータの項目を絞る候補になります。
媒体数が多いサイトほど、すべてを移すより「移さないタグの一覧」を作るほうが判断は早く進みます。残したタグも、第2章で触れた表示速度の観点から、使っていないものを整理する好機です。
並行計測は最低でも2〜4週間続け、次の3つの数値を週ごとに比べます。
3つの数値が説明のつく方向に動いたことを確かめてから、次の段階へ進みます。

サーバーサイドGTMを導入した直後は、GA4や広告の管理画面の数字が想定と違う動きをしがちです。症状から原因の当たりをつけられるよう、よくある5つのパターンを表にまとめました。いずれも設定の見直しで解消できるものが中心です。
| 症状 | まず疑う原因 | 確認する場所 |
|---|---|---|
| GA4のユーザー数が減った | 同一人物の判定が改善した | ブラウザ別の新規ユーザー比率 |
| 広告のCV数が倍近くに増えた | 重複排除の不備 | Metaのイベントマネージャ |
| 参照元が「(not set)」になる | ページ情報の受け渡し漏れ | サーバーコンテナのプレビュー |
| 同意を拒否した人の数字が増えた | 同意状態の未連携 | 同意管理ツールの設定 |
| クラウドの請求が急増した | リクエストログの課金 | Google Cloudの請求レポート |
移行後にGA4のユーザー数が減っても、慌てて元に戻す必要はありません。Cookieが7日で消えなくなり、これまで別人として数えていた再訪ユーザーが1人にまとまった結果である可能性があるためです。
見分けるには、ブラウザ別の新規ユーザー比率を見ます。Safariで新規の比率が下がり、コンバージョン数が維持されていれば、計測の精度が上がったと判断できます。
移行した途端にMetaの購入数が倍近くに増えたら、成果ではなく重複を疑います。ピクセルとコンバージョンAPIでイベントIDが一致していない、あるいはイベント名の表記が違う状態です。重複を放置すると、入札の精度も下がります。
株式会社Grillが相談を受けた例では、ウェブコンテナでイベントIDを発行したものの、サーバーへ渡す変数の設定だけが漏れていました。管理画面のCPAが急に半分になったと喜んでいたら、重複が原因だったというケースです。
サーバー経由に変えた後で、流入元やUTMパラメータが「(not set)」になる場合は、ページのURLやリファラーがサーバーへ送信されていないことが多いです。サーバーコンテナのプレビューで、受け取ったリクエストにページ情報が含まれているかを確かめます。「広告の効果測定と指標設計」はUTMの設計が前提になるため、この不具合は予算配分の判断に直結します。
移行後に数字が増えたとき、同意を拒否したユーザーのデータまで送信されていないかを必ず確認します。同意管理ツールの判定を渡す設定が漏れ、サーバーコンテナへ引き継がれていないと起きる不具合です。
第1章で述べたとおり、同意拒否分の数字が増えるのは改善ではなくプライバシー上の問題です。同意を拒否した状態でテスト購入を行い、各媒体へイベントが届いていないことを確かめてから本番に切り替えてください。
GoogleのCloud Run構築ガイドは、月100万リクエストを超える環境では、リクエストログに大きな課金が発生し得ると注意を促しています。そのうえで、リクエストログを無効にする方法を案内しています。
Google Cloudのコンソールで、インスタンスの台数上限も見直しましょう。公式ガイドでは、最大インスタンス数の設定が支払額の最悪値を決めると説明されています。アクセスの実績に合わせて上限を決めておけば、費用の急増を防げます。
\ 正しい効果計測と分析設計に強い /
【無料】計測と広告運用を無料相談>
SafariのITPは、7日ごとに識別子を消し続けます。構成を決めかねている間も、8日目に戻ってきた購入者は新規として数えられ、その偏った購入データで広告の入札は学習を重ねています。
サーバーサイドGTMは、計測の数字を増やす装置ではありません。欠損のうちサーバー化で止められる部分を見極め、そこだけを確実に止めるための道具です。計測の精度とプライバシーへの配慮を、設計の段階で両立させる仕組みとも言えます。
1つ目は、欠損の内訳です。第1章の3分類に沿って、設置ミス・Cookieの短命化・同意拒否のどれが多いかを把握すれば、サーバー化で戻る範囲の見込みが立ちます。
2つ目は、Safariの利用比率と購入までの検討期間です。この2つがわかれば、サブドメイン方式で足りるのか、同一オリジン方式まで組むべきかを、導入前に判断できます。
3つ目は、現在のタグの一覧と、GTMやGoogle Cloudの管理権限を誰が持っているかの記録です。移行の範囲と保守の分担は、この一覧をもとに決まります。計測を整えた後の改善の進め方は「リスティング広告の改善ロードマップ」が次の手がかりになります。
並行計測の期間に増えるデータには、Cookie寿命が延びたことによる本当の回復と、ピクセルとサーバーの二重送信による見かけの増加が混ざります。株式会社Grillは、ブラウザ側で計測したコンバージョンとサーバー側のイベントデータをAIで1件ずつ照合し、重複を除いた実数を御社と確認します。
そのうえで、戻ったSafariの購入データがどのキャンペーンに効いているかを見極め、入札の目標値の設定と広告の予算配分を組み直します。計測データの整備と広告の運用を切り離さず、移行後の運用判断まで同じ担当者が受け持つ体制です。GTMのコンテナを閲覧権限で共有いただければ、サーバーへ移すタグとブラウザに残すタグの線引き案を御社にお返しします。
\ 正しい計測で広告運用をするなら /
【無料】GrillにGTM導入を無料相談>