Metaのコンバージョン API（CAPI）とは｜ピクセルだけでは足りない理由と設定の手順Metaのコンバージョン API（CAPI）とは｜ピクセルだけでは足りない理由と設定の手順

「ピクセルは入れてある。なのに、コンバージョン APIも設定してくださいと言われる」

Meta広告を自分で回している人から、こう聞かれることがあります。イベントマネージャを開けばピクセルの数字はちゃんと出ている。これ以上なにを足すのか、そもそも何が違うのか、よく分からないまま放ってある。

ここで止まる人は珍しくない。

コンバージョン API（CAPI）は、ブラウザのピクセルとは別に、サーバーから同じ成果をMetaに送る仕組みです。この記事を読むと、ピクセルだけでは足りない理由、2重に数えないための条件、設定のやり方3つの選び方までが一通り分かります。途中で、私たちが自社で作ったLPでどう実装しているかも、コードの形まで出します。

Metaのコンバージョン APIとは？サーバーから成果を送る仕組み

コンバージョン APIは、広告主のサーバーやCRMからMetaへ、イベントを直接送るための仕組みです。Metaの開発者向けドキュメントでは、ウェブサイトのイベントやオフラインのコンバージョンなどのマーケティングデータを、広告のターゲティングや成果の測定を行うMetaのシステムにつなぐもの、と説明されています（出典はMeta for Developers「コンバージョンAPI」）。

ピクセルとの違いは送り手がどこにいるか。

Metaピクセルは、サイトを見ている人のブラウザの中で動くコードです。フォームを送った瞬間にその人のブラウザがMetaへ「送信があった」と知らせる。コンバージョン APIでは、フォームの中身を受け取ったサーバーが、その足でMetaに知らせます。経路が2本になる。

送り先のIDは同じでかまいません。ドキュメントでも、すでにサイトにピクセルがあるなら、ブラウザとサーバーのイベントに同じピクセルIDを使うよう書かれています（出典はMeta for Developers「スタートガイド」）。

ピクセルだけでは足りない理由は、ブラウザの中で起きることにある

ピクセルが届くかどうかは、訪問者のブラウザ次第。

Metaのベストプラクティスのページには、コンバージョン APIを使うと、通信の問題やページの読み込みエラーでピクセルが失うかもしれないウェブサイトのイベントを送れる、とあります。そのうえで、ピクセルに加えてコンバージョン APIを使い、同じイベントを両方から送るよう勧めている（出典はMeta for Developers「コンバージョンAPIのベストプラクティス」）。

たとえば電話のボタン。

スマホで電話番号をタップすると、画面はすぐに発信の画面へ切り替わります。ピクセルの通信が終わる前にページを離れてしまえばそのタップはMetaに届かない。フォームでも送信後に電波の弱い場所へ移れば同じことが起きます。

私たちが自社のLPでサーバーからの送信を足したのも、この取りこぼしを埋めたかったからです。広告ブロックの拡張機能などで、ピクセルのコードがそもそも読み込まれない場面も想定しました。

取りこぼしは、報告の数字が少なく見えるだけでは済まない。

Meta広告の配信は、成果が出た人の傾向を材料に、次に誰へ見せるかを決めています。材料が欠ければ、学ぶ相手がずれる。成果の数え方と費用対効果の関係はMeta広告の費用対効果を上げる方法でも触れています。

2重に数えない条件は、event_id とイベント名がそろうこと

両方から送ると聞いて最初に心配になるのが重複。フォーム送信1回が2件になっては困る。

Metaのドキュメントでは、重複を除く条件が次のように書かれています（出典はMeta for Developers「ピクセルとサーバーのイベントの重複排除」）。

• ピクセルの eventID と、コンバージョン APIの event_id が一致していること
• ピクセルのイベント名と、コンバージョン APIの event_name が一致していること
• 48時間以内に受け取ったイベントであること

