
広告費の判断を、計測された獲得件数で行っているためです。
件数が実際より少なく見えると、回せるはずの配信を止めることになります。
なお、TimeValue株式会社では、広告運用・クリエイティブ制作・LP改善・データ分析・AI導入までを一括で引き受けるWebマーケティング支援「KAIZEN」を提供しています。
現在、オンラインの無料マーケティング診断を毎月10社限定で実施中です。いまの数字を見ながら、どこから直すのが早いかを一緒に整理します。
今月の無料診断は残り4社です
広告からLPまで、まとめて見ます。オンラインで30分から対応しています。
目次
目次
- D2Cで計測のずれが事業に直結するのは、なぜなのか
- 見えていない獲得は、評価されない
- いま何が変わったのか
- 変更の一覧
- 同意モードの実装で、何が決まるのか
- 何を制御しているか
- コンバージョンAPIは、何を解決するのか
- 2つの経路の違い
- 定期購入では、何をコンバージョンとして送るのか
- 送る対象の設計
- 実装の順番を、どう決めるか
- 順番の考え方
- 数字が合わないとき、どう切り分けるか
- ずれの原因を分ける
- 何から手をつければいいのか
- 見る数字を決める
- よくある質問
- まとめ
広告費の判断を、計測された獲得件数で行っているためです。
件数が実際より少なく見えると、回せるはずの配信を止めることになります。
D2Cで計測のずれが事業に直結するのは、なぜなのか
広告費の判断を、計測された獲得件数で行っているためです。
件数が実際より少なく見えると、回せるはずの配信を止めることになります。
計測は技術の話に見えますが、実際には予算配分の話です。
見えていない獲得は、評価されない
ブラウザ側で取りこぼした購入は、広告の成果として記録されません。
その媒体のCPAは実際より高く出ます。
結果として、効いている配信から予算を抜くことになります。
自動入札は、送った数字で学習する
いまの配信は自動入札が中心です。
電通デジタルの2025年の数字では、インターネット広告媒体費3兆3,093億円のうち運用型が2兆9,352億円で、構成比88.7%を占めています。
自動入札に渡すデータが欠けていれば、学習の精度がそのまま落ちます。
D2Cでは2回目以降の情報も要る
初回購入だけを送っていると、初回を取りやすい層に最適化されます。それが継続率の低い層であっても、媒体側には分かりません。何を成果として送るかが、集まる顧客を決めます。
いま何が変わったのか
同意の取得状況が、広告データの扱いを直接決める形になりました。
ブラウザ側だけの計測では欠けが出る前提に変わっています。
ここ1年で、計測の前提がいくつも変わりました。
変更の一覧
計測まわりの主な変更
| 変更 | 内容 | 影響 |
|---|---|---|
| GA4の広告データ共有 | 2026年6月15日より同意モードのad_storageのみで可否が決まる | 同意モード未実装だと既定はgranted |
| Googleシグナルの役割 | レポート上のディメンション表示可否のみを制御 | 共有の可否には関与しない |
| Privacy Sandbox | 2025年10月17日に関連技術の大半の終了を発表、CHIPS等一部は存続 | 代替技術を前提にできない |
| LINEヤフーの広告統合 | 2026年4月1日リリース、基盤はYahoo!広告ディスプレイ広告 | LINE広告のみの利用企業はYahoo!計測タグの新規設置が必須 |
| 個人情報保護法 | 改正の動きがあり、施行日は未確定 | 同意の取り方の見直しが必要になる可能性 |
個人情報の取り扱いについては、掲載時点の最新の公式ガイドラインで確認してください。
ブラウザだけの計測は前提から外れた
クッキーの制限が進み、ブラウザ側のタグだけでは購入を追い切れません。
欠けを前提に、別の経路で補う設計に変わっています。
媒体ごとに対応が分かれる
同じ購入を、媒体ごとに違う方法で送ることになります。1か所を直せば全部が直るという構造にはなっていません。
同意モードの実装で、何が決まるのか
広告データを共有できるかどうかが決まります。
未実装のまま放置すると、既定値のまま動き続けます。
同意モードは、同意の状態をタグに伝える仕組みです。
何を制御しているか
同意モードで制御されるもの
| 項目 | 制御するもの | 注意点 |
|---|---|---|
| ad_storage | 広告データの共有可否 | 2026年6月15日以降はこれのみで決まる |
| analytics_storage | 分析用の計測の可否 | 広告データ共有の可否とは別 |
| Googleシグナル | レポート上のディメンション表示可否 | 共有の可否には関与しない |
| 未実装時の扱い | ad_storageの既定はgranted | 意図せず共有状態になっている可能性 |
未実装が、一番判断しにくい状態
実装していなければ既定値で動きます。
同意を取っているつもりでタグに伝わっていない、あるいは伝えているつもりで実装が漏れている。
どちらも管理画面の数字だけでは分かりません。
同意の取り方そのものを確認する
同意を取得する画面の設計と、取得した同意をタグに渡す実装は別の作業です。
片方だけでは成立しません。
取得の要件は、掲載時点の最新の公式ガイドラインで確認してください。
同意率は数字として持つ
同意率が下がれば、送れるデータが減ります。同意率を計測していないと、件数の減少が配信の問題に見えます。
コンバージョンAPIは、何を解決するのか
ブラウザ側で欠けた購入を、サーバー側から送って補います。
ブラウザの制限を受けない経路を、もう1本持つ考え方です。
タグだけで送っていると、取りこぼしがそのまま欠損になります。
2つの経路の違い
ブラウザ経由とサーバー経由の違い
| 観点 | ブラウザ経由のタグ | サーバー経由の送信 |
|---|---|---|
| 影響を受けるもの | クッキー制限、広告ブロック、離脱 | 受けにくい |
| 送れる情報 | 画面上の行動 | 注文データ、後から確定した情報 |
| 重複 | - | イベントIDで重複を除く設計が必要 |
| 実装の負荷 | タグ設置で済む | システム側の改修が必要 |
| 向く場面 | 初期の立ち上げ | 欠けが無視できなくなった段階 |
両方を送って重複を除く
サーバー経由に一本化するのではなく、両方を送ります。
同じ購入が二重に記録されないよう、イベントごとの識別子を揃えます。
ここの設計を飛ばすと、件数が水増しされます。
送れる情報が増える
サーバー側からは、注文確定後の情報も送れます。
キャンセルされた注文を除く、初回と2回目を区別する、購入金額を正確に渡す。
ブラウザ側では難しい処理ができます。
実装後に必ず突き合わせる
送った件数と、受け取られた件数と、自社の注文件数。この3つを並べて確認します。一致しない場合、どの段階で落ちているかを特定します。
定期購入では、何をコンバージョンとして送るのか
初回購入だけではなく、2回目の継続と実際の購入金額を送ります。
送る対象を変えると、集まる顧客が変わります。
D2Cの計測で最も効くのは、送るイベントの選び方です。
送る対象の設計
送るイベントと使い方
| イベント | 送る経路 | 使い方 |
|---|---|---|
| 初回購入 | ブラウザとサーバー | 基本の成果指標 |
| 2回目継続 | サーバー | 継続する顧客に最適化する |
| キャンセル・返品 | サーバー | 成果から除く |
| 購入金額 | 両方 | 金額ベースの入札に使う |
| 解約 | サーバー | 価値の再計算に使う |
| 問い合わせ・資料請求 | ブラウザ | 上流の指標として見る |
初回だけに最適化すると、継続率が落ちる
媒体は、送られた成果を増やす方向に学習します。
初回購入だけを送れば、初回を取りやすい層が集まります。
安さ目当ての層が増え、2回目に残らなくなります。
2回目の継続を送るには時間差がある
2回目の発送は初回から数週間後です。
その時点で送ると、媒体側の学習に使える形で紐づくかを確認する必要があります。
時間差の許容範囲は媒体ごとに異なります。
金額は実額で送る
初回割引の価格ではなく、確定した金額を送ります。割引後の低い金額だけを送ると、価値が低く評価されます。
実装の順番を、どう決めるか
同意モードを先に整え、そのあとでサーバー経由の送信を足します。
順番を逆にすると、送ったデータが使われない状態が起きます。
同時に全部は進みません。
依存関係のある順に進めます。
順番の考え方
実装の順番と理由を、項目ごとに見ていきます。
1については、やることは同意の取得画面と同意モードの実装、先にやる理由はここが未整備だと後工程が無駄になる。
2については、やることは現状の欠損率の測定、先にやる理由はどれだけ補う必要があるか決まる。
3については、やることは主要1媒体のサーバー経由送信、先にやる理由は効果を確認してから広げる。
4については、やることは重複除去の識別子の設計、先にやる理由は二重計上を防ぐ。
5については、やることはキャンセル・返品の除外、先にやる理由は成果の定義を正す。
6については、やることは2回目継続と金額の送信、先にやる理由は集まる顧客の質を変える。
7については、やることは残りの媒体への展開、先にやる理由は型が決まってから広げる。
全媒体を同時に触らない
1媒体で型を作ってから展開します。
同時に変えると、数字が動いた原因を特定できません。
統合や移行の予定を先に確認する
LINEヤフーの広告統合では、LINE広告のみを利用していた企業はYahoo!計測タグの新規設置が必要になりました。
移行ツールの利用にはビジネスIDが要ります。
こうした予定がある媒体は、実装の順番を前に持ってきます。
変更前後の数字を残す
実装の前後で件数が変わります。変更日を記録しておかないと、後から効果を検証できません。
数字が合わないとき、どう切り分けるか
媒体の数字と自社の注文データは、一致しません。
一致させることではなく、ずれ方を一定に保つことを目標にします。
計測を整えた後も、数字は完全には合いません。
ずれの原因を分ける
数字が合わない主な原因を、項目ごとに見ていきます。
アトリビューションの期間については、どちらが多く出るかは媒体側が多い、確認の方法は計測期間の設定を確認。
複数媒体での重複計上については、どちらが多く出るかは媒体側が多い、確認の方法は媒体の合計と実注文を比較。
同意が得られず送れないについては、どちらが多く出るかは媒体側が少ない、確認の方法は同意率を確認。
ブラウザ側の取りこぼしについては、どちらが多く出るかは媒体側が少ない、確認の方法はサーバー経由との差分を確認。
キャンセル・返品の未除外については、どちらが多く出るかは媒体側が多い、確認の方法は除外の実装を確認。
タグの発火漏れについては、どちらが多く出るかは媒体側が少ない、確認の方法はページごとの発火を確認。
合わせようとしすぎない
媒体はクリックやビューから遡って成果を数えます。
自社は注文が入った日で数えます。
定義が違うため、完全には一致しません。
ずれ率を固定して見る
先月は媒体合計が実注文の1.2倍、今月も1.2倍。
数字は説明のための仮の値です。
この比率が安定していれば、判断には使えます。
比率が急に動いたときに、原因を探します。
事業の判断は自社の注文データで行う
媒体の数字は配分の判断に使い、採算の判断は自社のデータで行います。役割を分けると、合わない数字に振り回されなくなります。
何から手をつければいいのか
同意モードの実装状況を確認することからです。
未実装のまま既定値で動いている状態かどうかを、まず把握します。
現状の確認から始めます。
作業に入る前に、どこが欠けているかを特定します。
着手の順番を、項目ごとに見ていきます。
1については、やることは同意モードの実装状況と同意率を確認する、期間の目安は1週間。
2については、やることは媒体の成果件数と自社の注文件数を突き合わせる、期間の目安は1週間。
3については、やることは欠損率を出して補う必要量を決める、期間の目安は1週間。
4については、やることは主要1媒体でサーバー経由の送信を実装する、期間の目安は1か月。
5については、やることはキャンセルと返品を成果から除く、期間の目安は2週間。
6については、やることは2回目継続と購入金額を送る設計に変える、期間の目安は1か月。
見る数字を決める
見る数字を、項目ごとに見ていきます。
同意率については、見る頻度は毎月、目安の考え方は送れるデータ量を決める。
媒体件数と自社注文件数の比率については、見る頻度は毎月、目安の考え方は急な変動を見る。
サーバー経由の送信成功率については、見る頻度は毎月、目安の考え方は落ちていないか。
キャンセル除外後の成果件数については、見る頻度は毎月、目安の考え方は実際の採算に近い数字。
2回目継続の送信件数については、見る頻度は毎月、目安の考え方は学習に渡せているか。
媒体別の継続後CACについては、見る頻度は毎月、目安の考え方は集まる顧客の質が変わったか。
実装の効果は配分で測る
計測を直した効果は、件数ではなく配分の変化に出ます。
これまで低く評価されていた媒体の位置が変わります。
一度で終わらない
媒体の仕様は変わり続けます。
四半期ごとに、送信の状態を点検する工程を置きます。
数字が合わない原因が分からない場合は、無料相談で現状を見てもらうところから始められます。計測の設計ごと見直す段階ならWeb集客改善サービスもあります。
よくある質問
同意モードを実装していないとどうなりますか
ad_storageの既定値はgrantedのため、そのまま動き続けます。GA4では2026年6月15日より広告データ共有の可否がad_storageのみで決まるようになっており、意図と実装がずれていても管理画面の数字だけでは分かりません。
Googleシグナルを有効にすれば広告データは共有されますか
Googleシグナルはレポート上のディメンション表示可否のみを制御します。広告データ共有の可否は同意モードのad_storageで決まります。役割が分かれている点に注意してください。
サーバー経由の送信に一本化すべきですか
ブラウザ経由と両方を送るのが基本です。その際、同じ購入が二重に記録されないよう、イベントごとの識別子を揃える設計が必要になります。ここを飛ばすと件数が水増しされます。
定期購入では何をコンバージョンにすべきですか
初回購入だけを送ると、初回を取りやすい層に最適化され、継続率が下がります。2回目の継続とキャンセル除外後の購入金額を送ると、残る顧客に近い形で学習が進みます。
媒体の成果件数と自社の注文件数が合いません
計測の定義が違うため、完全には一致しません。目標は一致させることではなく、ずれ方を一定に保つことです。比率が急に動いたときに、同意率、タグの発火、キャンセル除外の実装を順に確認してください。
まとめ
- 広告費の判断を、計測された獲得件数で行っているためです。件数が実際より少なく見えると、回せるはずの配信を止めることになります
- 同意の取得状況が、広告データの扱いを直接決める形になりました。ブラウザ側だけの計測では欠けが出る前提に変わっています
- 広告データを共有できるかどうかが決まります。未実装のまま放置すると、既定値のまま動き続けます
- ブラウザ側で欠けた購入を、サーバー側から送って補います。ブラウザの制限を受けない経路を、もう1本持つ考え方です
- 初回購入だけではなく、2回目の継続と実際の購入金額を送ります。送る対象を変えると、集まる顧客が変わります
- 同意モードを先に整え、そのあとでサーバー経由の送信を足します。順番を逆にすると、送ったデータが使われない状態が起きます
- 媒体の数字と自社の注文データは、一致しません。一致させることではなく、ずれ方を一定に保つことを目標にします
- 同意モードの実装状況を確認することからです。未実装のまま既定値で動いている状態かどうかを、まず把握します