BtoB SaaSの広告計測を立て直す｜同意モードとCV APIの実装順

なお、TimeValue株式会社では、広告運用・クリエイティブ制作・LP改善・データ分析・AI導入までを一括で引き受けるWebマーケティング支援「KAIZEN」を提供しています。

現在、オンラインの無料マーケティング診断を毎月10社限定で実施中です。いまの数字を見ながら、どこから直すのが早いかを一緒に整理します。

今月の無料診断は残り4社です

無料マーケ診断を申し込む

広告からLPまで、まとめて見ます。オンラインで30分から対応しています。

BtoB SaaSで計測が壊れやすいのは、なぜか

広告の数字と社内の数字が合わないという相談が増えています。

つながらない理由

計測が途切れる場所

運用型が大半を占める

電通デジタルの2025年の詳細分析では、インターネット広告媒体費3兆3,093億円のうち運用型が2兆9,352億円で、構成比88.7%です。
運用型は自動入札で配信が決まります。
入札の元になるデータが欠けると、配信の精度が直接落ちます。

欠けたデータは、配信の質に跳ね返る

計測が欠けると、媒体は成果が出ていないと判断します。
その結果、本来成果の出る層への配信が減ります。
レポートの数字が合わないという問題ではなく、成果そのものが落ちます。

計測の欠けが招くこと

同意モードで何が変わったのか

前提が変わったことを知らないまま運用しているケースがあります。

変更の内容

何が何を決めるか

未実装でも動くが、設計としては不安定

同意モードを実装していない場合、ad_storageはgrantedが既定です。
そのため、実装していなくても当面は動いているように見えます。
ただし同意管理の仕組みを入れた時点で挙動が変わります。

同意の取得率が、そのままデータ量になる

同意バナーの設計によって、同意の取得率は変わります。
取得率が下がれば、広告に送れるデータが減ります。

同意取得率とデータ量の関係

数字は説明のための仮の値です。

プライバシーの前提は動いている

サーバー側でのCV送信は、何を解決するのか

ブラウザ側のタグだけでは、送れない場面が増えています。

何が解決するか

ブラウザ側とサーバー側の違いを、項目ごとに見ていきます。
広告ブロックの影響については、ブラウザ側のタグは受ける、サーバー側での送信は受けにくい。
クッキーの制限については、ブラウザ側のタグは受ける、サーバー側での送信は受けにくい。
別端末での成約については、ブラウザ側のタグはつながらない、サーバー側での送信は識別子があればつながる。
送れるタイミングについては、ブラウザ側のタグはその場のみ、サーバー側での送信は後日でも送れる。
実装の負担については、ブラウザ側のタグは軽い、サーバー側での送信は開発が必要。
同意の扱いについては、ブラウザ側のタグは同意管理と連動、サーバー側での送信は同意の確認を自前で実装する必要がある。

同意の扱いは、サーバー側でも必要

サーバー側から送れば同意が不要になるわけではありません。
同意が得られていないデータを送らない仕組みを、自前で作る必要があります。

BtoB SaaSでは、後日送れることが効く

商談から受注まで数か月かかります。
ブラウザ側のタグでは、そのタイミングで送る手段がありません。
サーバー側なら、受注が決まった時点で送れます。

送るタイミングと、送れる内容を、項目ごとに見ていきます。
フォーム送信時については、送る内容はリード獲得、方法はブラウザ側またはサーバー側。
MQL判定時については、送る内容は質の情報、方法はサーバー側。
商談設定時については、送る内容は商談化、方法はサーバー側。
受注時については、送る内容は受注と金額、方法はサーバー側。

識別子を持っておく

商談から受注までの数字を、どう媒体に戻すのか

BtoB SaaSで最も効く計測の打ち手が、これです。

戻さないと、件数に最適化される

フォーム送信だけを送っていると、媒体はフォーム送信が増える方向に配信します。
その結果、商談にならないリードが増えます。
リードの質が悪いという相談の多くが、この構造から来ています。

送る指標と、配信の寄り方を、項目ごとに見ていきます。
フォーム送信のみについては、配信が寄る先はフォームを送りやすい層。
フォーム送信とMQLについては、配信が寄る先は条件を満たす層。
フォーム送信と受注については、配信が寄る先は受注しやすい層。
受注のみについては、配信が寄る先は件数不足で学習が回らないことがある。

件数が足りない場合の組み合わせ

受注件数が月に数件しかない場合、それだけでは学習が回りません。
上流の指標を主軸にし、下流の指標を価値として補正する形を取ります。

指標の組み合わせ例を、項目ごとに見ていきます。
フォーム送信については、役割は学習の主軸、月あたりの件数の目安は30件以上。
MQLについては、役割は質の補正、月あたりの件数の目安は10件以上。
受注と受注金額については、役割は価値の補正、月あたりの件数の目安は数件でも送る。

数字は説明のための仮の値です。

戻す運用を、誰が回すかを決める

受注データを戻す運用を、項目ごとに見ていきます。
渡す形式については、例はクリックの識別子または照合用の情報。
渡す頻度については、例は週次。
渡す範囲については、例はMQL判定、商談化、受注、受注金額。
社内の担当については、例はマーケティング担当。
実装と取り込みの担当については、例は開発または代理店。
失敗時の検知については、例は取り込み件数を週次で確認する。

時間差を前提に設計する

実装の順番はどうするのか

順番を誤ると、実装のやり直しが発生します。

順番

