Meta広告のCVは、どうやって1件になるのか。昔の僕が分からなかった計測の仕組みを、全体像で整理します
文章目录
運用初心者だった当時、テスト購入をして、「よし、OK。」
……と思っていたのに、広告マネージャの購入数は、まったく増えていない。
クライアントに聞かれました。
「なんでcvがつかないんですか？」
「……」
その場は「確認して折り返します！」でなんとか乗り切りました。（当時のクライアントさん、すみません。）
正直、どこを確認すればいいのかすら分かっていなかったんです。
そうなんです。あの頃の僕は、Meta広告の計測の仕組みをちゃんと分かっていませんでした。
PixelもCAPIも、fbclidも_fbcも_fbpも、言葉は知ってたんです。
でも「それぞれ何をしてるの？」と聞かれると、ふわっとしか説明できなかった。
分かったふりをしてたんですよね。（今思うと恥ずかしいです。笑）
特に勘違いしていたのが、
「PixelでPurchaseが発火すれば、それがそのまま管理画面の1CVになる」
と思っていたことです。
でも実際は、そんなに単純ではありません。Purchaseが発火してから管理画面に1CVが付くまでには、重複排除・照合・アトリビューションと、思っていたよりずっと多くの処理が挟まっています。
この記事では、昔の僕が知りたかった順番で、広告が表示されてから管理画面の「購入」が1件増えるまでを解説していきます。
これを知ることで、こんなことが得られます。
・計測設定の精度を上げることができる
・できること、できないことが分かる
・計測漏れなど、事故や不備に対応することができる
ちょっと長いです。でも図も入れたので、流し読みでも大丈夫です。たぶん。
① まずは広告が表示される。実はここから計測は始まってる
ユーザーAさんが、Instagramで「広告A」を見たとします。
この時点では、Aさんはまだサイトに来ていません。なので広告主のサイト側では、何も起きていません。
でも、Meta側にはちゃんと記録が残ってるんですよね。「誰に・どの広告を・いつ表示したか」という、広告接触の記録です。
これが、あとで購入が起きたときに「この人、買う前にどの広告を見てたっけ？」を照合するための材料になります。
僕はずっと、CV計測って「購入した瞬間」の話だと思ってました。
でも実際は、広告が表示された時点からもう始まってるんです。
② クリックすると、URLに「fbclid」がくっつく
Aさんが広告をクリックすると、リンク先のURLに「fbclid」という値が付くことがあります。
example.com/?fbclid=XXXXXXXX
広告からサイトに飛んだとき、URLがやたら長くなっているのを見たことがあると思います。あの謎の英数字の羅列です。
正直、ただのゴミだと思ってました。（すみません）
クライアントに「広告から飛ぶと、URLに変な文字列が付くんですけど。」と聞かれて、「大丈夫です！」と即答しました。根拠はゼロです。（すみません、その2）
実は、これがけっこう大事な値でした。fbclidは、FacebookやInstagramからサイトに飛んだ「このクリック」を識別するための値です。広告に限らず、オーガニック投稿のリンクから飛んだときにも付きます。
ちなみに、Aさん個人を表すIDではありません。ここ、勘違いしやすいので覚えておいてください。
（余談ですが、iOSのSafariのプライベートブラウズなど一部の環境では、こういう追跡用のパラメータがURLから消されることもあります。地味に効いてきます。）
③ fbclidは「_fbc」として保存される。「_fbp」はみんなに付く
ここが一番ややこしくて、僕が一番長いことふわっとさせていたところです。
名前が似すぎなんですよ。fbclid、_fbc、_fbp。考えた人をちょっと恨みました。笑
実際、「_fbcと_fbpって何が違うんですか？」と聞かれて、「どっちもCookieです！」と答えて逃げたことがあります。間違ってはいないのが、また厄介です。
でも、整理してみると意外とシンプルでした。
■ _fbc：クリック情報を保存しておくもの
URLに付いてきたfbclidを、Pixelが読み取ってCookieとして保存したものです。
例えるなら、fbclidは「その場で渡された一時的なメモ」で、_fbcは「そのメモを手帳に書き写したもの」。手帳に書いてあるから、ページを移動しても、後日購入しても、「どの広告クリックから来た人か」をたどれます。
そして、fbclid付きのURLから来たとき、つまり主にFacebookやInstagramからのクリックで来たときにしか作られません。広告クリックとの紐付けに使われるのは、この_fbcです。
広告クリック → URLにfbclid → Cookieに_fbcとして保存
■ _fbp：ブラウザを見分けるもの
こっちは、Pixelが入ったサイトに来たブラウザ全部に付きます。広告から来たかどうかは関係ありません。FacebookのユーザーIDでも、スマホの端末IDでもないです。
fbclid＝メモ、_fbc＝手帳に書き写したもの、_fbp＝ブラウザの名札。これで覚えたら、だいぶスッキリしました。
ちなみにどちらも広告主ドメインのファーストパーティCookieなので、いわゆるサードパーティCookie規制の影響は受けにくいです。ただ、SafariではJavaScriptで付けたCookieの有効期限が最長7日に制限されます。しかも、fbclidのような追跡用パラメータ付きのURLから着地した場合は、24時間まで短くなることがあります。広告経由の訪問ほど影響を受けやすい、ということです。
この弱点が、このあと出てくるCAPIの話につながってきます。伏線です。
④ サイトで購入が完了する
Aさんがサイトの中を進んで、無事に購入完了。
おめでとうございます、Aさん。広告主も大喜びです。
このとき、サイト上では「Purchase」というイベントが発生します。
ただ、ここで一つ気をつけたいのが、この時点ではまだ、広告主のサイトの中だけの出来事だということ。
Aさんが買ったことを知っているのは、広告主のサイトだけ。Metaはまだ何も知りません。
ここから、Metaに知らせる旅が始まります。
📷
⑤ PurchaseをMetaに届ける。PixelとCAPIの違いは「通り道」
届け方は2つあって、違いは通り道です。
Meta Pixel：ユーザーのブラウザ → Meta
CAPI（Conversions API）：広告主のサーバー→ Meta
よく言う「Pixelが発火する」というのは、このブラウザからMetaへの送信のことです。（発火って言い方、ちょっとカッコいいですよね。笑）
Meta Pixel Helperで見えるのはブラウザが送ったところまで、イベントマネージャで見えるのはMetaが受け取ったところまでです。
以前の僕は、ここでPurchaseが確認できれば、それがそのまま管理画面の1CVになると思っていました。
でも実際は、Metaに届いただけ。まだ「誰の購入なのか」「どの広告の成果なのか」は決まっていません。それを決めるのが、このあとの⑥〜⑧の処理です。
さて、話を戻します。ブラウザから送る方法だと、広告ブロッカーやブラウザのCookie制限、途中でページを閉じられた、などで取りこぼしが出ます。
そこでCAPIも一緒に使うと、ブラウザに頼らない通り道からも届けられる、というわけです。さっきの伏線の回収です。
これも僕が勘違いしていたことなんですが、「CAPI＝Cookieを使わない計測」ではないんですよね。
CAPIでも_fbcや_fbpは普通に送ります。他にも、メールアドレスや電話番号（ハッシュ化したもの）、external_id、IPアドレス、User Agent、購入金額などを送れます。
ひとつ落とし穴なのが、自前で実装する場合、_fbcや_fbpはサーバーが勝手に拾ってくれるわけじゃない、ということ。サーバー側でCookieを読み取って送る実装が必要です。IPアドレスやUser Agentも同じで、Pixelなら自動で付くものを、サーバーからは自分で付けて送る必要があります。（ShopifyなどのカートシステムやCAPIゲートウェイを使う場合は、自動で送ってくれるものもあります）
「CAPI入れました！」で安心しがちですが、中身までちゃんと送れているかは別の話です。
僕は「CAPI入れたほうがいいですよ」と提案しておいて、エンジニアさんに「で、何を送ればいいですか？」と聞かれて固まったことがあります。提案した本人が、一番分かっていませんでした。
⑥ PixelとCAPIの両方から送ったら、2CVにならない？
なりそうですよね。僕も最初そう思いました。実際、対策をしていないと2件として数えられてしまうことがあります。
それを防ぐのが「重複排除（Deduplication）」です。
Metaは、イベント名（event_name）とイベントID（event_id）が両方一致するものを、同じイベントとして1件にまとめてくれます（両方の受信が48時間以内であることも条件です）。
Pixel：Purchase / ORDER123
CAPI：Purchase / ORDER123
→ 1件として処理
考えた人、頭いいなと思いました。
で、ここに地味すぎる落とし穴があります。
Pixel側ではパラメータ名が「eventID」、CAPI側では「event_id」なんです。表記が違う。なんで。
ここを取り違えると重複排除されず、CVが二重に計上されます。「CAPI入れたらCVが急に増えた！」は、喜ぶ前にまずここを疑ったほうがいいです。（喜びたい気持ちは分かります）
僕も昔、CAPIを入れた直後にCVが増えて、「効果出ましたね！」と報告しそうになったことがあります。……二重計上でした。危なかった。
なお、event_idは「1回のイベント」を見分けるためのIDで、ユーザーを見分けるものではありません。
⑦ 「これ、誰のPurchase？」を照合する（Event Matching）
ここからが、僕がいちばん「へぇ〜」となったところです。
Metaに届いたPurchaseを、Metaはこう見ています。
「で、これ誰？」
そりゃそうですよね。Purchaseが届いただけでは、どこの誰の購入かは分かりません。
この「誰？」を照合するのがEvent Matchingです。
最初は、Cookieがあればそれで終わりじゃないの？と思っていました。
でも実際は、_fbc、_fbp、メールアドレス、電話番号、external_id、IPアドレス、User Agentなど、いろんな情報を使います。Cookieひとつで「この人だ！」と決めているわけではなく、手がかりを組み合わせて照合しているイメージです。
この照合に、CAPIで送った情報がどれくらい役立っているかの目安が、イベントマネージャの「イベントマッチング品質（EMQ）」です。スコアが低いと、あとで地味に効いてきます。
⑧ どの広告の成果にするか（Attribution）
さて、これでAさんの購入だと分かりました。
広告Aの成果になる…かというと、まだです。（まだあるんです。長い。笑）
Metaは、Aさんが過去にどの広告に接触していたかを照合して、条件を満たすかどうかを判定します。これがアトリビューションです。
9月25日 広告Aのリンクをクリック
9月29日 購入
現在の標準的な設定では、「リンククリック後7日間」「エンゲージ後1日間」「ビュー後1日間」に起きたCVが対象です。この例はリンクをクリックしてから4日後の購入なので、広告Aの成果になり得ます。
ここで言う「クリック」は、サイトなどへ飛ぶリンククリックだけです。いいね・保存・シェア・コメント・5秒以上の動画視聴などは「エンゲージ」という別枠で扱われます。
（この区分、2026年3月に変わりました。それより前の記事を読むときは注意です。昔は、いいねもクリック扱いでした）
複数の広告に接触していた場合は、リンククリック、エンゲージ、ビューの順に優先され、原則として最後の接触に計上されます。
ここで、ちょっと面白いケースを一つ。ビュー経由です。
広告を見ただけでクリックせず、あとで検索からサイトに来て買った場合。URLにfbclidはないし、_fbcも作られません。
じゃあどうやって広告と結び付けるの？と思いますよね。
そこで効いてくるのが、⑦で出てきたメールアドレスなどの照合情報です。逆に言えば、照合情報が少ないと、こういうCVは付きにくくなります。
「メールアドレスも送ってください」と言われる理由が、ここでやっと腹落ちしました。
⑨ ここでようやく、管理画面の「購入」が1件増える
ここまで来て、ようやく広告管理画面の「購入」が1件増えます。
長かった。ほんとに長かった。
（ここまで読んでくださった方、ありがとうございます。あと少しです。）
イベント発生
→ Metaへ送信（Pixel / CAPI）
→ 重複排除
→ 誰のイベントか照合
→ 広告接触と照合・アトリビューション判定
→ 広告CVとして計上
※説明のために段階を分けていますが、Metaの中で実際にどの順番で処理しているかは公開されていません。
あともうひとつ。管理画面の数字は、全部が1件ずつ照合されたものとは限りません。iOSでトラッキングを許可していないユーザーなど、直接照合できない一部のCVについては、Metaは統計的なモデリングによる推定値も含めて報告しています。
つまり「管理画面の数字＝全部実測」ではない、ということです。これを知ったときは、ちょっとショックでした。
⑩ 数字がズレたときの確認ポイント
ここまで読んで、「で、結局ズレたらどこを見ればいいの？」となると思うので、最後にまとめます。
ここまでの各ステップが、そのままチェックポイントになります。どこで落ちているかを、順番に見ていくイメージです。
・ ② fbclidが消えていないか：リダイレクトなどで、URLから落ちてしまうことがあります
・ ③ Cookieは残っているか：_fbc・_fbpが付いているか、有効期限で消えていないか
・ ⑤ CAPIは届いているか：イベントマネージャでサーバーイベントを受信しているか
・ ⑥ 重複排除できているか：eventID / event_idが一致しているか（CVが多すぎるとき）
・ ⑦ 照合できているか：EMQが低くなっていないか（CVが少なすぎるとき）
・ ⑧ そもそもルールが違わないか：GA4はMeta広告の表示を把握できないので、ビュー経由のCVは数えません。また各媒体がそれぞれ自分の成果としてCVを数えるので、全媒体のCVを足すと実際の注文数を超えることがあります
全部を一気に見る必要はありません。CVが多すぎるのか、少なすぎるのかで、まず当たりを付けると楽です。
それと、Meta広告マネージャでは原則として、購入日ではなく広告に接触した日にCVが計上されます。日別の数字が合わないときは、まずここを確認するのがおすすめです。（これ、知らないと沼ります）
僕はこれを知らずに、日別の数字を1時間くらい睨んで、「なんでズレてるんだ…」とやっていたことがあります。原因は、ただの仕様でした。
おわりに
正直、この記事に書いたことは、公式ドキュメントを読めばだいたい書いてあります。
でも僕は、読んでも頭に入ってきませんでした。
言葉を知っていることと、仕組みが分かっていることは、全然違うんですよね。
一度流れで理解できてからは、数字がズレても慌てなくなりました。「どこで落ちてるんだろう」と、落ち着いて考えられるようになった。これが一番大きかったです。
あのときのクライアントさん、改めてすみませんでした。今なら、ちゃんと答えられます。
同じように「なんとなく分かってるつもり」でモヤモヤしている方にとって、何かのきっかけになったらうれしいです。
最後まで読んでいただき、ありがとうございました！
（「うちはこう見てるよ」というご意見があれば、ぜひ教えてください。）
【用語集】
読み返すとき用に置いておきます。
・ Meta Pixel：ブラウザからMetaへイベントを送る仕組み
・ CAPI（Conversions API）：広告主のサーバーからMetaへイベントや照合用の情報を送る仕組み
・ fbclid：FacebookやInstagramからのクリックを識別するために、URLに付く値（広告・オーガニック共通）
・ _fbc：fbclidをCookieとして保存したもの。fbclid付きのURLから来た訪問でのみ作られる
・ _fbp：サイトを訪れたブラウザを識別するCookie
・ event_id：1回のイベントを識別するID。重複排除に使う
・ Deduplication（重複排除）：複数の経路から届いた同じイベントを1件にまとめる処理
・ Event Matching：イベントがMeta側の誰の行動かを照合する処理
・ EMQ（イベントマッチング品質）：CAPIで送った情報が照合にどれだけ役立っているかの指標
・ Attribution：CVをどの広告接触の成果として扱うかを判定する仕組み
・ external_id：広告主側で顧客を識別するために使うID（会員IDなど）
・ User Agent：ブラウザや端末環境に関する情報