そろえば1件。Metaは基本的に、先に受け取ったほうを残します。

fbp や external_id を使って重複を除く方法も紹介されています。こちらは、ブラウザが先に送り、サーバーがあとから送った場合にしか働かない、と注意書きがある。サーバーのほうが先に届く作りなら、使えない。

私たちは event_id だけで重複を除いています。こちらのほうが迷わない。

設定の手順は3通り、サイトを誰が触れるかで選ぶ

つなぎ方は3通り。Metaのドキュメントでは、コンバージョン APIのつなぎ方として、パートナー連携、コンバージョンAPIゲートウェイ、自分で直接実装する方法が挙げられています。

パートナー連携

サイトを作ったサービスにMetaとの連携が用意されていれば、それを使うのが近道。管理画面でアカウントをつなぐだけで済むことが多い。どのイベントが、ピクセルとサーバーのどちらから送られるのかは、サービスごとに違います。つないだあとに、次の章のイベントマネージャで受信元を確かめてください。

ネットショップで購入イベントを送る場合の広告の組み立ては、ECサイトのMeta広告運用にまとめてあります。

コンバージョンAPIゲートウェイ

ゲートウェイは、イベントマネージャから選べる自分で設定するタイプの選択肢です。Metaのドキュメントでは、開発者の手を借りずに、ピクセルとコンバージョン APIを両方使う形でイベントを送れて、コードは不要と説明されています（出典はMeta for Developers「コンバージョンAPIゲートウェイ」）。

条件が1つあります。AWSのような、Meta以外のクラウドのアカウントが必要です。費用はそのクラウドの利用料か、パートナーの料金だけ、と書かれている。無料ではないので、月々の請求がどこから来るのかは先に確かめておきます。

直接実装

自社でLPのコードを持っているなら、これが一番自由がききます。送るイベント、付ける情報、失敗したときの扱いを全部自分で決められる。

大まかな流れはこうです。

1. イベントマネージャで、ピクセルの設定タブにあるコンバージョンAPIの項目からアクセストークンを生成する
2. トークンをサーバーの環境変数に入れる（コードやリポジトリには書かない）
3. サーバーの処理から https://graph.facebook.com/{APIのバージョン}/{ピクセルID}/events にイベントを送る
4. イベントマネージャの「テストイベント」でテスト用のコードを発行し、一時的に付けて送る
5. 届いたのを確認したら、テスト用のコードを外す

手順1は、ドキュメントで推奨されているやり方です。この方法だとコンバージョンAPI用のアプリとシステムユーザーが自動で作られ、アプリの審査もいらない、とあります（出典はMeta for Developers「スタートガイド」）。

私たちの実装では、フォーム・電話・LINEを分けて送っている

ここからは自社で作ったLPの話。LPはAstroで作り、フォームの受け付けはVercelのサーバーで動く小さな処理であるVercel Functionsに置いています。

送っているイベントは3種類。

Metaのピクセルのリファレンスでは、CompleteRegistration は登録フォームの完了、Contact は電話やSMS、メール、チャットなどで事業者に連絡を始めたとき、と説明されています（出典はMeta for Developers「Metaピクセル リファレンス」）。

Lead はフォームとLINEを合わせた数で、広告セットはこの Lead を成果の目標にして配信しています。フォームだけの数を見たいときは CompleteRegistration を見る。1つの送信で2つのイベントを送っているのはそのため。

フォーム送信の流れ

順番はこう。

1. 送信ボタンが押されたら、ブラウザで event_id を作り、フォームの中身と一緒にサーバーへ送る
2. サーバーは通知メールを送ったあと、同じ event_id で CompleteRegistration を、末尾に _lead を足したIDで Lead をMetaに送る
3. サーバーから成功が返ってきたら、ブラウザのピクセルでも同じ2つのIDで同じ2つのイベントを送る

ピクセルを最後にしているのは、受け付けに失敗した送信を成果として数えないためです。

