3DデータSaaSの計測基盤構築 — SPA環境で正確なCV計測とファネル分析を実現

課題分析と仮説

計測環境を調査した結果、課題を3つの構造的要因に分解しました。

SPAではCV完了を「ページビュー」で捕捉できない

クライアントのサイトはSPAです。SPAはページ遷移時にブラウザの通常のページ読み込み（リロード）が発生せず、JavaScriptで画面だけを書き換えます。このため、標準的なページビュートリガーでは「サンクスページに到達した」というイベントを検知できません。フォーム送信完了をCVとしてカウントしたくても、その瞬間を捕捉する仕組みがない状態でした。

CVが計測できなければファネル分析の起点が作れない

CVが正しくカウントできなければ、その手前のステップ（CTAクリック・フォーム到達）を計測しても、「どこで離脱しているか」を分析できません。最終地点（CV完了）が固定されて初めて、ファネルの各段階の通過率・離脱率が意味を持ちます。

CV種別が複数に分かれ、統合管理しないと分析が煩雑になる

クライアントのサイトには、お問い合わせ・資料ダウンロード・見積り・トライアルという複数のコンバージョン導線があります。これらを別々のイベントとして個別に持つと、フォーム種別をまたいだ比較やファネル分析が煩雑になります。

実施した施策

SPA前提のGTM設計仕様書の作成

実装に着手する前に、SPAを前提としたGTMのタグ・トリガー・変数の設計仕様書を作成しました。

• トリガータイプの選定: ページビュー系ではなく「履歴の変更（History Change）」を採用
• サンクスページ直アクセス・リロード対策: History Changeに加え、DOM Ready（ページビュー）トリガーも併設する設計方針を明記
• 拡張計測との整理: GA4拡張計測（ページビュー・離脱クリック・サイト内検索・ファイルダウンロード等）で十分カバーできる項目はGTM実装を行わず、二重計測を避ける方針を整理

設計仕様書を先に固めることで、実装段階での手戻りを防ぎ、後からの保守・引き継ぎも容易にしました。

キーイベント4種（コンバージョン）の設計と実装

GA4に4つのキーイベント（コンバージョン）を事前作成し、GTMで各CVを計測する仕組みを構築しました。

各CVのトリガーは「履歴の変更」で、Page Pathがサンクスページに一致したときに発火します。generate_lead はGA4推奨イベント名を使用し、残り3種はサイト固有のカスタムイベントとして命名しました。

サンクスページ判定を正規表現で厳密化

SPAのURL遷移を検知する際、類似パスの誤マッチを防ぐため、トリガー条件を正規表現で厳密化しました。

• 条件式: ^/[サンクスページパス](?.*)?$ 形式
• 狙い: パラメータ付きURL（?utm_source=... 等）に対応しつつ、/[完了パス] と /[類似の完了パス] のような類似パスを取り違えないようにする

CVのカウントは数値の信頼性に直結するため、トリガー条件の精度を最優先しました。

複数CVをフォーム種別パラメータで統合管理

複数のCVを別々に管理するのではなく、form_type パラメータ（contact / document_request / quote / trial）で束ねて統合管理する設計にしました。

• メリット1: フォーム種別ごとのCV件数を1つの軸で比較できる
• メリット2: フォーム到達（form_start）と組み合わせれば、種別ごとのフォーム完了率を算出できる
• 拡張性の担保: 資料DLフォームが将来複数URLに増えることを見越し、ルックアップテーブル（LUT）のデフォルト値を document_request に設定。新しいフォームが追加されても計測が漏れない設計にした

エンゲージメントイベントの設定とファネル設計

CV完了の手前のステップを計測するため、2種のエンゲージメントイベントを設定しました。

これにより、「サイト訪問 → CTAクリック → フォーム到達 → CV完了」 のファネルを構成できるようになりました。なお、当初計画にあったスクロール深度（25/50/75/100%）の計測は、全閾値が同時に発火する問題が判明したため削除し、計測ノイズを避けました。設計時の想定と実装時の挙動が異なる箇所を、検証で潰した判断です。

命名規則の統一とGSC連携

保守性を高めるため、GTMのタグ・トリガー・変数名に共通プレフィックスを付与し、命名規則を統一しました。GA4イベント名は日本語が使用不可のため、すべて英語で命名しています。

並行してGSC（Google Search Console）の設定も完了しました。

• プロパティ作成
• 所有権の確認
• サイトマップの送信
• GA4連携

GA4とGSCをセットで整備することで、「検索結果でどう見えているか（GSC）」と「サイトに来てから何をしたか（GA4）」を両面から把握できる状態にしました。

運用ドキュメントの整備とMTG実施

構築で終わらせず、クライアントが自走して数値を読める状態まで伴走しました。

