サンクスページがないサイトのCV設定方法｜GTMとGA4で失敗しない完了判定の考え方

サンクスページがなくてもCV設定はできる

CV設定というと、問い合わせ完了後に専用の完了ページへ遷移し、その到達を計測する方法を思い浮かべる方が多いかもしれません。
たしかにこの方法は分かりやすく、設定もしやすいです。

ただ、実務ではサンクスページが用意されていないサイトもかなり多くあります。
フォーム送信後にモーダルで完了表示が出るだけのサイト、外部フォームへ飛ぶサイト、予約ツールに遷移するサイト、Stripeの決済画面へ移動するサイトなど、実装はさまざまです。

このときに迷いやすいのが、どこをCVとして計測すればよいのか、という点です。
先に結論を言うと、サンクスページがなくてもCV設定は可能です。
ただし、適当にボタンのクリックをCVにしてしまうと、完了していない人まで含んでしまい、数字がズレやすくなります。

1) ボタンクリックと完了は同じではない

よくあるのが、送信ボタンや予約ボタンを押した時点でCVとしてしまうケースです。
しかし実際には、その後に入力エラーで止まることもあれば、外部ツール側で離脱することもあります。

つまり、クリックは行動の開始ではあっても、完了とは限りません。
この違いを分けて考えないと、広告評価もGA4のCV数も甘く見えやすくなります。

2) まず決めるべきは 何をCVと呼ぶか

サンクスページがないときほど、最初にCV定義を決めることが大事です。
何をもって成果とするのかを曖昧にしたまま設定すると、後から説明がつかなくなります。

問い合わせ送信成功をCVにするのか、予約ツールへの遷移をCVにするのか、Stripeの決済画面到達をCVにするのか。
ここはサイトの目的や実際の運用フローに合わせて決める必要があります。

完了判定の代表パターン

サンクスページがない場合でも、完了したと判断できるポイントは意外とあります。
代表的なパターンを順番に見ていきます。

1) モーダルや完了メッセージの表示で判定する

フォーム送信後に、ページ遷移せず同一画面内で送信完了メッセージやモーダルが表示されるタイプです。
この場合は、完了時にだけ表示される要素を条件にしてCVを計測します。

たとえば、送信ありがとうございました という文言が表示されたとき、完了モーダルが開いたとき、完了用のclassが付与されたときなどが判定ポイントになります。
実装によってはGTMの要素表示やカスタムイベントで対応します。

2) 外部フォームへの送信成功をイベントで受ける

HubSpot、formrun、各種SaaSフォームなど、入力自体は自サイト上でも、送信判定は外部側で管理されているケースがあります。
この場合、完了ページがないことも多く、見た目だけでは判定しにくいことがあります。

そのときは、フォーム送信成功時に発火するイベントやコールバック、dataLayer連携の有無を確認します。
見た目のクリックではなく、送信成功の信号が取れるなら、そちらを優先した方が正確です。

3) 予約ツールへの遷移を中間CVとして扱う

店舗予約や面談予約では、自サイトから外部の予約ツールへ移動する形がよくあります。
この場合、自サイト側だけでは最終予約完了まで追えないことがあります。

そのときは、予約ツール遷移を中間CVとして計測する方法があります。
ただし、これは予約完了そのものではありません。
あくまで予約意向が高い遷移として扱うのか、正式なCVとするのかは、レポート上で分けて考える必要があります。

4) Stripe遷移は 決済開始 と 購入完了 を分ける

Stripeを使っている場合も、よく誤解が起きます。
商品ページからStripeの決済画面へ遷移しただけでは、まだ購入完了ではありません。
入力途中で離脱する人もいるためです。

そのため、Stripe遷移は決済開始として別イベントで持ち、購入完了は決済完了後の戻り先ページやサーバー側の完了通知で計測する方が整理しやすいです。
この分け方をしておくと、途中離脱の把握や広告評価がしやすくなります。

5) 最もおすすめなのは dataLayerで完了を渡す方法

実務で一番安定しやすいのは、フォームやシステム側で送信成功時にdataLayerへ完了イベントを渡してもらう方法です。
これなら見た目の変化や文言の変更に左右されにくく、GTMでも条件を明確にできます。

サイト改修が可能なら、送信成功時や購入完了時に専用イベントをpushする設計にしておくと、後々の保守もかなり楽になります。

やりがちな設定ミス