サーバー側の送信部分を、IDやトークンを伏せて最小の形にするとこうなります。

import { createHash } from "node:crypto";

const sha256 = (v) => createHash("sha256").update(v).digest("hex");
const cookie = (req, name) =>
  (String(req.headers.cookie || "").match(new RegExp(`(?:^|; )${name}=([^;]+)`)) || [])[1];

export async function sendCapi({ req, eventName, eventId, sourceUrl, phone, email }) {
  const token = process.env.META_CAPI_ACCESS_TOKEN; // 環境変数から読む
  const pixelId = process.env.META_PIXEL_ID;
  if (!token || !pixelId || !eventId) return; // 未設定ならピクセルだけで動かす

  const body = {
    data: [{
      event_name: eventName,
      event_time: Math.floor(Date.now() / 1000),
      event_id: eventId, // ブラウザの eventID と同じ値
      action_source: "website",
      event_source_url: sourceUrl,
      user_data: {
        client_ip_address: String(req.headers["x-forwarded-for"] || "").split(",")[0].trim(),
        client_user_agent: req.headers["user-agent"],
        fbp: cookie(req, "_fbp"),
        fbc: cookie(req, "_fbc"),
        ph: phone ? [sha256("81" + phone.replace(/^0/, ""))] : undefined,
        em: email ? [sha256(email.trim().toLowerCase())] : undefined,
      },
    }],
  };

  const ctrl = new AbortController();
  const timer = setTimeout(() => ctrl.abort(), 3000); // Metaが遅くてもフォームを待たせない
  try {
    await fetch(`https://graph.facebook.com/{APIのバージョン}/${pixelId}/events?access_token=${token}`, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(body),
      signal: ctrl.signal,
    });
  } catch (err) {
    console.error("capi failed", eventName); // 失敗してもフォームの受け付けは止めない
  } finally {
    clearTimeout(timer);
  }
}

ブラウザ側は、ピクセルの呼び出しに4つめの引数で同じIDを渡すだけです。

fbq("track", "CompleteRegistration", {}, { eventID: eventId });
fbq("track", "Lead", {}, { eventID: eventId + "_lead" });

送る情報の決まりごと

コードの中の細かい処理は、どれもMetaのドキュメントの決まりに合わせたものです（出典はMeta for Developers「顧客情報パラメーター」と「サーバーイベントのパラメーター」）。

• メールアドレスや電話番号はSHA-256でハッシュ化して送る。メールは前後の空白を取って小文字に、電話は先頭の0を外して国番号を付ける（日本なら81）
• IPアドレス、ブラウザの情報（ユーザーエージェント）、fbp、fbc はハッシュ化しない
• ウェブサイトのイベントでは、ユーザーエージェントとイベントが起きたページのURL（event_source_url）が必須

fbc は広告のクリックを表すCookieで、中身に fbclid が入ります。Facebookから外部のリンクを開いたとき、URLの末尾にくっついてくるあの長い文字列。SNSで共有されたURLにも残っていて、昔はなんの暗号だろうと思っていました。

私たちは event_source_url を送るとき、このクエリ部分を落としてページのアドレスだけにしています。fbc はCookieのほうから別に拾っているので、URLに残す理由がない。

電話タップとLINE

電話はタップの瞬間に画面が切り替わるので、サーバーへの送信に keepalive を付けています。ページが閉じても通信を最後まで送り切るためのブラウザの機能です。ピクセルの送信にも少しだけ時間をあげたくて、発信の画面に移る前に150ミリ秒だけ待たせている。

Contact はタップのたびに送り、Lead は同じブラウザで1回だけ。同じ人が3回タップしても、配信が学ぶ Lead は1件のままです。

サーバーが受け付けるイベント名は Contact と Lead だけに決め打ち。誰でも呼べるURLなので、外から好きなイベントを作られないようにするためです。

