サーバーサイドGTMは導入すべきか｜Cookieの延命はサブドメインでは足りず、戻る件数を見積もってから費用を決める

広告代理店や計測ツールの提供会社から「Cookie規制への対応としてサーバーサイドGTMを入れましょう」と提案される。GA4やGoogle広告の管理画面の件数と、実際の問い合わせ台帳の件数が合わず、原因を調べるうちに「サーバーサイドで計測すれば戻る」という記事に行き着く。この段階で多くの会社が、サーバーサイドGTMを「入れれば計測が守られる仕組み」と受け取っています。サーバーサイドGTMは、ブラウザから直接送っていたデータを自社のサーバー経由で送る仕組みで、何が戻るかは経路の作り方と自社の訪問者の構成で決まります。サブドメインをサーバーに向けるだけの構成では、Safariに対する効果はほとんど得られません。

この記事では、サーバーサイドGTMが何をどう変えるのかを押さえた上で、Safariの制限がどこまで越えられるのか、費用の内訳、自社で戻る件数の見積もり方、先に済ませるべき代替手段、導入する場合の順序を整理します。構築手順そのものはGoogleのドキュメントに載っているため、この記事は「自社に必要か」と「入れた後に何が変わるか」に重心を置きます。

サーバーサイドGTMは「入れるか」ではなく「経路を用意できるか」と「戻る件数」で決まる

最初に結論を示します。サーバーサイドGTMを導入すべきかは、自社サイトと同一オリジンの経路を用意できるか、そしてその構成で戻る件数が費用に見合うかの2点で決まります。どちらか一方が欠けると、サーバーを立てて月の費用を払い続けても、管理画面の数字はほとんど変わりません。

理由は、サーバーサイドGTMに期待される効果の中心が「Cookieの寿命」にあるためです。Safariは、JavaScriptで書かれたCookieの有効期限を7日に切り詰めます。サーバーから書いたCookieはこの対象外なので、サーバーサイドGTMを自社ドメインで動かせば長く保てる、というのが提案の根拠です。ところが、WebKitは2022年10月の変更で、サーバーがサイトと別のIPアドレスから応答している場合にも、そのCookieを7日に切り詰めるようにしました。サブドメインを外部のサーバーに向けるだけの構成は、この条件にほぼ当たります。

もう1つの理由は、戻る件数が訪問者の構成で決まることです。Safariの制限で消えるのは、Safariを使い、クリックから7日を超えて（クリックIDが付いた訪問なら24時間を超えて）問い合わせた人のコンバージョンです。自社の訪問者にSafariがどれだけいて、検討期間がどれだけ長いかで、戻る件数の上限は計算できます。月の問い合わせが数十件の会社では、この上限が月に数件になります。

したがって、判断の順序は「サーバーサイドGTMを入れるか」から始めません。管理画面と台帳の差を測り、その差のうちSafariの制限に由来する分を見積もり、同一オリジンの経路を用意できるかを確認してから、費用を見ます。Cookieを巡る計測環境の変化と、必要な対応・不要になった対応の全体像はCookie規制で広告の計測はどう変わったか｜必要な対応と、不要になった対応で整理しています。サーバーサイドGTMはその中で最も負荷の高い手段で、先に済ませる手段があります。

仕組み｜ブラウザから直接送らず、自社のサーバーコンテナを経由する

通常のGoogleタグマネージャー（ウェブコンテナ）では、訪問者のブラウザで動くタグが、GA4やGoogle広告、Metaなどの媒体のサーバーへ直接データを送ります。サーバーサイドGTMでは、ブラウザからのデータをいったん自社が管理する「サーバーコンテナ」で受け、そこで動くタグが各媒体へ送ります。Googleのドキュメントは、サーバーコンテナを「タグ、トリガー、変数という同じモデルで動くが、ブラウザではなく自社のインフラで動くもの」と説明しています。

サーバーコンテナには、GA4向けの「クライアント」とタグが最初から入っています。ブラウザ側のGA4のタグの送信先をサーバーコンテナに向けると、サーバー側のクライアントがそれを受けてイベントに変換し、GA4のタグがGoogleへ送ります。Google広告のコンバージョンやMetaのコンバージョンAPIへは、同じイベントを元に別のタグで送れます。サーバーサイドGTMで変わるのは「どこでタグが動き、どこからCookieが書かれるか」であり、計測の定義や同意の扱いは変わりません。