サンクスページがない案件では、設定できないことより、設定の仕方を間違えることの方が多いです。
特に次のようなパターンは注意が必要です。

1) クリックだけでCVにしてしまう

もっとも多いのがこれです。
ボタンが押された事実だけを見て、完了とみなしてしまうケースです。

もちろん、どうしても完了信号が取れない場合に、中間CVとしてクリックを置くことはあります。
ただしその場合は、問い合わせ完了や購入完了とは別物として扱うべきです。

2) 同じ意味のCVを複数回送ってしまう

完了メッセージ表示でも送る、クリックでも送る、ページ読み込みでも送る、という形で同じ成果を重複計測してしまうことがあります。
こうなるとCV数が膨らみ、媒体側の最適化にも悪影響が出ることがあります。

1つの成果に対して、原則として主判定は1つに絞る方が安全です。

3) 外部ツール遷移を本CVとみなしてしまう

予約ツールや決済画面への遷移は、確かに強い行動です。
ただし、本当に完了したかまでは分からない場合があります。

実務では、遷移と完了を分けておかないと、あとで成約率や離脱率の話が噛み合わなくなります。

4) レポート上で定義を書いていない

意外と見落とされるのがここです。
自分の中では決済開始をCVとして見ているつもりでも、上司やクライアントは購入完了だと思っていることがあります。

そのため、GA4やLooker Studioでは、何をCVとして数えているのかを注記しておくと認識違いを防ぎやすくなります。

実務で失敗しにくい進め方

サンクスページがないサイトでは、いきなり設定に入るより、先に判定方法を整理した方がうまくいきます。
現場では次の順番で進めると比較的スムーズです。

手順1：サイトの導線を図にして 完了地点を整理する

まずは、ユーザーがどこからどこへ進み、どこで完了になるのかを整理します。
フォーム入力完了なのか、外部ツール遷移なのか、予約確定なのか、決済成功なのか。
ここが曖昧だと、設定条件も曖昧になります。

手順2：自サイト内で取れる信号を確認する

次に、自サイト側で何が取れるかを見ます。
完了文言、モーダル表示、特定要素の出現、JavaScriptイベント、dataLayer、外部リンク遷移など、取れる信号は案件ごとに異なります。

サンクスページがないから無理、と決めつけず、まずは完了後の挙動を観察することが大事です。

手順3：本CVと中間CVを分ける

ここがとても重要です。
完了が取れるなら本CV、完了が取れず一歩手前までしか見えないなら中間CVとして分けます。

この分け方をしておくと、広告運用でも月次レポートでも数字の意味が整理しやすくなります。

• ● 本CV ＝ 問い合わせ送信成功、購入完了、予約完了など
• ● 中間CV ＝ 予約ツール遷移、決済開始、電話クリックなど

手順4：GTMとGA4だけで無理なら 実装側の協力をもらう

見た目の変化だけではどうしても安定判定できない案件もあります。
その場合は、フロント実装やフォーム側にdataLayer連携を入れてもらう方が早いことがあります。

無理にGTMだけで頑張るより、システム側と連携して完了信号を出してもらった方が、長期的には保守しやすく、誤計測も減ります。

手順5：設定後は必ずテストして 意味まで確認する

イベントが飛んだかどうかだけでは不十分です。
そのイベントが、どの行動を指しているのかまで確認してください。

特に、送信失敗でも発火していないか、モーダルを閉じただけで発火しないか、読み込み直しで再発火しないかは要チェックです。
CV設定は、飛んだら終わりではなく、正しい意味で飛んでいるかが大切です。

まとめ：大事なのは完了したと断定できる条件を決めること

サンクスページがないサイトでも、CV設定は十分可能です。
モーダル表示、完了メッセージ、dataLayer、外部ツール連携、決済完了後の戻り先など、判定方法はいくつもあります。

ただし、送信ボタンクリックや外部遷移だけをそのままCVにしてしまうと、完了していない人まで含みやすくなります。
そのため、まずは何を本当の成果とするのかを決め、そのうえで本CVと中間CVを分けて設計するのが実務ではおすすめです。

もし見た目だけでは完了判定が難しい場合は、GTMだけで無理に完結させようとせず、実装側で完了イベントを渡す設計まで含めて考えた方が安定します。
大事なのは、サンクスページの有無ではなく、完了したと断定できる条件を持てているかです。