SaaS事業の広告運用で「サインアップCVが Google 広告管理画面とプロダクトDBで合わない」「Free→Paid 転換のアトリビューションが空白になる」という相談が、技術顧問先・問い合わせともに増えている。SaaS マーケティング 計測の問題は、単一タグの不具合ではなく、ITP・拡張機能・サブドメイン遷移・遅延CVという SaaS 業界特有の四層構造で発生するため、表面的なタグ追加では止血できない。本稿では SaaS 業界に絞り、Google タグ ゲートウェイ（GTG）と Conversions API（CAPI）を組み合わせたファーストパーティ実装の全体像を、PLG／Sales-Led 両モデルへの応用まで含めて整理する。
💡 この記事の要点（30秒で）
SaaS のサインアップCVが広告管理画面に届かないのは、ITP・拡張機能・サブドメイン遷移・遅延CVの四層構造が SaaS 業界特有の累積ロスを生むため
ファネルが長く Free→Paid 転換が 14-45 日かかる SaaS では、Cookie 寿命を超える遅延CVの計測が最大のペインになる
Google タグ ゲートウェイ（GTG）で計測タグの配信を自社ドメイン経由化し、Conversions API（CAPI）でサーバーサイド送信を冗長化するのが現時点の業界標準解
PLG モデルでは「サインアップ」より「Activation（初回価値体験）」を主要 CV に据え、Value-based Bidding に重み付けで渡す設計が要
エンタープライズ／Sales-Led SaaS では、Salesforce 等の CRM と CAPI を統合し、SQL／Opportunity／Closed-Won をオフライン CV として広告に送り返す設計が標準
SaaS 業界の広告計測を蝕む3大ペイン
SaaS 事業のマーケ責任者が直面する計測の痛みは、EC や BtoB リード型サイトとは構造が違う。SaaS 業界に固有のペインは大きく3つに分類できる。
ペイン1：ファネルが長く、計測ロスが各段で累積する
広告クリック → LP → サインアップ → メール認証 → トライアル開始 → Activation（初回価値体験） → Paid 転換、と SaaS のファネルは最低でも 7 ステップ。各ステップで一定の割合がトラッキングから脱落するため、最終的に管理画面に届く数字は元の半分程度にまで目減りしている、というケースが珍しくない。EC のような「クリック → 購入」型より、累積ロスのインパクトが構造的に大きい。
ペイン2：サブドメイン構成が複雑で Cookie が分断される
LP は `www.example.com`、サインアップは `app.example.com`、決済は `billing.example.com`、というサブドメイン分割は SaaS では標準的な構成だ。一方、ファーストパーティ Cookie は設定を誤るとサブドメイン跨ぎで意図しない挙動を起こす。さらに iOS Safari の ITP（Intelligent Tracking Prevention） は JavaScript で設定された Cookie を最大 7 日で削除するため、トライアル期間中（14-30 日）の Paid 転換は計測がほぼ消える、という SaaS ならではの落とし穴がある。
ペイン3：ターゲット層の広告ブロッカー利用率が高い
SaaS、特に BtoB SaaS の購買担当者はエンジニア・PM・情シスといった技術リテラシーの高い層が多く、uBlock Origin 等のフィルタリスト型拡張機能や、プライバシー特化ブラウザの利用率がコンシューマ平均より明確に高い。GTM 経由の gtag 送信は、`googletagmanager.com` や `google-analytics.com` がリスト型ブロッカーに登録されているため、ブラウザ側で `Blocked by client` として遮断される。SaaS のターゲット層では、この遮断率が想定より高く出る。
これら3つのペインは、いずれも単発のタグ修正では解消できない。SaaS 業界の構造に踏み込んだ計測基盤の再設計が必要になる、というのが出発点だ。
🏢 CRIEN実証 ── 技術顧問として SaaS スタートアップから上場前後の SaaS 事業者まで複数社の計測基盤を見てきたが、「広告管理画面の CPA が異常に低く見えていて予算配分を誤っていた」というケースは想像以上に多い。広告側に届いていない CV が一定割合存在すると、見かけの CPA は実態より良く見える。SaaS 業界では、まず「計測ロスがどの段でどれくらい発生しているか」を可視化する診断から始めるべきで、いきなりタグの追加に走ると問題の構造を見誤ることが多い、というのが現場感だ。
SaaS 特有の CV フローと、計測ロスが発生する4つの技術要因
SaaS 業界の計測精度を毀損する技術要因を、メカニズムまで分解する。これは EC や BtoB リード型と共通する部分もあるが、SaaS は遅延 CV の比重が大きいため、各要因の影響度が違ってくる。
要因1：ITP による JavaScript 設定 Cookie の 7 日制限
iOS／macOS の Safari は `document.cookie` で JavaScript が設定した Cookie を最大 7 日でクリアする。GA4 の `_ga` Cookie も対象で、サインアップから 7 日以上経過した Activation や Paid 転換は同一ユーザーとして紐付けできない。Chrome も段階的にサードパーティ Cookie 制限を強化しており、SameSite=Lax 前提の実装が前提になる。
要因2：拡張機能によるリクエスト遮断
uBlock Origin 等のフィルタリスト「EasyPrivacy」「Fanboy's Annoyance List」には `googletagmanager.com`、`google-analytics.com`、`facebook.net` といったドメインが登録済みだ。SaaS のターゲット層（技術職）はこれらの拡張機能を入れている比率が高く、ブラウザ側で完全に遮断されるとサーバーログにも到達しない。
要因3：サブドメイン跨ぎでの Client ID 欠落
`www → app` 遷移時、`_ga` Cookie のドメインを `.example.com` に設定していないと、別ユーザー扱いで 2 セッション計上される。SaaS では LP と本体アプリで GTM コンテナを分けがちで、設定ミスがそのまま放置されているケースが多い。
要因4：遅延 CV に対する Cookie 寿命
Free → Paid 転換は SaaS の場合、平均 14-45 日。Cookie 寿命を超えると最後のセッションが「Direct/None」として記録され、初回広告クリックへのアトリビューションが失われる。
これら4要因を統合的に解決するのが Google タグ ゲートウェイ（GTG）＋ Conversions API（CAPI）併用設計だ。GTG は計測タグの配信元を `www.googletagmanager.com` ではなく自社ドメイン（例：`tag.example.com`）に置き換える仕組みで、Cloudflare Workers ／ AWS CloudFront Functions ／ GCP Cloud Run 等のエッジで動かす。CAPI はサーバー側から直接 Google／Meta のコンバージョン API に送信する仕組みで、ブラウザ側の Cookie 状態に依存しない。
両者を組み合わせると、SaaS 業界の4要因に対して以下のような効き方をする。
| 課題 | GTG 単独 | CAPI 単独 | GTG ＋ CAPI 併用 |
|---|---|---|---|
| 拡張機能による遮断 | 回避（自社ドメイン） | 回避（サーバー間） | 二重で回避 |
| ITP 7 日制限 | HttpOnly Cookie で延長 | サーバー Cookie | 完全回避 |
| サブドメイン跨ぎ | 統一管理可 | 影響なし | 完全解決 |
| 遅延 CV（Paid 転換） | △（30日まで） | ◯（user_id 送信） | ◯（冗長化） |
| 実装コスト | 中（エッジ設定） | 高（API 開発） | 中-高 |
SaaS では遅延 CV の比重が大きいため、CAPI 側でユーザー ID を軸にした送信設計を組まないと、Paid 側の計測がそもそも復旧しない。GTG 単独では限界がある、というのが SaaS 業界特有の事情だ。
SaaS での GTG 実装パターン（PLG／Sales-Led 別）
SaaS 業界の GTG 実装は、ビジネスモデルが PLG（Product-Led Growth）か Sales-Led かで設計の重心が変わる。両モデルとも共通するフェーズと、モデル別に分岐するフェーズに整理した。
Phase 1：計測ロス診断（共通／1週間）
広告管理画面の CV 数とプロダクト DB 上のサインアップ・Activation・Paid 数を、過去 90 日分突合する。User-Agent 別、デバイス別、参照元別にロス率を分解し、ITP 起因／拡張機能起因／サブドメイン起因の比率を推定する。SaaS の場合、Activation の定義（初回ログイン／初回データ投入／初回 API 呼び出し等）を関係者間で合意するのもこのフェーズで行う。
Phase 2：CV 設計の再定義（PLG／1週間）
PLG SaaS では、広告プラットフォームに送る CV を「サインアップ」ではなく「Qualified Signup（メール認証済＋業務用ドメイン）」「Activation」「Paid」の 3 段階に分け、それぞれ重み付けする。Google 広告の Value-based Bidding に `signup_value=10, activation_value=40, paid_value=200` のような相対値を渡すと、入札最適化が「Paid に繋がりそうなユーザー」を優先するようになる。
Sales-Led SaaS の場合は、サインアップではなく「デモ申込」「商談化（SQL）」「契約（Closed-Won）」を CV 軸に置き直す。広告側に渡す即時シグナルとしてはデモ申込を使い、SQL と Closed-Won は後段で CRM 経由のオフライン CV として送る。
Phase 3：GTG エッジ環境の構築（共通／1-2週間）
Cloudflare Workers が最も実装が早い。自社ドメイン `tag.example.com` のサブドメインを Workers に向け、`/gtm.js`、`/g/collect`、`/gtag/js` 等のパスを Google サーバーへリバースプロキシする。実装上のポイントは以下。
• `Set-Cookie` ヘッダを HttpOnly + Secure + SameSite=Lax で発行（ITP 回避）
• レスポンスヘッダの `Cache-Control` を `private, max-age=0` に統一
• `X-Forwarded-For` で実 IP 転送、Geo 情報の精度維持
• 全サブドメイン（www, app, billing）で同一 Cookie ドメインを共有
AWS 構成なら CloudFront Functions ＋ Lambda@Edge、GCP なら Cloud Run、さくらクラウドなら Web アクセラレータ ＋ VPS 等、主要インフラいずれにも対応可能だ。
Phase 4：CAPI 実装（共通／2週間、Sales-Led はさらに CRM 連携）
Paid 転換や Activation は、フロント側 JS ではなくサーバー側から直接 Google／Meta API に送信する。SaaS の場合、Stripe・Paddle 等の Webhook をトリガーに、user_id（プロダクト内部 ID）と紐付けた状態で送る。ここで Enhanced Conversions（メールアドレスの SHA-256 ハッシュ）も同時送信すると、Cookie が失効していても CV 帰属が復活する確率が上がる。
Sales-Led SaaS では、Salesforce／HubSpot 等の CRM の SQL／Opportunity／Closed-Won イベントを CAPI で送り返す。ここまで設計して初めて、商談化 6-12 ヶ月後の契約まで広告アトリビューションが繋がる。
Phase 5：dataLayer ＆ GA4 設計（共通／1週間）
`user_id` を GA4 に渡し、Cross-domain・Cross-device の名寄せを有効化。SaaS では「契約プラン」「シート数」「業種」を User Property に持たせると、後続の LTV 分析や ABM 系の広告最適化に効く。
Phase 6：検証 ＆ 本番移行（共通／1週間）
`tagassistant.google.com` でタグ発火確認、`debug_mode` で GA4 にイベント到達確認、Google Ads「診断」で「広告と Conversion Linker のトラフィック」をチェック。ロールアウトは 10% → 50% → 100% の段階リリースを推奨する。
導入の全体像と他ツールとの比較は ファーストパーティ計測ツール比較 、BtoB 特有の論点は BtoBリード計測の精度向上 、GTG の基礎概念は Google タグ ゲートウェイ 概要 も参照されたい。SaaS 個別の事情を踏まえた設計支援は Google タグ ゲートウェイ 導入支援 で受け付けている。
SaaS 事業者が今取り組むべき計測基盤の分水嶺
SaaS 業界は、計測基盤を「サードパーティ Cookie 前提の旧構成のまま放置するか」「ファーストパーティ＋サーバーサイド前提に作り直すか」の分水嶺にいる、と見ている。Chrome のサードパーティ Cookie 制限強化、各 OS のプライバシー保護強化、ターゲット層の拡張機能利用率の高さ、いずれも逆行することはなく、放置している期間が長いほど広告管理画面と実態の乖離は広がる。
CPA が見かけ上「健全」に見えていても、実態は計測ロスが上乗せされた数字であり、その状態で予算配分を最適化しても本質的な改善にはつながらない。SaaS 業界のマーケ責任者がまず取り組むべきは、新しい施策の追加ではなく 「いま広告管理画面に見えている数字が、実態の何割を反映しているのか」を計測ロス診断で把握することだ。これが固まらないと、その後の打ち手がすべて砂上の楼閣になる。
最初の 3 ヶ月でやるべきことを順序立てると、(1) 計測ロス診断と現状の可視化、(2) PLG／Sales-Led いずれのモデルかに応じた CV 設計の再定義、(3) GTG エッジ環境の構築と CAPI 実装、の 3 ステップに集約される。ここまで仕上げると、広告管理画面の数字が実態の DB と概ね一致する状態に乗ってくる。
SaaS 業界に特化した計測基盤の設計・実装は、PLG／Sales-Led のモデル別事情、サブドメイン構成、Stripe／Paddle 等の決済連携、Salesforce／HubSpot 等の CRM 連携、いずれも考慮要素が多い。CRIEN は技術顧問 20 社以上の実績と、自社プロダクトの開発・運用経験を背景に、SaaS 事業者の計測基盤を「まるごとAI顧問」「AI家庭教師」「伴走支援」の組み合わせでサポートしている。社内のマーケ責任者・エンジニアと並走しながら自走化まで支援するスタイルだ。
FAQ（よくある質問）
SaaS 特有の計測課題とは何ですか？
ファネルが長く Free → Paid 転換が 14-45 日と遅延すること、サブドメイン構成（www／app／billing）が複雑なこと、ターゲット層（技術職）の拡張機能利用率が高いことの 3 点が SaaS 業界特有のペインです。結果として広告管理画面に届く CV は実態より目減りし、CPA が過大評価される構造的リスクがあります。GTG ＋ CAPI 併用で計測ロスを圧縮することが、SaaS 業界では標準解になりつつあります。
Free → Paid のアトリビューションはどう設計しますか？
`user_id`（プロダクト内部 ID）を軸に、サインアップ・Activation・Paid の 3 段階に CV イベントを分け、それぞれ Value-based Bidding 用に重み付けします。GA4 のデータドリブンアトリビューションを有効化し、初回広告クリックから Paid 転換まで 30-60 日間追跡できる設計にします。CAPI でオフライン CV も送信し、Cookie が失効した遅延 CV まで広告最適化に反映可能です。
Product-Led Growth での活用は？
PLG では「サインアップ」より「Activation（初回価値体験）」を CV 主軸に据え直すことが核心です。分析 SaaS なら「初回ダッシュボード作成」、コミュニケーション SaaS なら「3 名招待＋初回メッセージ送信」を Activation と定義する、というように事業ごとに具体化します。GA4 と CAPI でこのイベントを広告に送ることで、Paid に繋がりやすいユーザーを入札最適化が優先するようになります。
エンタープライズ／Sales-Led SaaS への応用は？
エンタープライズ SaaS は Sales-Led が主流で、商談化から契約まで 6-12 ヶ月かかります。GTG で初期計測を確保したうえで、Salesforce／HubSpot 等の CRM と CAPI を統合し、SQL／Opportunity／Closed-Won をオフライン CV として広告に送り返す設計が標準です。ABM キャンペーンの計測まで対応するには、CRM 側の項目設計と CAPI 送信スキーマを揃え込む工程が肝になります。
主要インフラ（AWS／GCP／Cloudflare）への対応可否は？
Cloudflare Workers が最短実装、AWS なら CloudFront Functions ＋ Lambda@Edge、GCP なら Cloud Run、さくらクラウドなら Web アクセラレータ ＋ VPS 等、主要インフラいずれでも実装可能です。既存インフラの構成と運用体制に合わせて選定するのが基本で、新たに別インフラを立てる必要はほぼありません。CRIEN は主要インフラの実装パターンを横断的に整理しており、現行構成に乗せる前提で提案できます。
出典・参考
• Google「タグ プラットフォーム」公式ドキュメント
• Google「サーバーサイド タグ設定」公式ドキュメント
• Google タグ マネージャー ヘルプ
• Google アナリティクス（GA4）ヘルプ
• MDN「SameSite cookies」
• Apple WebKit「Tracking Prevention」