Googleは、サーバーの初期設定をタグマネージャーの画面から自動でCloud Run上に用意する方法と、Google Cloudで手動で用意する方法の両方を用意しています。外部のホスティング事業者を使う選択肢もあり、費用の節で扱います。

期待される効果の中身｜Cookieの寿命、送るデータの制御、ブラウザの負荷

サーバーサイドGTMの効果として挙げられるのは主に3つです。このうち中小企業の判断に直接効くのは1つ目で、2つ目と3つ目は「あれば良いが、それだけのために入れる理由にはならない」ものです。

1. Cookieの寿命｜サーバーから書いたCookieは、Safariの7日制限の対象外になり得る

GA4の利用者を識別する _ga や、Google広告のクリックIDを保持する _gcl_aw は、通常はブラウザのJavaScriptで書かれます。Safariはこれを7日で消すため、初回のクリックから8日後に問い合わせた人は別人として扱われ、広告のコンバージョンとして結び付きません。サーバーコンテナは、応答ヘッダーでCookieを書けます。GA4のクライアントには、識別子を「サーバー管理」に切り替える設定があり、FPIDという名前のCookieをサーバーから書きます。このCookieはHttpOnly属性が付き、ブラウザのJavaScriptからは読めません。

ただし、これが効くのは、サーバーコンテナが自社サイトと同一オリジンで応答している場合に限ります。次の節で詳しく扱います。

2. 送るデータの制御｜媒体へ渡す項目を自社で決められる

ブラウザで媒体のタグが動く構成では、媒体のタグが何を送っているかを自社で制御しにくく、送り先を絞ることもできません。サーバーコンテナでは、受け取ったイベントから項目を削る、IPアドレスを送らない、特定の媒体にだけ送るといった制御ができます。Googleのドキュメントは「サーバー内のデータには、自社が他へ送ると決めるまで自社だけがアクセスできる」と説明しています。個人情報の扱いに厳しい業種や、媒体へ送る項目を監査で説明する必要がある会社には、この点が導入理由になります。

3. ブラウザの負荷｜読み込むスクリプトが減る

媒体ごとのスクリプトをブラウザで読み込む代わりに、送信先を1つにまとめられるため、ページの表示は軽くなります。ただし、タグの数が数個の中小企業のサイトでは、改善幅は体感できる規模になりません。表示速度に課題があるなら、画像やサーバーの応答など、先に手をつける箇所があります。優先順位はサイトの表示速度を改善する優先順位｜何から手をつけるかで整理しています。

Safariの制限は「サブドメイン」では越えられない｜IPアドレスの比較

サーバーサイドGTMの提案で最も誤解が多いのがこの点です。「自社ドメインのサブドメインをサーバーに向ければファーストパーティCookieになり、Safariの制限を受けない」という説明は、2022年10月以前の仕様です。WebKitのトラッキング防止のドキュメントに沿って、現在の規則を整理します。

4行目が問題です。WebKitに取り込まれた変更の説明によると、応答のCNAMEが空の場合、応答したサーバーのIPアドレスとサイト本体のIPアドレスを比較し、IPv4なら先頭16ビット、IPv6なら先頭64ビットが一致しなければ、CNAMEクローキングと同じ7日の上限を適用します。Googleのドキュメントも、Cloud Runの既定のドメインのままでは「第三者のコンテキストで動き、サーバーから書いたCookieの利点は得られない」とし、同一オリジンでの配信を推奨しています。

自社サイトがレンタルサーバーやクラウドの自社アカウントで動いていて、サーバーコンテナがGoogle CloudのCloud Runや外部のホスティングで動いている場合、両者のIPアドレスの先頭16ビットが一致することはまずありません。つまり、サブドメインをサーバーコンテナに向けるだけの構成では、サーバーから書いたCookieも7日で切れます。JavaScriptで書いた場合と比べて、クリックIDが付いた訪問で24時間になる制限は避けられますが、「7日を超えて保てる」という効果は得られません。

この制限を越える構成は2つあります。

Googleのドキュメントは、サブドメイン方式とパス方式の両方を「同一オリジン配信」として挙げていますが、IPアドレスの比較を考えると、Safariに対して確実なのはパス方式か、IPアドレス帯を揃える構成です。提案を受けたら「サーバーコンテナへの経路はどう作るのか」を最初に聞いてください。「サブドメインを向けます」という答えなら、Safariの制限に対する効果は期待できないことを前提に費用を見ます。パス方式には、サイト本体の前段にCDNかロードバランサが要るため、制作会社やサーバーの管理者を巻き込む必要があります。

