コンバージョンAPI（CAPI）とは？｜広告に届く成果をサーバー側で守る仕組み

広告の管理画面を開くたびに、コンバージョン数が実際より少なく出ている気がする——そう感じたことはないでしょうか。

原因の多くは、ブラウザ側の計測がここ数年で急速に弱くなっていることにあります。Appleの追跡型広告に対する規制や、Safari・Firefoxの追跡防止機能は、サードパーティCookieだけでなく広告タグそのものの発火まで制限するようになりました。

その穴を埋める仕組みとして、MetaやGoogleをはじめとする広告プラットフォームが推し進めているのが、本記事のテーマであるコンバージョンAPI（Conversions API、以下CAPI）です。広告予算を握るプロダクトマーケターや、計測基盤の実装を任されるエンジニアの双方にとって、避けて通れない話題になっています。

この記事では、CAPIがどんな仕組みで動いているのか、導入すると何が変わり何が変わらないのかを、プロダクトやマーケティングの現場目線で整理します。

ブラウザ計測が弱くなり続ける理由

話の前提として、なぜブラウザ側の計測がここまで弱くなったのかを押さえておきましょう。広告のクリックからコンバージョンまでを追跡する仕組みは、長らくCookieと、ページに埋め込んだJavaScriptタグ（ピクセル）に依存してきました。

ブラウザとOSがトラッキングを制限する側に回った

2021年のiOS 14.5でAppleがApp Tracking Transparency（ATT）を導入し、アプリ横断の追跡には明示的な同意を必須にしたのは広く知られた転換点です。SafariのITP（Intelligent Tracking Prevention）やFirefoxのEnhanced Tracking Protectionも、サードパーティCookieの保持期間を短くしたり、広告トラッキング用ドメインへの通信を制限したりします。

広告ブロッカーや企業ネットワークのセキュリティ製品が、ピクセル自体の読み込みをブロックするケースも珍しくありません。本サイトの過去記事Googleが「サードパーティCookie廃止」を撤回した理由で触れたとおり、Googleは土壇場でサードパーティCookie廃止の撤回を決めましたが、SafariやFirefoxは独自にブロックを続けており、ブラウザ計測が万能に戻ったわけではありません。

制限は今後も強まりこそすれ、弱まる見込みは薄いというのが実務上の前提です。だからこそ、ブラウザに依存しない計測経路をどう確保するかが、広告運用チームの共通課題になっています。

サーバー間で計測するという別ルート

ブラウザ側が信頼できないなら、計測の主戦場をサーバー側に移そう、という発想が生まれます。自社サイトの分析基盤をサーバーサイドに寄せる話はサーバーサイド計測とは？で扱いましたが、CAPIはその考え方を「広告プラットフォームへの成果報告」に特化させたものだと捉えると理解しやすくなります。

訪問者のブラウザを経由せず、事業者のサーバーから直接、広告プラットフォームのAPIエンドポイントにイベントを送信する。それがCAPIの基本構造です。

コンバージョンAPIとは何か

定義を確認しておきましょう。コンバージョンAPIとは、購入やリード獲得といった成果イベントを、事業者のサーバーから広告プラットフォームへ直接送信するためのインターフェースです。

ピクセルとの役割分担

名前がよく挙がるのはMetaのConversions APIですが、同じ考え方はGoogle広告の拡張コンバージョン（Enhanced Conversions）や、TikTokのEvents APIにも存在します。呼び方は違っても構造は共通していて、ブラウザで動くピクセル（クライアント側）と、サーバーから送るCAPI（サーバー側）を併走させるのが標準的な構成です。

片方だけに頼らないのは、ピクセルは行動の文脈を捉えやすく、CAPIはブロックされにくい代わりに文脈情報が薄い、という互いの弱点を補い合う関係にあるからです。どちらか一方を選ぶものではなく、両輪として設計するのが基本になります。

送られるデータの中身

CAPIで送るイベントには、purchaseやleadといったイベント名、金額や通貨などの成果の中身、そして相手を特定するための顧客識別子が含まれます。識別子の代表格はメールアドレスと電話番号ですが、そのまま送ることはなく、次章で説明するハッシュ化を経由します。