実装の順番を、項目ごとに見ていきます。
1については、やることは現状の計測の棚卸し、なぜこの順番かは何が壊れているかを把握する。
2については、やることは同意管理の設計と実装、なぜこの順番かはデータの前提が決まる。
3については、やることはサーバー側でのCV送信、なぜこの順番かは取りこぼしを減らす。
4については、やることは識別子の保存設計、なぜこの順番かは後日送信の土台になる。
5については、やることはMQLと商談化の連携、なぜこの順番かは質の情報を戻す。
6については、やることは受注と金額の連携、なぜこの順番かは価値の情報を戻す。
7については、やることはGA4のレポート設計、なぜこの順番かは判断できる形に整える。
8については、やることは異常検知の仕組み、なぜこの順番かは壊れたときに気づく。

棚卸しで確認すること

現状の確認項目を、項目ごとに見ていきます。
CVタグの設置箇所については、見方は漏れと重複がないか。
広告の数字と社内の数字の差については、見方はどれくらい乖離しているか。
同意管理の実装状況については、見方はad_storageがどう制御されているか。
参照元の引き継ぎについては、見方は別ドメインをまたぐ箇所。
識別子の保存については、見方はフォーム送信時に保存しているか。
MAツールとSFAの連携については、見方は受注情報がどこにあるか。

一度に全部やらない

同意モードだけを先に入れて、数字の変化を確認します。
複数を同時に変えると、どの変更が何を動かしたか分からなくなります。

変更の前後で、数字を記録しておく

計測が直ると、何が変わるのか

計測は報告のための作業だと思われがちです。

変わること

計測が直ると変わることを、項目ごとに見ていきます。
自動入札の判断については、内容は受注しやすい層に配信が寄る。
媒体間の配分については、内容は受注率で比較できるようになる。
代理店との議論については、内容はCPAではなくCACで話せる。
経営への報告については、内容は回収期間を数字で示せる。
除外の判断については、内容は成果の出ない層を根拠を持って外せる。

代理店への不満が、ここで減ることがある

代理店への不満で経営層の最多は、費用が成果に見合わないで56.3%という調査があります。
これは多くの場合、CPAだけで報告されていることから来ています。
受注データが戻っていれば、CACで報告できます。

効果が出るまでには時間がかかる

受注データを戻してから、自動入札の学習が変わるまでには時間が必要です。
さらに、その配信から受注が出るまでに数か月かかります。

効果が見え始める時期の目安を、項目ごとに見ていきます。
実装直後については、見える変化は計測できるCV数が増える。
1か月については、見える変化は配信先の傾向が変わる。
2か月から3か月については、見える変化はMQL率と商談化率が動く。
4か月以降については、見える変化は受注率とCACが動く。

数字は説明のための仮の値です。

直った状態を維持する仕組みが要る

よくある誤解は何か

優先順位を誤ると、実装が後回しになります。

誤解と、実際に起きること

誤解と実際を、項目ごとに見ていきます。
計測はレポート用の作業については、実際に起きることは自動入札の精度が落ち、成果が下がる。
同意モードは未実装でも問題ないについては、実際に起きることは同意管理を入れた時点で挙動が変わる。
サーバー側から送れば同意は不要については、実際に起きることは同意の確認を自前で実装する必要がある。
受注件数が少ないから戻す意味がないについては、実際に起きることは価値の補正として少数でも効く。
広告の数字と社内の数字は合うはずについては、実際に起きることは集計の定義と期間が違うため完全には一致しない。
一度実装すれば終わりについては、実際に起きることは改修や更新で壊れるため監視が要る。

数字が完全に一致しない理由

広告の数字と社内の数字がずれる理由を、項目ごとに見ていきます。
計上の時期については、内容は媒体はクリック日、社内は発生日で数える。
重複の扱いについては、内容は同じ企業の複数リードの数え方が違う。
除外の基準については、内容はテストや社内アクセスの除外範囲が違う。
計測の取りこぼしについては、内容は同意やブロックで一部が送られない。

完全な一致を目指すより、乖離の幅を把握して安定させるほうが実用的です。

外部に任せる場合の確認事項

何から手をつければいいのか

土台から順に積みます。

着手の順番を、項目ごとに見ていきます。
1については、やることは現状の計測を棚卸しする、期間の目安は2週間。
2については、やることは広告の数字と社内の数字の乖離幅を記録する、期間の目安は1週間。
3については、やることは同意管理を設計して実装する、期間の目安は1か月。
4については、やることはサーバー側でのCV送信を実装する、期間の目安は1か月。
5については、やることはフォーム送信時に識別子を保存する、期間の目安は2週間。
6については、やることはMQLと商談化の連携を作る、期間の目安は1か月。
7については、やることは受注と金額の連携を作る、期間の目安は1か月。
8については、やることは週次で異常を検知する仕組みを作る、期間の目安は2週間。

見る数字を決める

見る数字を、項目ごとに見ていきます。
媒体別のCV数については、見る頻度は毎週、目安の考え方は急な変動がないか。
広告と社内の数字の乖離幅については、見る頻度は毎月、目安の考え方は幅が安定しているか。
同意の取得率については、見る頻度は毎月、目安の考え方はデータ量に直結する。
媒体に戻した受注件数については、見る頻度は毎月、目安の考え方は運用が回っているか。
MQL率と商談化率については、見る頻度は毎月、目安の考え方は質が動いたか。
媒体別の受注率については、見る頻度は四半期、目安の考え方は配分の根拠にする。
CACについては、見る頻度は毎月、目安の考え方は広告費以外も含めて計算する。

数字は説明のための仮の値です。

一度に全部を変えない

同意モードだけを入れて数字の変化を確認し、次にサーバー側の送信を入れます。
同時に変えると、原因の切り分けができません。

壊れたことに気づける形にする

計測は改修や更新で壊れます。
週次でCV数を見て、前週と大きく違えば調べる。
この程度の仕組みでも、放置期間を大きく短縮できます。

よくある質問

まとめ