費用の内訳｜サーバー、ホスティング、構築、運用

サーバーサイドGTMそのものは無料ですが、サーバーコンテナを動かす場所に費用がかかります。主な選択肢はGoogle CloudのCloud Runと、外部のホスティング事業者の2つです。

リクエスト数の見当を先に付けてください。1ページの表示で、GA4のページビュー、スクロール、クリックなどのイベントと、広告のタグの分がそれぞれ1リクエストになります。仮に月3万ページビューのサイトで1ページあたり5〜6リクエストとすると、月15万〜18万リクエストです。外部のホスティングなら月17ドルの枠に収まり、Cloud Runの2台構成なら余裕があります。月100万ページビューを超えるサイトでは、Cloud Runの台数とログの費用、ホスティングの上位の枠のどちらが安いかを比べる段階になります。

見落とされやすいのは運用の費用です。ブラウザでタグが動く構成では、Googleや媒体のサーバーが落ちない限り計測は続きます。サーバーサイドGTMでは、自社のサーバーコンテナが落ちれば、そこを経由する計測が全て止まります。Googleが2台の稼働を推奨しているのはこのためです。止まったときに誰が気付き、誰が直すのかを、導入前に決めておく必要があります。月1万円台のサーバー費用よりも、この体制のほうが中小企業にとっては重い条件になります。

戻る件数の見積もり｜Safariの比率と、クリックから7日を超える割合

費用に見合うかを判断するには、サーバーサイドGTMで戻る件数の上限を見積もります。戻るのは、Safariを使い、クリックから7日（クリックIDが付いた訪問では24時間）を超えて、同じ端末とブラウザで問い合わせた人のコンバージョンです。この3つの条件を掛け合わせると上限が出ます。使う数字は全て自社の管理画面にあります。

計算の例

数字は仮のものです。月の広告経由のコンバージョンが管理画面で60件、台帳では75件の会社を考えます。差は15件で、計測カバー率は80%です。GA4でSafariの比率は45%、Google広告の「コンバージョンまでの日数」で7日を超える割合は20%でした。

この会社で戻るのは、最大でも月7件、実際には端末をまたいだ人や既に拡張コンバージョンで補えている人を除いて、月に数件です。Cloud Runの2台構成で月およそ13,500円をかけると、戻る1件あたり数千円になります。これは問い合わせが増えるのではなく、既に来ている問い合わせが管理画面に載るようになるだけです。得られる効果は、自動入札の学習に使える件数が増えることと、コンバージョン単価の見え方が実際に近づくことの2つで、その価値を月1万円台と運用の手間に対して判断します。1件に払える上限の決め方は広告のCPA目安はどう決めるか｜業種別平均が使えない理由で扱っています。

同じ計算を、月の問い合わせが数百件の会社で行うと、戻る件数は月に数十件になり、費用は同じか少し増える程度です。サーバーサイドGTMの費用対効果は、件数に比例して良くなります。月の問い合わせが数十件の会社が先に手をつけるべき手段は、次の節で扱う拡張コンバージョンと同意の設計です。

先に済ませる代替手段｜拡張コンバージョン、同意の設計、Google tag gateway

管理画面と台帳の差は、Safariの制限だけで生まれるのではありません。差の原因を切り分けずにサーバーサイドGTMを入れると、費用をかけた後に差が残り、原因が分からなくなります。負荷の低い順に、先に済ませる手段を並べます。

拡張コンバージョンは、フォームで取れる情報があれば設定だけで済み、Safariで切れた分の一部をCookie無しで補えます。要否の判断と、増えた件数を成果と混ぜない読み方は拡張コンバージョンは設定すべきか｜フォームで取れる情報の有無で決め、増えた件数を成果と混ぜないで扱っています。

同意バナーで拒否された分は、サーバーサイドGTMでは戻りません。拒否は利用者の選択であり、サーバー経由にしても媒体へ送ってよいことにはなりません。サーバーコンテナで同意モードの詳細設定を使うために、Googleは訪問者の地域を判定するヘッダーの設定を有効にするよう推奨しており、これも別に作業が要ります。同意モードが必要になる条件はGoogleの同意モードは設定すべきか｜同意バナーが無ければ何も変わらず、日本向けサイトで必要になるのは2つの条件で扱っています。

