sGTMの要否は計測精度では決まらない。決めるのは「誰がどこを触れるか」

sGTM（サーバーサイドGTM）を入れるかどうかは、Cookieの寿命でもページ速度でもなく、サイトに触らずに計測を変えられる範囲を、どこまで広げたいかで決まります。

そして、その範囲を広げたあとに「誰がそこを触り続けるのか」を決めていない会社は、入れないほうがいいです。

上場企業でマーケティング責任者を務め、月間1億円規模の広告費を統括していました。責任者になる前は自分で運用も担当していました。現在はMarket Engineering代表として、GA4/GTM/sGTM等の広告計測設計、広告運用代行、広告運用のインハウス移行を北九州・大阪の2拠点で支援しています。

① 提案書の中心は、精度の話ではなく役割分担の表だった

ある案件で、代理店経由でsGTMの導入を提案したことがあります。きっかけは「特定の条件に合うコンバージョンだけを媒体に送りたい」という要件でした。

提案書の中心に置いたのは、精度の話でもコストの話でもなく、次の表です。

意味は一行で言えます。初回に発注側が2回だけ動けば、以降の計測変更はサイトに一切触れずに済むようになります。

これがsGTMの本体だと考えています。よく語られるメリット（サーバーサイドCookieのためITPの7日制限を受けず、最大400日まで伸びる）は事実ですが、副次的なものです。実務で効くのは、媒体を1つ足すたびに「サイト側のGTMを公開する」工程が消えることのほうです。

この工程には、たいてい別の会社か別の部署の確認が挟まります。1回あたりの待ちは小さいです。ただ、年に何度も止まります。

② それでもサイト側のGTMは消えない。あえて「できない」と書いた3つ

同じ提案書に、「できること」と並べて「できないこと」の欄を作りました。sGTMを入れてもサイト側のGTMが引き続き必要になる範囲です。

• SPAのpage_view検知（History Change）
• クロスドメイントラッキングの _gl パラメータ管理
• dataLayerの設計と発火

sGTMは、ブラウザから送られてきたデータを受け取って加工し、媒体へ中継する装置です。ブラウザ上で「何が起きたか」を検知する部分は、一切代替しません。

なぜわざわざ「できない」と書くのか？　ここが期待値のずれる箇所だからです。「入れれば計測は支援側で完結する」と受け取られたまま導入すると、SPAでページ遷移がカウントされないといった相談に「それはサイト側の作業です」と答えることになります。導入後にそれを言うのは、かなり筋が悪いんですよね。

判断基準としても効きます。いま困っている計測の不具合がこの3つのどれかに当たるなら、sGTMを入れても解決しません。 先にそちらを直します。

③ 月額費用はほぼ問題にならない。詰まるのはDNSの承認フローだ

sGTMはGoogle CloudのCloud Run上で動き、リクエスト数で課金されます。月200万リクエストの無料枠があるため、桁感はこうなります。

多くの中小企業は、無料枠に収まる範囲に入ります。

自社サイトも実験台にしてsGTMを動かしています。やることは3工程です。Cloud Runにサーバーコンテナを立て、gtm. から始まる自社サブドメインを当て、Webコンテナ側のGoogleタグに送信先を1行足します。

稼働確認はGA4のリアルタイムレポートで済みます。実際に詰まったのは、gcloudコマンドが手元のPythonのバージョンに対応していないという、計測とは何の関係もない理由でした（そもそもsGTMの話ですらありません）。

では、どこがリードタイムを食うのか？　DNSです。サードパーティ扱いを避けるため、エンドポイントは自社ドメインのサブドメインに向ける必要があります。作業はCNAMEを1本足すだけです。

ですが、それを実行できる人が社内にいるとは限りません。ネームサーバーを制作会社が管理している、情シスに申請フローがある、というケースは珍しくありません。冒頭の案件でも、承認フロー込みで数週間から1ヶ月を見込むこと、DNS変更の担当者を先に特定することを注意点として明記しました。

自社サイトはDNSも自分で管理しているので即日でした。CNAMEを1本足すのに何人の承認が要るかが導入コストの実体です。

ここから先は自社の数字を見ないと決まりません。

