数字は嘘をつく
広告の管理画面に表示された「コンバージョン10件」。この数字を見て、順調だと思っていた。
ある事業者が、自社セミナーの集客のためにMeta広告（FacebookやInstagramに配信される広告）を出稿していた。セミナーに興味を持った人がランディングページからフォームを送信すれば、それが「コンバージョン」として1件カウントされる。管理画面には10件と表示されていたから、10人がフォームを送ったのだと、当然そう思う。
ところが、実態は違った。
計測していたのはフォーム送信ではなく、ページを見ただけの人の数だった。Metaのコンバージョン設定で「Lead（リード）」というイベントを選んでいたつもりが、実際にはCONTENT_VIEWという別のイベント──つまり単なるページ閲覧──を拾っていたのだ。
// 誤って計測していたイベント
fbq('track', 'ViewContent'); // ← ページ閲覧をカウント
// 本来計測すべきだったイベント
fbq('track', 'Lead'); // ← フォーム送信をカウント10件のフォーム送信があったのではなく、10回ページが見られただけ。広告費に対する成果の見え方がまるで変わってしまう。
まずはここを正しいLeadイベントに修正した。これで正確な数字が取れるようになるはずだった。
直したはずなのに、ゼロのまま
修正後、管理画面のコンバージョン数はゼロのまま動かなかった。
テストでフォームを送信してみても、数字は増えない。おかしい。設定を見直すことにした。
この事業者のサイトでは、GTM（Google Tag Manager）という仕組みを使って計測タグを管理している。GTMは、ウェブサイトに埋め込むさまざまな計測コード（タグ）を一元管理できるツールで、「このページでこのボタンが押されたらこのタグを動かす」といったルールを画面上で設定できる。
フォーム送信後に表示される「サンクスページ」に到達したら、MetaのPixel（ピクセル）と呼ばれる計測コードに「Leadイベントが発生した」と伝えるタグが仕込んであった。
// GTMで設定していたMeta Pixelタグの構成
タグタイプ: カスタムHTML
トリガー: サンクスページ表示（Page View）
条件: Page URL contains "/thanks"
// タグの中身
<script>
fbq('track', 'Lead');
</script>GTMの設定を確認すると、タグもトリガーも正しく組まれている。理屈の上では動くはずだ。
犯人は意外なところにいた
サンクスページをChromeのDevTools（ブラウザに標準搭載されている開発者向けの検証ツール）で開き、コンソールと呼ばれるメッセージ出力欄を確認したとき、見慣れないメッセージが目に飛び込んできた。
// Chrome DevToolsのコンソールに表示されたメッセージ
⚠️ Duplicate Pixel ID
ピクセルIDが重複しています
🚫 You are attempting to send a restricted event.
The event was suppressed.
制限付きイベントを送信しようとしています。
このイベントは抑制されました。つまり、GTMのタグはちゃんと動いていた。Leadイベントを送ろうとしていた。しかし、受け取る側であるMeta Pixelが、それを「制限付きイベント」として握りつぶしていたのだ。
タグが発火していないのではなく、発火した信号がブロックされていた。
特定カテゴリのサイトに課せられた見えない壁
なぜブロックされるのか。MetaのEvents Manager（イベント管理画面）の診断タブを開くと、答えが書いてあった。
「一部のウェブサイトデータがブロックされました」
その理由は、この事業者のウェブサイトがMetaによって特定の規制カテゴリに自動分類されていたこと。提供しているサービスの性質上、この分類自体は妥当なものだった。カテゴリの変更を申請してみたが、審査で却下された。
これはMetaが近年強化している業種別のデータ制限ポリシーの一環だ。ヘルスケア、金融、政治といった特定のカテゴリに分類されたウェブサイトでは、ユーザーのプライバシーを守るために、ブラウザ上で動作するPixelを使った特定のイベント計測が恒久的にブロックされる。Leadイベントはまさにその対象だった。
ここが厄介なポイントで、設定ミスではなく「仕様」なのだ。どれだけGTMの設定を完璧にしても、ブラウザ側からLeadイベントを送る限り、永遠にブロックされ続ける。
ブラウザがダメなら、サーバーから送ればいい
正攻法がふさがれたなら、別の道を探すしかない。
MetaはConversions API（CAPI）という仕組みを公式に提供している。通常のPixelはユーザーのブラウザ上で動作するが、CAPIはサーバー側からMetaにイベントデータを直接送信する。ブラウザを経由しないため、Pixelのブロック対象にならない。
規制カテゴリに分類されたサイトであっても、CAPIからのLeadイベントは正常に受理される。これはMetaが公式に認めている正規の計測手段だ。
// Conversions API（CAPI）のリクエスト構造
POST https://graph.facebook.com/v18.0/{PIXEL_ID}/events
{
"data": [{
"event_name": "Lead",
"event_time": 1700000000,
"action_source": "website",
"event_source_url": "https://example.com/thanks",
"user_data": {
"em": ["SHA256ハッシュ化されたメールアドレス"],
"fn": ["SHA256ハッシュ化された名前"],
"ph": ["SHA256ハッシュ化された電話番号"]
}
}],
"access_token": "YOUR_ACCESS_TOKEN"
}CAPIを使うにはサーバー側に「フォームが送信されたらMetaにデータを送る」という自動処理を組む必要がある。この事業者のフォームにはJotformというサービスが使われていたので、ここを起点にする。
Jotform → n8n → Meta CAPIの自動化パイプライン
構築した仕組みは、3つのステップで構成されている。
ステップ1：Jotformにwebhookを設定
webhookとは「何かが起きたら指定のURLにデータを飛ばす」仕組みで、フォームが送信されるたびに、次の処理へデータを自動的に渡してくれる。
ステップ2：n8nでデータを変換
n8nは「Aが起きたらBをして、次にCをする」というワークフローをノードと呼ばれるブロックを繋げて構築できる自動化ツールだ。受け取ったデータをMetaが求める形式に変換する。
// n8nのデータ変換ノード（Codeノード）の処理イメージ
const crypto = require('crypto');
// SHA256ハッシュ化関数
function sha256(value) {
return crypto
.createHash('sha256')
.update(value.trim().toLowerCase())
.digest('hex');
}
// Jotformから受け取ったデータをCAPI形式に変換
const formData = $input.first().json;
return {
data: [{
event_name: 'Lead',
event_time: Math.floor(Date.now() / 1000),
action_source: 'website',
user_data: {
em: [sha256(formData.email)],
fn: [sha256(formData.firstName)],
ln: [sha256(formData.lastName)],
ph: [sha256(formData.phone)]
}
}]
};ここで重要なのが、氏名やメールアドレスといった個人情報をSHA256という方式でハッシュ化（元に戻せない形に変換）すること。Metaはプライバシー保護のため、個人情報を平文では受け付けない。
ステップ3：Meta CAPIエンドポイントにPOST送信
変換済みデータをMetaのCAPIエンドポイントにHTTPリクエストとして送る。APIを叩くにはアクセストークンが必要になるので、Metaのビジネスマネージャーでシステムユーザーを作成し、専用のトークンを発行した。
// n8nのHTTP Requestノードの設定
メソッド: POST
URL: https://graph.facebook.com/v18.0/{PIXEL_ID}/events
認証: Bearer Token（システムユーザーのアクセストークン）
ボディ: JSONデータ（ステップ2で変換済み）
緑のチェックマーク、3つ
n8nでワークフローをテスト実行する。1つ目のノードが緑。2つ目も緑。3つ目も緑。全ノード成功。
MetaのEvents Managerでも、テスト送信したLeadイベントがサーバー経由で正しく記録されていることを確認した。
ワークフローをアクティブ化して本番稼働。これで、フォームが送信されるたびに、ブラウザを一切経由せずサーバーからMetaにLeadイベントが届く。規制カテゴリのサイトへのPixelブロックを、正規の手段で迂回できた。
この経験から学んだこと
広告管理画面の数字を鵜呑みにしてはいけない。今回はCONTENT_VIEWをLeadと誤認していたことが出発点だった。数字の定義を確認せずに「10件取れている」と判断していたら、ずっと間違った成果指標で広告を運用し続けていたことになる。
「タグが動いていない」と思い込まないこと。今回はタグ自体はきちんと発火していた。問題はその先、Pixel側でイベントが握りつぶされていたという、一段奥にある原因だった。DevToolsのコンソールメッセージが決定的な手がかりになった。
特定カテゴリに分類されたサイトはMetaの厳格なデータポリシーの対象になる。これは設定の問題ではなくプラットフォームの仕様であり、知らなければ解決の糸口すらつかめない。ヘルスケア、金融、政治など、規制対象の業種は幅広い。
CAPIはブラウザ側の制約を正規に回避できる強力な手段。今後、プライバシー規制の強化やサードパーティCookieの廃止が進む中で、サーバーサイドからの計測はますます重要になっていく。今回の対応は、そうした流れの先取りでもある。
運用上の注意点
- システムユーザーのアクセストークンには60日間の有効期限がある。期限切れでCAPI送信が止まるため、定期的な更新が必要
- Jotformのフォーム項目を変更した場合は、n8nのデータ変換ノードのフィールドマッピングも合わせて修正する必要がある
- 仕組みは動いているが、メンテナンスフリーではない
計測の信頼性は、広告運用の土台だ。その土台が崩れていることに気づけるかどうかで、その後の判断の質はまるで変わる。