Google tag gatewayは、Googleが用意した比較的新しい選択肢で、サーバーコンテナを持たずに、自社のCDNやロードバランサの設定でGoogleのタグを自社ドメインから配信します。サーバーサイドGTMほどの制御はできませんが、同一オリジンからの配信という点では同じ効果が見込め、サーバーの運用が要りません。Googleはサーバーサイドタギングとの併用を推奨していますが、Googleのタグしか使っていない会社が同一オリジン配信だけを目的にするなら、先に検討する価値があります。

導入を検討する会社と、今は入れない会社

ここまでの条件を、判断の形にまとめます。

導入を検討する会社

• 月の問い合わせが数百件あり、管理画面と台帳の差が大きい。戻る件数が月に数十件になり、費用に見合う
• Safariの比率が高く、検討期間が7日を超える商材。高額な商品、法人向け、比較検討に時間がかかるサービス
• 同一オリジンの経路をCDNかロードバランサで用意できる。サイトの前段に既にCDNがある、または制作会社やサーバー管理者がパス方式を組める
• Metaなど複数の媒体へサーバー経由で送りたい。Metaは、サーバーコンテナ向けのコンバージョンAPIのタグを公式に提供しており、1つのサーバーコンテナから複数媒体へ送れる
• 障害時に対応する担当者が、社内か委託先にいる。止まったときに計測が全て止まる構成であることを理解している
• 媒体へ送る項目を自社で制御する必要がある。個人情報の扱いに厳しい業種、監査で説明が要る会社

今は入れない会社

• 月の問い合わせが数十件。戻る件数が月に数件で、費用と運用に見合わない。拡張コンバージョンと同意の設計で足りる
• 拡張コンバージョンをまだ入れていない。負荷の低い手段を飛ばして、負荷の高い手段に進む順序になっている
• サブドメインをサーバーに向けるだけの構成しか組めない。Safariに対する効果は7日で切れ、提案の根拠が成り立たない
• 同意バナーで拒否された分を戻したい。サーバー経由にしても戻らない。目的が間違っている
• 管理画面と台帳の差の原因を切り分けていない。タグの不具合、電話や別経路の問い合わせ、同意の拒否が混ざったまま費用をかけると、入れた後に差が残る

差の原因を切り分ける順序は、コンバージョンが計測されない原因を確認する手順と同じです。GA4のコンバージョンが計測されない時に確認すべき5つのポイントで扱っており、サーバーサイドGTMの導入前に一度通しておくと、導入後の差をサーバーのせいにせずに済みます。

導入する場合の順序｜差の計測、経路の設計、サーバーの用意、切り替え、確認

入れると決めた場合の順序です。順序を守る理由は、導入の前後で何が変わったかを数字で示せるようにするためです。導入前の数字が無いと、費用に見合ったかを後から判断できません。

1. 導入前の数字を残す

管理画面のコンバージョン数、台帳の件数、計測カバー率、GA4のSafariの比率、Google広告の「コンバージョンまでの日数」の分布を、直近3か月分は記録します。導入後にこれと比べます。

2. 経路を設計する

サブドメイン方式か、同一オリジンのパス方式か、サイト全体を同じCDNの背後に置くかを決めます。Safariに対する効果を目的にするなら、パス方式かIPアドレス帯を揃える構成です。ここでサイトの制作会社やサーバーの管理者を巻き込みます。この段階で「サブドメインしか組めない」と分かったら、Safariに対する効果は7日で切れる前提に戻って費用を見直します。

3. サーバーコンテナを用意する

タグマネージャーで新しいサーバーコンテナを作り、Cloud Runに自動で用意するか、外部のホスティングを使うかを選びます。本番の稼働は2台以上にします。プレビュー用のサーバーも別に立てます。カスタムドメインを設定し、証明書を有効にします。

4. ウェブコンテナの送信先を切り替える

ブラウザ側のGoogleタグの送信先を、サーバーコンテナのURLに向けます。サーバー側では、GA4のクライアントがイベントを受け、GA4のタグとGoogle広告のコンバージョンのタグが媒体へ送るように設定します。Cookieの識別子をサーバー管理に切り替える場合、既存の識別子から移行する設定を選べば、従来のCookieが消えるまではその値が使われるため、切り替え直後に利用者数が跳ねることを避けられます。Metaへ送る場合は、公式のコンバージョンAPIのタグにピクセルIDとアクセストークンを設定し、ブラウザのピクセルと同じイベントIDを渡して重複を除きます。