1. 月間PV。 60万PV前後を下回るなら、費用は判断材料になりません
2. 直近1年で媒体を追加・入れ替えした回数。 ①で消える工程の回数がそのまま便益になります。0回なら、sGTMで浮くものはほぼありません
3. 初回接触からコンバージョンまでの日数。 GA4で確認できます。大半が7日以内なら、ITPによるCookie失効の取りこぼしは小さく、「Cookie寿命が伸びる」という代表的なメリットは自社には効いていません

3つとも小さいなら、いま入れる理由はありません。1つでも大きいなら、次が本題になります。

④ 大手・インハウスの場合、問いは「必要か」ではなく「誰が当番を持つか」

規模の大きい組織では、①〜③の判断はたいてい済んでいます。それでも動かない理由は、必要性ではありません。持ち主が決まらないからです。

そもそもクライアントサイドのGTMは、マーケティング部門の持ち物でした。サーバーは要らず、落ちる心配はGoogleが引き受けています。sGTMを入れるとこれが変わります。

自社のクラウド上に常時稼働するサービスが1つ増え、課金が発生し、落ちれば計測が止まります。マーケの持ち物が、インフラの性質を帯びます。決めるべきは3つです。

1. 課金の持ち主。 GCPプロジェクトを誰の部門予算で持つか。小さい金額だからこそ、誰も引き取らないまま宙に浮きます。

2. 公開権限とレビュー。 ①のとおり、サーバーコンテナは「サイトに触らずに媒体への送信内容を変えられる場所」です。裏を返せば、サイト側のレビューを通さずに計測が変わる場所ができます。

誰が公開し誰が確認するかを決めないと、部門ごとにタグが積み上がる構造がサーバー側へ移るだけになります。しかもサーバー側の設定は、月次レポートのどこにも載りません。載っていない軸は誰も見ないという話は代理店のレポートを毎月確認しても、広告は最適化されないに書きました。

3. 落ちたときの一次受け。 これは自分でも痛い目を見ています。自社サイトのCMSを同じCloud Run上で動かしているのですが、アプリのプロセスが落ちてもコンテナ自体は生き続けます。

そのため、外形監視を入れるまで異常に気づけませんでした（ここは完全に設計側の見落としです）。sGTMで同じことが起きれば、症状は「計測が全部止まる」になります。

そしてGA4のデータは、遡って復元できません。運用責任を引き取るというのは、こういうことです。

よくある反論への回答

「媒体ごとのCAPI（コンバージョンAPI）を入れれば同じでは？」

1媒体だけならCAPIのほうがだいぶ早いです。差が出るのは媒体数が増えたときです。冒頭の案件でsGTMが選ばれた決め手も精度ではなく、送信条件を都度変えられること、媒体タグの入れ替え・追加をサイト側の公開作業なしにできること、この2つでした。

「AIに聞けば自分で構築できるのでは？」

できます。手順は公開情報で、自社サイト分は調べながら自力で動かしました。ただし詰まるのはDNSの承認フロー（③）で、終わらないのは運用当番の決定（④）です。

構築が終わった時点で、仕事はまだ始まってすらいません。この構造はAI時代にコンサルへ発注する意味は、知識ではなく時間だったに書きました。

「代理店がsGTMを提案してきた。乗るべきか？」

①の表を自社のケースで埋めてもらうといいです。誰がホストするのか。導入後もサイト側に残る作業は何か（②）。

代理店にホスティングごと任せる構成は現実的で、冒頭の案件で提案したのもこの形です。ただしその場合、契約が終わったときサーバーと設定は誰のものかを先に決めておきます。代理店を変えるときは計測基盤ごと引っ越すことになり、移行中に止まればその期間の数字は戻りません。

この記事の内容を自社に当てはめたい方へ。

②のとおり、壊れた計測はサーバーを立てても直りません。前提となるGA4の設定状況を10項目でチェックできる無料チェックリストを用意しています。

無料チェックリストをダウンロードする

自社にsGTMが要るのか、要るとして誰が運用を持つのか。今の体制のまま話しながら整理したい方は、30分の無料相談も受け付けています。

無料相談を予約する（30分・オンライン）