送信先はプラットフォームごとに別々のAPIエンドポイントで、フォーマットも微妙に異なります。ここを1件ずつ手作業で合わせるのは現実的ではないため、実務ではタグ管理システムやサーバーサイドGTMのようなハブを介して配信するのが一般的です。

リアルタイム性とバッチ送信

CAPIのイベントは、注文確定のタイミングで1件ずつ即座に送ることもできますし、日次バッチでまとめて送ることもできます。即時送信のほうがマッチ品質は高く出やすい一方、実装の複雑さは増します。

どちらを選ぶかは、既存のバックエンド構成と、広告運用チームがどこまでリアルタイム性を必要としているかで決めるのが現実的です。まずはバッチ送信で仕組みを検証し、精度が求められる主要イベントだけ即時送信に切り替える、という段階移行も無理のない選択肢です。

仕組み：ハッシュ化とマッチング

CAPIの肝は、個人情報を生のまま渡さずに同一人物だと広告プラットフォーム側に伝える仕組みにあります。ここを誤解すると、実装の必要性そのものが腹落ちしません。

ハッシュ化という一手間

メールアドレスや電話番号は、送信前にSHA-256という不可逆なハッシュ関数にかけられます。同じ入力からは常に同じ出力が得られる一方、出力から元の入力を復元することは事実上できない処理です。

広告プラットフォーム側もユーザーの登録メールなどを同じ手順でハッシュ化して保持しているため、両者のハッシュ値が一致すれば、生のメールアドレスをやり取りしなくても同一人物だと突き合わせられます。仮に自社のユーザーテーブルに1万件のメールアドレスがあったとしても、外部に渡るのはハッシュ値だけで済みます。

マッチ品質という考え方

この突き合わせがどれだけ成功したかを示す指標として、Metaはイベントマッチ品質（EMQ）というスコアをEvents Manager上に表示します。送る識別子の種類が多く、フォーマットが正しいほどマッチ率は上がります。

逆に言えば、メールアドレスの表記ゆれ（大文字小文字や全角半角）を正規化してからハッシュ化しないと、本来一致するはずのデータが不一致扱いになる点には注意が必要です。地味な前処理の丁寧さが、そのままマッチ率に跳ね返ってきます。

説明用の仮定として、メールアドレスと電話番号の両方を正規化してから送った場合と、メールアドレスだけを未加工のまま送った場合とでは、同じ100件の購入データでもマッチする件数が大きく変わり得ます。前処理の質は、実装作業の中でもっとも地味で、もっとも効果に直結する部分だと考えておくとよいでしょう。

重複排除という設計上の要

ピクセルとCAPIを併走させると、当然ながら同じ購入が二重に報告されるリスクが生まれます。ここを軽視すると、CAPI導入がかえって数字を歪めてしまいます。

共通IDでの突き合わせ

これを防ぐのがイベントID（Meta）やトランザクションID（Google）と呼ばれる、ブラウザ側とサーバー側の両方に同じ値を持たせる仕組みです。広告プラットフォームは、同じイベント名と同じ識別子を持つイベントが一定時間内に複数届いた場合、片方を重複として除外し、もう片方だけを成果として数えます。

逆にこの識別子の発行と共有が甘いと、実際には1件の購入が2件として集計され、広告の費用対効果を実態より良く見せてしまいます。良く見える数字ほど、まず重複を疑う癖をつけておくとよいでしょう。

二重計上が起きるとどう困るか

見かけ上のコンバージョン数が水増しされると、広告プラットフォームの自動入札はその良い結果を再現しようとして、実際には効果の低い配信面や層に予算を寄せてしまいます。つまり重複排除は精度の問題であると同時に、広告予算の配分そのものを歪めるリスクでもあるということです。

数値はあくまで説明用の仮定ですが、ある月に実際は50件だった購入が、共通IDの発行漏れによってピクセル側とCAPI側で別々にカウントされ、広告プラットフォーム上では100件の購入として報告されるといったことが起こり得ます。この状態で自動入札を回すと、実態の2倍の成果が出ている配信面に予算が集まり続けることになります。