サンクスページを複数の媒体で共有している場合、サーバー側で媒体ごとにタグを分ける設計になります。重複と水増しを防ぐ考え方は複数媒体で同じサンクスページを使うときのCV計測｜重複と水増しを防ぐ設定で扱っています。

5. 動作を確認し、導入前の数字と比べる

• 設定直後：サーバーコンテナのプレビューで、ブラウザからの要求が届き、イベントに変換され、各媒体へのタグが発火しているかを見る。応答ヘッダーにCookieが書かれているか、そのドメインとオリジンが想定どおりかをブラウザの開発者ツールで確認する
• Safariで確認：実機のSafariで訪問し、8日後にCookieが残っているかを確認する。サブドメイン方式なら消えているはずで、それが確認できれば経路の見直しに戻る
• 1か月後：管理画面のコンバージョン数と台帳の件数を並べ、計測カバー率が導入前からどれだけ動いたかを見る。「コンバージョンまでの日数」で7日を超える割合が増えていれば、延命が効いている

計測の基盤をタグマネージャーで組む考え方と、サーバーサイドに進む前に整えておく構成は店舗ビジネスのためのGA4×GTM計測設定ガイドで扱っています。

MetaのコンバージョンAPIは、サーバーサイドGTMが無くても入れられる

「MetaのコンバージョンAPIを入れるため」にサーバーコンテナを立てる提案がありますが、順序が逆です。WordPressの公式プラグイン、ECカートの統合機能、コンバージョンAPIゲートウェイは、サーバーサイドGTMを持たずに動きます。GA4やGoogle広告もサーバー経由にする計画がある場合に限り、サーバーコンテナにまとめます。

よくある失敗

サブドメインを向けただけで「ファーストパーティになった」とする

Safariは、応答したサーバーのIPアドレスがサイト本体と大きく異なれば、サーバーから書いたCookieも7日に切り詰めます。サブドメインをCloud Runや外部のホスティングに向けるだけの構成はこれに当たります。延命の効果を目的にするなら、同一オリジンのパス方式か、IPアドレス帯を揃える構成が要ります。

拡張コンバージョンを入れる前に、サーバーサイドGTMに進む

拡張コンバージョンは設定だけで済み、Safariで切れた分の一部をCookie無しで補えます。負荷の低い手段を飛ばすと、サーバーの費用をかけた後に「拡張コンバージョンで足りていた」と分かります。

同意バナーで拒否された分が戻ると期待する

拒否は利用者の選択で、サーバー経由にしても媒体へ送ってよいことにはなりません。同意モードのモデリングで補える分はしきい値次第で、サーバーサイドGTMとは別の話です。

1台で運用し、障害で計測が丸ごと止まる

サーバーコンテナが落ちると、そこを経由する全ての計測が止まります。Googleは最低2台の稼働を推奨しています。1台で費用を抑えた結果、止まっていた期間の数字が全て欠けることがあります。

導入前の数字を残さず、効果を説明できない

管理画面と台帳の差、Safariの比率、コンバージョンまでの日数の分布を導入前に記録していないと、費用に見合ったかを後から判断できません。導入後の件数の増加だけを見ると、問い合わせが増えたのか計測が戻ったのかも区別できません。

媒体へ送る項目を減らせるのに、そのまま全て送る

サーバーコンテナの利点の1つは、送る項目を自社で決められることです。IPアドレスや不要なパラメータをそのまま送っていると、制御の利点を使っていないことになります。プライバシーポリシーの記載と合わせて、送る項目を決めてください。

Cookieの識別子をサーバー管理に切り替え、別サイトとの計測が切れる

複数のドメインをまたいで計測している場合、サーバーから書いたCookieはブラウザのJavaScriptから読めないため、従来のクロスドメインの仕組みがそのままでは動きません。切り替える前に、ドメインをまたぐ導線があるかを確認してください。

よくある質問

代理店から「Cookie規制対応としてサーバーサイドGTMを」と提案されました。入れるべきですか

先に3つを確認してください。サーバーコンテナへの経路をどう作るのか（サブドメインだけならSafariに対する効果は7日で切れます）、自社の管理画面と台帳の差のうちSafariに由来する分がどれだけか、拡張コンバージョンと同意の設計を済ませているか。月の問い合わせが数十件なら、戻る件数は月に数件で、費用と運用に見合わないことがほとんどです。

