広告の購入計測が取れているか確かめる手順｜「イベントが無い」と判断する前に見る3か所
広告の購入計測が取れているか確かめる手順｜「イベントが無い」と判断する前に見る3か所
広告の管理画面を開いて「購入が計測されていない」と感じたとき、最初にやるべきことは設定を触ることではありません。自分の観測が正しいかを確かめることです。
広告の計測が壊れているように見えるケースを実際に調べると、かなりの割合が「壊れていない」という結論になります。管理画面の表が途中で切れていて、あるはずの行や列を見ていなかった、というだけの話です。にもかかわらず、そこで「計測に穴がある」と判断してしまうと、配信を止める・タグを入れ直す・別のツールを追加するといった、本来不要な作業が動き出します。しかも直した気になるので、本当の原因は残ったままになります。
この記事では、購入計測が取れているかを確かめる順番を3ステップで示し、そのうえで「本当に壊れていた場合」に何が起きているのかを、実際のECサイトと店舗サイトの調査例から整理します。
結論：判断の前に、この3か所を順番に見る
順番に意味があります。上から順に、コストが低く・誤りを潰せる確率が高い順に並んでいます。
① イベント一覧を「最後の行まで」見る
Metaのイベントマネージャや、GA4のイベント一覧は、画面内に収まっているように見えても下に行が続いていることがあります。ページ全体はスクロールできるのに、表の中だけは別枠でスクロールする、という作りは珍しくありません。マウスホイールが効かず、「ここが末尾だ」と錯覚します。
確認方法は単純で、表の行数を数えることです。 「スクロールしたつもり」は根拠になりません。実際に、あるECサイトのピクセルを調査した際、イベントは7行あったのに5行目までしか表示されておらず、6行目の「支払い情報の追加 171件」と7行目の「購入 78件」が見えていませんでした。購入イベントは正常に受信されており、マッチ品質も8.7/10と良好でした。表を最後まで見るだけで、この調査は5分で終わっていたはずのものです。
② 表の「列」を絞って、金額とROASの列を出す
次に多いのが横方向の見落としです。広告マネージャの表は列が多く、横スクロールが効きにくい領域があります。数回ドラッグして諦めると、「金額が渡っていない」「ROASの列が空だ」という誤った結論が出ます。
Metaの広告マネージャは、URLに直接 columns= を指定して表示列を絞れます。
https://adsmanager.facebook.com/adsmanager/manage/campaigns
?act=<アカウントID>&business_id=<ビジネスID>
&columns=name%2Cspend%2Cresults%2Cresult_values%2Cresult_roas
&date=2026-07-18_2026-08-16列を4〜5個に絞れば横スクロールが不要になり、見落としが物理的に起きなくなります。同じECサイトでこの方法を使ったところ、消化金額14,224円に対して結果の値103,565円・ROAS 7.28倍が正常に出ていました。「値が渡っていない」は誤りだったわけです。
なお、媒体が用意しているプリセットのレポートビュー（ROASレポートなど）は、フィルタも列も自動で決まってしまうため、切り分け作業には向きません。自分で列を指定した素の表を正とするのが確実です。
③ 自分で1件発火させて、基準点を打つ
ここまで見ても「最終受信が27日前になっている」など、受信が止まっているように見えることがあります。このときに設定を疑い始めると時間がかかります。自分で1件イベントを発生させるのが最短です。
同じ調査では、テスト用にチェックアウト開始を1件だけ意図的に発火させたところ、「最終受信27日前」の表示が「1時間前」に変わりました。これで「媒体側の取り込みが止まっている」のか「単に直近の実データがなかっただけ」なのかが一発で切り分けられます。疑って調べるより、1件打つ方が速く、しかも確実です。
Shopifyであれば、ブラウザのコンソールで次を実行すると、設定を一切変えずに標準イベントの発火状況を一覧できます。
localStorage['shopify-pixel-mode'] = 'debug'もうひとつ、計測の検証で覚えておきたいのがブラウザ側の落とし穴です。開発者ツールのネットワークタブは、sendBeacon で送られるリクエストを取りこぼすことがあります。GA4の送信が「無い」ように見えても、performance.getEntriesByType('resource') で全送信を確認すると、実際には飛んでいることがあります。計測検証はPerformance APIを正とすると決めておくと、この種の空振りがなくなります。同様に、GA4のリアルタイムレポートに自分のアクセスが出ないことも、実装が壊れている証拠にはなりません。
3か所を見ても数字が合わないときに疑う3つの型
観測が正しいと確認できたうえで、まだ数字が合わない場合。壊れ方には型があります。
型A：多すぎる（二重発火）
広告側やGA4の売上が、実際の受注額のちょうど2倍前後になっているケースです。革製品のECサイトでは、ある週のGA4売上が556,160円だったのに対し、実際の受注は287,870円でした。単品でも、1件106,480円の注文がGA4上では212,960円として記録されていました。ここまで綺麗に2倍になるのは、サンクスページで購入タグが2回発火しているときの典型です。
これを放置すると何が起きるか。広告のコンバージョン値をGA4からインポートしている場合、広告側のROAS表示も約2倍に膨らみます。目標ROASを15倍に設定して「10.6倍だから予算を増やそう」と判断したつもりが、実態は5.3倍だった、という事故になります。数字を評価する前に計測を確定させるべき理由はここにあります。
二重発火の原因で最も多いのは、タグの直書きとタグマネージャの併用です。実際に学習塾のサイトでタグマネージャのコンテナを開いてみると、GA4用のタグが2本入っていたことがありました。ここに気づかないままページ側へ直書きのタグを追加していたら、確実に二重計測になっていました。「タグマネージャを入れてください」という依頼は、コンテナの中身を実査するところまでがセットです。
型B：粒度がずれている（1回の行動が複数件に分かれる）
見落とされやすいのがこの型です。イベントは飛んでいて、金額も乗っている。それでも最適化が効かない、という状態を作ります。
オーダーメイド商品を扱うページで、革帯・バックル・かぶせの3パーツをまとめてカートに入れる仕組みがありました。お客さまの操作は「1回」ですが、媒体側に届くカート追加イベントは3件に分裂していました。
カート追加 10,780円（革帯）
カート追加 16,500円（バックル）
カート追加 8,580円（かぶせ）本来1件・合計35,860円として届くべきものが、3件の安いイベントに見えている状態です。カート追加を最適化イベントに指定して広告を配信すると、媒体は「1万円のパーツを1つ買う人」を探しに行きます。イベントの数は合っているのに、学習させたい相手がずれるという壊れ方です。
対処は、パーツ単位ではなくカート合計を1件で送る独自イベントを追加し、そちらを最適化対象にする方法が確実です。ここで大事なのは、既存のイベントを止めずに追加だけで済ませること。既存の3件はそのまま流し、新しいイベントは名前を分けます。こうしておけば、うまくいかなかったときに追加した分を削除するだけで完全に元へ戻せます。計測の改修は、消す作業を含めた瞬間に取り返しがつかなくなります。
型C：金額が乗っていない
イベントは届いているが、金額情報が付いていないケースです。カート表示や一覧表示から出るイベントに金額も商品IDも付いていない、という実装は実際にあります。件数だけが積み上がってデータの品質を薄め、媒体の学習精度を下げます。
金額が可変の商材では、媒体側の設定でコンバージョン値を固定しないことも重要です。固定値を入れると、28,000円の注文も130,000円の注文も同じ価値として扱われます。金額差を学習させたいのであれば、イベントが送る実額をそのまま使う設定にします。
直す前に決めておくこと
計測の改修は、本番の売上導線に手を入れる作業です。次の3つを先に決めてから着手すると、事故が起きません。
- 戻し方を1行で書けるか。 「追加したイベントを削除する。以上」と言い切れる形にします。既存タグの書き換えや削除が混ざると、戻し方が説明できなくなります。
- 変更前の設定を控えたか。 現在稼働しているタグやピクセルの一覧を、IDまで含めてファイルに保存しておきます。改修後に「無傷であること」を照合するために使います。
- 検証の合格条件を先に書いたか。 「発火回数は1回」「金額はカート合計と一致」「他のページでは発火しない」まで先に決めます。決めずに触ると、動いたように見えた時点で終わってしまいます。
実装の直後には、必ずブラウザで実データを取って確認します。前述のオーダーメイド商品の例では、追加したイベントが1回だけ発火し、金額96,800円がカートの合計と完全に一致し、対象ページ以外では発火しないところまで確認しました。「たぶん動いている」で運用に乗せた計測は、数か月後に数字を疑う根拠になります。
計測は「静かに止まる」ので、定期点検を仕組みにする
最後に、いちばん見つけにくい壊れ方について触れておきます。計測やレポートは、エラーを出さずに止まることがあります。
毎朝の広告レポートを自動生成している仕組みで、レポート自体は毎日届くのに、中身が「取得失敗」のまま1週間続いていたことがありました。原因は、広告アカウントと解析ツールにつないでいた認証情報の期限切れです。自動実行の仕組み自体は毎朝「成功」を返していました。ジョブの成否ではなく、出力の中身を見ないと気づけない類の障害です。
これを防ぐには、次のような素朴な確認を運用に入れておくのが有効です。
- 月に1回、広告管理画面の購入件数と、実際の受注件数を突き合わせる。ズレが2割を超えたら計測を疑う
- レポートに「取得できた件数」を必ず出す。件数0のときはアラートを上げる
- 媒体との連携で使う認証情報は、期限切れが起きうるものとして扱い、切れたら気づける形にする
計測は、間違った数字を静かに出し続ける方が、止まるより厄介です。うるさく間違える設計にしておく方が、結果的に安全に運用できます。
まとめ
- 「購入が計測されていない」と判断する前に、イベント一覧を最後の行まで見る／表の列を絞る／自分で1件発火させるの3ステップを踏む
- 管理画面を自分の目で見た結果は「実測」に見えるが、表の見切れによる読み落ちも実測を名乗ってしまう。矛盾を感じたら、システムより先に自分の観測を疑う
- それでも合わないときは、多すぎる（二重発火）／粒度がずれている（1操作が複数件に分裂）／金額が乗っていないの3つの型で切り分ける
- 改修は追加だけで行い、戻し方を1行で説明できる形にしておく
- 計測はエラーを出さずに止まる。件数の突き合わせを月次の作業に入れておく
広告の予算配分も、クリエイティブの良し悪しも、すべて計測の数字を土台にして決めます。土台が2倍に膨らんでいたり、意図と違う行動を数えていたりすると、その上の判断は全部ずれます。設定を触る前に、まず自分が見ている数字が本物かを確かめる。 これだけで、無駄な作り直しの大半は避けられます。