導入で何が変わり、何が変わらないか

ここまでの内容を、ピクセル単体運用との違いとして整理してみましょう。表にすると、変わる部分と変わらない部分の輪郭がはっきりします。

表からもわかるとおり、CAPIは計測の取りこぼしを減らす手段であって、失われたデータを魔法のように復元する仕組みではありません。同意管理の仕組みで計測を拒否したユーザーの分は、CAPI経由であっても送信してはならず、同意の扱いはブラウザ側と同じ基準で運用する必要があります。

また、CAPIが埋めるのは広告プラットフォームに成果を伝える経路であって、そもそも広告接点が記録されない流入までは埋められません。検討期間が長い商材でのSNSのDMや口コミ経由の申し込みのような見えない検討プロセスは、ダークファネルとは？で扱った領域と地続きです。

もう一つ見落とされがちなのが、ハッシュ化は個人情報を扱わなくてよくする仕組みではないという点です。ハッシュ化前のメールアドレスや電話番号を取得・利用する行為自体は、通常の個人情報の取り扱いと同じ扱いを受けます。

実装をエンジニアだけに任せきりにせず、利用目的の通知や同意取得の手順を法務・マーケティング側とすり合わせておくと、後から慌てずに済みます。

重複計上が起きているときは、次のような兆候として現れることが多いので、定期的に見ておくとよいでしょう。

• 特定のキャンペーンだけコンバージョン数が不自然に伸びている
• 広告プラットフォーム上の成果件数と、自社の受注・申し込みデータの件数が合わない
• イベントマネージャーの診断画面で、同じ注文のはずのイベントが重複として警告されている

導入の進め方とプラットフォームごとの違い

実務でCAPIを入れるときは、いきなり全イベント・全プラットフォームを対象にせず、段階を踏むことをおすすめします。焦って一気に広げると、不具合の原因の切り分けが難しくなります。

スモールスタートで始める

まずは購入や申し込みなど成果に直結する1イベントだけを対象にCAPIを実装し、各プラットフォームの診断画面でマッチ品質と重複排除の状態を確認します。数値が安定してから、カート追加やフォーム開始といった中間イベントへ対象を広げ、複数の広告プラットフォームへ展開していくのが無理のない順序です。

最初の1イベントを選ぶ段階で、次の3点を確認しておくと後戻りが少なくなります。

• そのイベントに紐づく顧客識別子（メールアドレス・電話番号）を、サーバー側で確実に取得できるか
• ブラウザ側のピクセルと共有できる共通IDを、注文完了などのタイミングで発行できるか
• 診断画面でマッチ品質と重複排除の状態を、実装直後に確認できる体制になっているか

プラットフォームごとの呼び名の違い

名称と細部は各社で異なるため、実装前に対象プラットフォームの呼び方を確認しておくと混乱を避けられます。骨格は共通していても、キーの名前は微妙に食い違います。

このように仕組みの骨格は共通していても、キーの名前や送信タイミングの細部は異なります。1社での実装経験をそのまま別のプラットフォームに流用しようとすると、思わぬ差異でつまずくことがあります。

まとめ

MonaLensは訪問者のCookieや個人情報を集めずにファネルやN1分析を行う設計を選んでいるため、メールアドレスや電話番号をハッシュ化して広告プラットフォームに送るCAPIそのものは提供していません。自社サイト上のどのステップで離脱しているかをアトリビューションの実務で整理したような形で把握するところまでがMonaLensの役割で、その先の広告プラットフォームへの成果連携は、CAPIや各社のタグ管理の領域だと切り分けて捉えるのが実務上は素直です。

ブラウザ側の計測がこれからも制限され続ける前提に立つなら、CAPIは一過性の対策ではなく、広告運用の標準装備になっていくと考えられます。大切なのは、ハッシュ化や重複排除といった仕組みを正しく理解したうえで、同意管理と組み合わせて運用することです。

そしてCAPIが埋めるのは、あくまで広告接点があった成果までだと割り切ることです。自社の計測がどこまでを捉え、どこから先が見えていないのかを整理する作業そのものが、広告予算の使い方を見直す最初の一歩になります。