費用はいくらかかりますか

Googleが推奨するCloud Runの2台構成で月およそ90ドル（1ドル150円で約13,500円）、外部のホスティングなら無料枠が月1万リクエストまで、有料は月17ドルで50万リクエストからです。これに構築の費用と、障害時に対応する担当者の時間が加わります。プレビュー用のサーバーを別に立てるとその分も加わります。

Safariの制限は、サーバーサイドGTMで完全になくなりますか

なくなりません。同一オリジンの経路を用意した場合に、サーバーから書いたCookieが7日の制限を受けなくなります。JavaScriptで書くCookieは従来どおり7日（クリックIDが付いた訪問では24時間）です。サブドメインを外部のサーバーに向けるだけの構成では、サーバーから書いたCookieも7日に切り詰められます。

拡張コンバージョンとサーバーサイドGTMはどちらを先に入れるべきですか

拡張コンバージョンです。フォームで取れる情報があれば設定だけで済み、Safariで切れた分の一部をCookie無しで補えます。それでも残る差に、サーバーサイドGTMを当てます。

Meta広告のコンバージョンAPIもサーバーサイドGTMで送れますか

送れます。Metaはサーバーコンテナ向けのコンバージョンAPIのタグを公式に提供しており、ピクセルIDとアクセストークンを設定して使います。ブラウザのピクセルと同じイベントを両方から送る場合は、同じイベント名と同じイベントIDを渡して重複を除きます。複数媒体へサーバー経由で送りたい会社にとって、これは導入理由の1つになります。

外部のホスティングとCloud Runはどちらがよいですか

月のリクエスト数と、クラウドの管理を自社で行えるかで決めます。月数十万リクエストまでの規模で、クラウドの管理に慣れた担当者がいないなら、外部のホスティングのほうが費用も手間も小さくなります。月100万リクエストを超える規模や、Google Cloudを既に使っている会社は、Cloud Runの台数とログの費用を試算して比べます。どちらでも、同一オリジンの経路の設計は別に要ります。

サーバーサイドGTMを入れれば、プライバシーポリシーの記載は不要になりますか

なりません。自社のサーバーを経由しても、最終的に媒体へ情報を送ることに変わりはなく、外部送信に当たります。送る項目を自社で制御できるようになるため、記載する内容を実態に合わせて整理する機会にはなります。

まとめ

サーバーサイドGTMは、ブラウザから媒体へ直接送っていた計測データを、自社が管理するサーバーコンテナで受けてから送る仕組みです。変わるのは、Cookieを書く主体、送るデータの制御、ブラウザの負荷の3つで、計測の定義や同意の扱いは変わりません。

Safariは、JavaScriptで書いたCookieを7日で消し、クリックIDが付いた訪問では24時間にします。サーバーから書いたCookieはこの対象外ですが、応答したサーバーのIPアドレスがサイト本体と大きく異なれば、サーバーから書いたCookieも7日に切り詰められます。サブドメインを外部のサーバーに向けるだけの構成はこれに当たり、延命の効果を得るには、CDNやロードバランサで同一オリジンの経路を用意する必要があります。

費用は、Googleが推奨するCloud Runの2台構成で月およそ90ドル、外部のホスティングなら月17ドルからです。それで戻る件数は「管理画面と台帳の差」×「Safariの比率」×「クリックから7日を超える割合」で見積もり、月の問い合わせが数十件の会社では月に数件に届きません。戻るのは既に来ている問い合わせであり、問い合わせが増えるわけではありません。

先に済ませるのは、タグの不具合の修正、拡張コンバージョン、同意の設計、必要ならGoogle tag gatewayです。それでも残る差と、Metaなど複数媒体へのサーバー経由の送信、送る項目の制御が必要な会社が、サーバーサイドGTMを検討します。

入れる場合は、導入前の数字を残し、経路を設計し、2台以上でサーバーを用意し、送信先を切り替え、Safariの実機と1か月後の計測カバー率で確認します。障害時に誰が直すかを決めておくことが、月1万円台のサーバー費用より重い条件です。

計測環境の整備と広告運用はWEBマーケティング・広告運用で承っています。同一オリジンの経路の設計を含むサイト側の構成はWEB制作・ホームページ制作と合わせてご相談いただけます。会社紹介資料は資料ダウンロードから、ご相談はお問い合わせからご連絡ください。