• GA4レポートガイド: 標準レポート・探索レポートで何が見られるか、ファネル探索の作成手順を記載
• 30分MTG資料: GA4とGSCの役割の違い、見るべき画面、分析の進め方を非エンジニア向けに整理
• MTG資料はドキュメント共有環境にエクスポートし、クライアント側でいつでも参照できる状態にした

「計測基盤を作って終わり」ではなく、運用側が数値を意思決定に使えるところまでを支援範囲としています。

Claude Code環境を活用した工数削減・品質向上

計測基盤の構築フェーズでも、設計仕様書・運用ドキュメントの整備とナレッジ連携にソリシオのClaude Code業務基盤を活用しました。設計を先に固め、引き継ぎ資料まで一気通貫で整える土台です。

本案件は計測基盤の構築フェーズのため、定型処理の自動化より「設計・ドキュメントの一気通貫整備」がClaude Code活用の主軸です。実装・検証と最終判断は担当者が行っています。

成果

本案件は計測基盤の構築フェーズ であり、流入数・CV件数・検索順位といった定量成果は今後の運用で蓄積される段階です。現時点では実測値による成果数値は存在しません。本フェーズの成果は、「正確に計測できる状態を作ったこと」そのものの定性価値 にあります。

SPA環境での正確なCV計測を実現

SPAは計測が崩れやすく、CV計測が正しく動かないまま運用されているサイトが少なくありません。本案件ではHistory Changeトリガーを軸に設計し、SPA環境でもサンクスページ到達を確実に検知してCVをカウントできる状態を確立しました。サンクスページ判定を正規表現で厳密化したことで、類似パスの誤カウントも防いでいます。

サイト訪問からCVまでのファネル分析が可能になった

複数のCV（お問い合わせ・資料DL・見積り・トライアル）に加え、CTAクリック・フォーム到達のマイクロコンバージョンを計測する設計により、以下のファネルの各段階で離脱率を可視化できるようになりました。

① サイト訪問
      ↓ 離脱率
② CTAクリック（cta_click）
      ↓ 離脱率
③ フォーム到達（form_start / form_type で種別識別）
      ↓ 離脱率
④ CV完了（generate_lead / document_download / request_quote / sign_up_trial）

「どこで離脱が多いか」を特定できるため、データが蓄積した後はCTAの配置・文言、フォームの改善といった具体的な打ち手につなげられます。施策の効果測定が可能な状態になったことが、本フェーズ最大の成果です。

将来の運用に耐える拡張性を確保

• LUTデフォルト値の設定: 資料DLフォームの複数化を見越したデフォルト値設定により、フォーム追加時も計測漏れが起きない
• 命名規則の統一: 共通プレフィックスにより、後からの保守・引き継ぎが容易
• フォーム種別パラメータでの統合管理: 新しいCV導線が増えても同じ設計思想で拡張できる

構築時点で「将来増えるもの」を想定した設計にしたことで、運用が始まってからの追加実装コストを抑えています。

クライアントが数値を読める状態まで伴走

GA4レポートガイドと30分MTG資料の提供により、非エンジニアの運用担当者でも、流入チャネル・CV件数・ファネル完了率を自分で確認できる状態になりました。計測基盤の価値は「作ったこと」ではなく「使われること」で初めて生まれます。運用ガイドの整備まで含めた伴走が、本事例の支援スタイルです。

数値成果について: 本フェーズは構築が主目的のため、CV件数・流入セッション・検索順位の実測値は今後の運用で蓄積されます。定量成果が出そろった段階で、本セクションに実測値を追記する予定です。

ふり返り・横展開ポイント

再現可能なポイント

本事例の核は 「SPA環境での正確なCV計測設計 × 複数CVの統合管理 × 構築で終わらない運用伴走」 の3点です。SEO記事を1本も書かなくても、計測の土台を整えること自体に明確な価値があることを示した事例です。

必要な前提条件

横展開には以下の前提条件が必要です。

• GA4・GTM・GSCのアクセス権限付与（クライアント側の協力）
• フォーム送信フロー（ページ遷移か、Ajax送信か → サンクスページ遷移）の仕様確認
• サンクスページURL構造の共有（正規表現でのトリガー条件設計に必要）
• 運用担当者がレポートを読む時間の確保（MTG・ガイドの活用）

限界・想定されるリスク

• SPAのプレビュー制約: GTMプレビューではサンクスページのURL変化が検知されないため、CV系トリガーは公開後の実データで最終確認が必要
• フォーム送信方式への依存: フォームがAjax送信かページ遷移かによってトリガー設計が変わる。仕様変更時は再設計が必要
• 定量成果は運用待ち: 本フェーズは構築が主目的のため、流入・CV・順位の成果は今後の運用で蓄積される
• 計測仕様の保守: サイトのURL構造やフォーム導線が変わると、トリガー条件の更新が必要になる