広告のCVと実際の受注数が合わない｜計測と実数を分ける設計
文・編集：ワークデイズ合同会社
広告の管理画面には「コンバージョン 40件」——申込や購入といった、Web上のゴールの数です——と出ている。けれど受注台帳を数えると、そんなに無い。この食い違いに気づいて、原因を探し始めた——という話をよく聞きます。
結論から言うと、探し始める前に決めておくことがあります。何を「実数」とするかです。広告媒体やGoogleアナリティクスが出す数字は、あくまで計測であって実数ではありません。両者は合わないのがふつうで、合わせにいくものでもない。私たちは、ズレを見つけてから調べるのではなく、はじめから実数の側を正として設計しています。
この記事では、その考え方と、Web上のゴールとお金が発生する地点がつながらないときに何をするかを書きます。まず、なぜいま計測の設計から始めるのかに触れ、そのあとで考え方の中身に入ります。
なぜ、いま計測の設計から始めるのか
細かく計測する目的が、この数年で変わりました。
以前は、媒体の自動入札に学習させるためでした。媒体のアルゴリズムに良質なデータを渡すと、配信の精度が上がる。目的はそこで完結していました。
いまは、AIでこれまでできなかった分析をするためです。クリックした時間、そのクリエイティブ、そのキーワード、見たページ。カートだけでなくフォームも。一つひとつのトラッキングを細かく紐づけておくと、手作業では現実的でなかった分析まで、AIを使って回せるようになりました。
実際に見えたことを1つ挙げます。時間帯によって、獲得したお客様のLTV（顧客生涯価値＝一人のお客様が取引を通じて生む売上）が違いました。粒度を上げていなければ、この差は平均に埋もれたままでした。
速さも変わりました。大量のパターンから共通点を見つけ、仮説を立て、テストして確かめる。この一周が、ものすごく速くなりました。
クリエイティブを一本ずつ機械が読める形に分解して比べる進め方は、広告クリエイティブをAIで分析するに書きました。
ただし、土台は変わりません。 何を実数とするかが決まっていなければ、粒度をどれだけ上げても、積み上がるのは精度の低い数字です。ここから先は、その土台の話になります。
広告の管理画面の数字は、計測であって実数ではない
まず言葉を分けます。
- 計測＝広告媒体やGoogleアナリティクスが、タグ（サイトに埋め込む、訪問者の動きを数えるための短いプログラム）を通して数えた数字。
- 実数＝実際に起きたことの数。
タグは、いろいろな理由でズレます。複数の媒体が同じ1件を取り合う。クリックした人とページを見ただけの人を、媒体ごとに違う数え方で足す。ブラウザの制限でそもそも記録が届かない。原因を挙げていけばきりがありません。
大事なのは、原因の一覧ではなく、実数の側には必ず元になる実体があるということです。問い合わせなら、フォームから実際に届いた連絡の数。受注なら、受注の数。サービスの決済なら、決済の数と金額。どれも、タグとは関係なく存在します。
計測が疑わしいとき、比べる相手はこの実体です。
「何を正とするか」は、案件ごとに違う
「コンバージョンとは何か」に、全社共通の正解はありません。事業の形で変わります。
| 事業の形 | 何を実数とするか | 元になる実体 |
|---|---|---|
| 通販・EC | カートの購入 | 注文データ・決済の数と金額 |
| BtoB（問い合わせ型） | 問い合わせが届いた数／商談／受注 | フォームに届いた連絡・商談の記録・受注 |
| 予約型（店舗・サービス） | 来店・実施 | 予約台帳と、実際に来られたかの記録 |
同じ「コンバージョン1件」でも、通販の1件と、BtoBの1件では、指しているものが違います。だから新しい案件に入るとき、私たちが最初に確かめるのは、タグの設定ではありません。この事業は、どこでお金が発生するのか。そして、Web上のどの行動をゴールとして数えているのか。この2つです。
なお、1件あたりの価値も枠によって変わります。CVの先まで見て予算配分を変える話は目標CPAを一律にするなに書きました。この記事は、その手前——そもそも何を1件として数えるか——の話です。
「ズレたら調べる」ではありません
私たちは閾値を置いていません。必ずズレるので、そもそもタグの数字を信用していません。ここが、この記事でいちばん伝えたいところです。
よく聞かれます。「どのくらいズレていたら、おかしいと見て調べ始めますか」。
この問いには、前提の取り違えがあります。1件でもズレていれば、ズレている。おかしいと思うかどうかではなく、ズレるものだという前提に立って、タグ計測ではなく実数計測のほうを正としています。
だから私たちは、案件に入って最初にタグを見ません。先に、受注や決済がどこに記録されているかを見ます。タグの設定を確かめるのは、正とする実数が決まってからです。順番が逆になると、タグの数字を基準に「合っている・合っていない」を判断することになり、そもそも信用していないはずのものを物差しにしてしまいます。
これは細かい言葉の違いに見えて、実務ではかなり効きます。閾値を置くと、「この範囲なら大丈夫」という判断が生まれ、タグの数字を使い続けることになります。最初から実数を正としておけば、その迷いが発生しません。
Web上のゴールと、お金が発生する地点がつながらないとき
問題は、Web上のゴールとお金が発生する地点が、いつも直結するとは限らないことです。
- 予約 ≠ 来店。予約は入ったが、来られなかった。
- 問い合わせ ≠ アポイント。連絡は来たが、商談にならなかった。
このとき、媒体から見れば「来店しなかった予約」も「来店した予約」も、同じ1件です。返さないかぎり、媒体は両者を区別できません。私たちは、これを放置すると、来ない予約を増やす方向へ最適化が進むと見ています。
だから設計は、Web上のゴールで終わりません。来店した・商談になった・受注したという後工程の結果を、もう一度媒体に返すところまでを含みます。これがオフラインコンバージョンと呼ばれるものです。
返すには、クリックの時点で拾っていないと間に合わない
ここに、後から取り返せない部分があります。
受注データと広告のクリックを突き合わせるには、両者を同じお客様だと判別する目印が要ります。Google広告ならGCLID（広告のクリックごとに付く識別子）です。広告から来られた方がフォームを送る時点でこの識別子を一緒に受け取り、顧客の情報と並べて保存しておく——計測の設計では、ここを最初に押さえます（参照＝GCLID を使用してオフライン コンバージョンを設定する）。
クリックの時点で拾っていなければ、後から作ることはできません。
この抜けは、そのまま損になります。拾っていなかった期間、広告はずっと不正確な成果をもとに配信され続けます。「受注が固まってから、まとめて突き合わせよう」が間に合わないのは、このためです。計測の設計を広告の出稿より先に置く理由も、ここにあります。
ここから先の3段落は、実装に近い話です。仕組みまで関心がなければ、次の見出しへ進んでも筋は通ります。
アップロードには期限もあります。クリックからコンバージョンまでの期間は、データソースに応じて14日または90日未満に収まっている必要があります。
目印はGCLID一択ではありません。ハッシュ化したメールアドレスや電話番号でも突き合わせられます。ただし精度を最大限に高めるなら、可能な限りGCLIDを含めるのが基本です（参照＝リードの拡張コンバージョンについて）。
なお、インポートの経路は変わります。2026年6月15日以降、オフラインコンバージョンのインポートとリードの拡張コンバージョンのアップロードはData Manager APIへ移行し、Google Ads APIではブロックされます（参照＝オフライン コンバージョンのインポートについて）。これはAPIで直結させている場合の話です。スプレッドシートからのアップロードは、いまも公式の方法として案内されています。手順を調べるときは、情報の日付を必ず見てください。
CRMツールとの連携が第一、無ければスプレッドシート
やり方は複数あります。順番に挙げます。
いちばん良いのは、CRMツール（顧客管理のツール）とGoogle広告を連携させることです。受注や商談の更新が、そのまま広告側へ流れます。
ただ、中小企業では連携できるCRMツールを入れていないことも多い。その場合でも、別の対応方法があります。スプレッドシートから連携する形です。問い合わせやCVをスプレッドシートへ自動で出力しておき、その同じ表に、受注・アポイント・面談といった後工程の結果を足していきます。
Googleスプレッドシートからのアップロードも、スケジュールを設定した定期アップロードも、通常の手段として使えます（参照＝ファイル（従来版）を使用してコンバージョンをインポートする）。表が1枚あれば始められる、というのがここでの要点です。ツールを買う判断を待たなくてよい。
明日からできること
順番があります。上から詰めてください。
- お金が発生する地点を書き出す。受注か、決済か、来店か。事業として何が起きたら売上になるのかを、一文で書きます。
- その実数が、いまどこに記録されているかを確かめる。受注台帳、フォームの受信箱、決済の管理画面。誰が見ているか、どんな形で残っているかまで見ます。
- 広告の管理画面の数字と並べてみる。合わせにいく必要はありません。どちらを正とするかを決めるためです。
- ズレが構造的なものなら、返す設計を考える。予約と来店、問い合わせとアポイントが離れているなら、後工程の結果を媒体へ返す。そのためにクリックの識別子を拾うところから始めます。
1から3までは、ツールを入れなくてもできます。4だけは、始めた日から先の分しか取り返せません。だから、いまやるかどうかで差がつきます。
まとめ
広告の管理画面の数字と実際の受注数が合わないのは、不具合ではなく前提です。計測と実数は別のものだからです。
やるべきことは、ズレを見つけて原因を探すことではありません。何を実数とするかを先に決め、その実数の側を正として設計することです。何を正とするかは、事業の形で変わります。
そして、Web上のゴールとお金が発生する地点が離れているなら、後工程の結果を媒体へ返すところまでが設計に入ります。そこには、クリックの時点で識別子を拾っていないと間に合わない、という時間の制約があります。AIで細かく分析できるようになったぶん、土台がずれていたときの影響も大きくなったと考えています。広告を出す前に決めておく理由は、ここにあります。