LINE友だち追加は、LPからLINEへ移ったあとの出来事なので、LPのサーバーからは見えない。こちらは外部の計測ツールが友だち追加を受けて、Lead として送っています。

テストイベントコードは本番に残さない

僕は最初、テストイベントコードを付けて送ったイベントは、本番の数字には混ざらないものだと思い込んでいた。

実装のコメントにも、そう書いていた。

読み直したら違った。test_event_code を付けたイベントは捨てられずにイベントマネージャに流れ、ターゲティングと広告の測定に使われる。テスト用のコードは本番の送信では外す必要がある、と書かれています（出典はMeta for Developers「APIを使用する」）。

私たちはテスト用のコードも環境変数に入れていて、中身があるときだけ送信に付ける作りです。確認が終わったら変数ごと消す。コードを書き換えずに外せるので、消し忘れても気づけば一瞬で直せます。

同じページには、event_time はMetaに送る時点から最大7日前まで、それより古いイベントが1つでも入っているとまとめて送った分が全部はじかれる、ともあります。成果が起きたら、その場で送る。

Metaピクセルの設定と合わせて、イベントマネージャで点検する

20分以内。送ったイベントがピクセルの概要の画面で確認できるまでの目安として、Metaのドキュメントに書かれている時間です。送信を足したら、まずここで届き方を確かめます。

見ているのは2か所。

イベントの受信元

イベントごとに、ブラウザ（ピクセル）とサーバー（コンバージョン API）のどちらから届いているかが分かれて表示されます。フォーム送信なら両方から届いているのが正しい状態。片方しかなければ、そちら側の送信が止まっています。

Metaの品質の指標には、イベントカバレッジ（event coverage）というものもあります。ドキュメントでは、ピクセルのイベントのうち、コンバージョン APIからも同じ重複除外のキーで届いている割合の7日間の平均と説明されている（出典はMeta for Developers「データセット品質API」）。両方から送っているのに低いなら、event_id の渡し方がずれています。

イベントマッチ品質

イベントマッチ品質は、サーバーから送った顧客情報が、どれだけイベントをMetaのアカウントに結び付けられそうかを10点満点で表したものです。どの顧客情報を受け取ったか、その質、アカウントに結び付いたイベントの割合から計算される、と同じページにあります。

点数を上げる手段は送る情報を増やして正しく整えること。メールや電話を送れるイベントでは送り、ハッシュ化の前の整え方を間違えない。fbp と fbc も付ける。ベストプラクティスのページには、この2つのCookieの値は変わることがあるので、定期的に新しい値を送るよう書かれています。

• フォーム送信のイベントが、ブラウザとサーバーの両方から届いているか
• 同じ送信が2件に数えられていないか（イベント数とフォームの通知メールの件数を突き合わせる）
• イベントマッチ品質が低いイベントに、送れるはずの顧客情報が抜けていないか
• テストイベントコードが本番の環境変数に残っていないか
• アクセストークンがコードやリポジトリに書かれていないか

広告管理画面の見方や、どの指標から見ればいいかで迷うなら、Meta広告が難しいと感じる理由と解決策から読むと入りやすいはず。Google広告の計測も一緒に整えるなら、Google広告のコンバージョン設定で、同じ問い合わせを2つの設定で数えない考え方を書いています。

次の一歩は、自分のサイトを誰が触れるかを確かめること

選び方は単純。

サイト作成サービスやECサービスに連携があるならそれをつなぐ。コードは書けないがクラウドのアカウントは用意できるなら、ゲートウェイ。自社でLPのコードを持っているなら、直接実装。どれを選んでも、最後にイベントマネージャで受信元とイベントマッチ品質を見るところまでは同じです。

直接実装を選ぶなら、先に決めておくことが3つあります。どの行動を何のイベントとして送るか。event_id をどこで作り、どう両方に渡すか。送信に失敗したとき、お客さんの操作を止めるかどうか。私たちは止めないと決めました。