コンバージョンAPI(CAPI)とは?Cookie規制下の計測の仕組みと4つの導入方式・外注判断を解説

コンバージョンAPI(CAPI)は、広告主のサーバーから広告媒体のサーバーへ、コンバージョンのデータを直接送る計測方式です。ブラウザのCookieに頼っていた従来のタグ計測は、SafariのITPや広告ブロッカーの普及でデータの欠落が広がりました。その欠落を埋める手段がコンバージョンAPIです。この記事では、ブラウザ計測との違いという仕組みの土台から、Meta・Google・Yahoo!・LINE・TikTokの対応状況、ノーコードから自社API実装まで4つの導入方式の比較、そして「自社開発まで踏み込むべきか、ツールで足りるか」の判断軸までを、受託開発会社の視点で整理します。

目次

まとめ:コンバージョンAPIは計測欠落を埋める手段であり導入方式の選択が成否を分ける

コンバージョンAPIの本質は、ブラウザを経由せずサーバー間でコンバージョンを送ることで、Cookieが失われても計測を続けられる点にあります。技術的な新しさそのものより、自社の計測体制にどう組み込むかが成果を左右します。

導入方式は大きく4つあります。ShopifyなどのプラットフォームでのノーコードSet、GTMサーバーサイド(sGTM)、CAPiCOやStapeなどの外部ツール、そして自社サーバーでのAPI直接実装です。単一媒体で月間コンバージョンが少なくノーコードで足りる事業者は、自社開発まで踏み込む必要はありません。複数媒体へ送りオフラインの成約データまで突き合わせたい事業者は、sGTMや自社実装が選択肢に入ります。判断を分けるのは検索ボリュームでも流行でもなく、送りたいデータの複雑さと媒体数です。

コンバージョンAPIの仕組みとブラウザ計測との違いという土台

まず押さえるべきは、データが「どこから」送られるかです。従来のタグ計測とコンバージョンAPIは、送信元が根本的に異なります。

従来のピクセル計測が抱えるCookie欠落という構造的な限界

従来の広告計測は、ブラウザに埋め込んだ計測タグ(Metaならピクセル)が、閲覧者のブラウザから媒体サーバーへコンバージョンを送る仕組みでした。この方式はサードパーティCookieやブラウザの識別情報に依存します。SafariのITP(Intelligent Tracking Prevention)はこうしたCookieの寿命を最短24時間などに制限し、iOSのSafari利用者が多い日本市場では計測漏れが無視できない規模になりました。広告ブロッカーやトラッキング防止拡張機能も、タグの発火自体を止めます。結果として、実際は成約しているのに広告側では成果として記録されないズレが生じるのです。このズレが広告の自動入札を狂わせ、獲得単価の悪化につながります。

サーバー間でのデータ送信とハッシュ化マッチングという中核の仕組み

コンバージョンAPIは、コンバージョンのデータを広告主のWebサーバーやCRMから、媒体のAPIエンドポイントへ直接送ります。ブラウザを経由しないため、Cookieの制限やブロッカーの影響を受けにくいのが利点です。送るデータには、メールアドレスや電話番号といった顧客情報が含まれますが、これらはSHA-256などでハッシュ化してから送信し、媒体側は受け取ったハッシュ値を自社の保有データと突き合わせて広告接触者と同定します。生の個人情報を平文で渡すわけではありません。Metaの場合、ブラウザのピクセルとサーバーのAPIを併用し、同じ成約を二重に数えないようevent_idで重複を排除する設計が標準です。この併用と重複排除が、精度を担保する肝になります。

主要広告媒体ごとのコンバージョンAPI対応状況という選定前提

「コンバージョンAPI」は特定の1社の機能名ではなく、各広告媒体がそれぞれ用意するサーバー間送信の総称です。媒体ごとに名称も成熟度も違うため、自社が出稿している媒体の対応を先に確認します。

Meta・Google・Yahoo!・LINE・TikTokの各API名と位置づけ

2020年代半ば時点で、主要媒体はいずれもサーバー間送信の手段を提供しています。名称と位置づけは次の通りです。

媒体 機能名 特徴・位置づけ
Meta(Facebook/Instagram) Conversions API(CAPI) 普及が最も進む。ピクセルとの併用・重複排除が前提
Google広告 拡張コンバージョン+オフラインインポート 単一CAPIでなく複数機能で構成される
Yahoo!広告 コンバージョンAPI サーバー間送信に対応。国内で採用増
LINE広告 Conversions API LINE公式アカウント連携と併せた計測で用いられる
TikTok広告 Events API ピクセルと併用するサーバーイベント送信

Googleだけは「コンバージョンAPI」という一枚岩の機能ではない点に注意します。ウェブの成果を補う拡張コンバージョンと、店舗やCRMの成約を後から取り込むオフラインインポートを、目的に応じて使い分けます。各媒体の仕様は更新が続くため、実装前に必ず公式のヘルプで最新の項目要件を確認してください。

サーバーサイドトラッキング(sGTM)との関係を整理する位置づけ

コンバージョンAPIと混同されやすいのがサーバーサイドトラッキングです。両者は対立概念ではありません。サーバーサイドトラッキングは、計測データをいったん自社が管理するサーバー(GTMサーバーサイド=sGTM)で受け止め、そこから各媒体へ配る「計測の中継基盤」を指します。コンバージョンAPIは、その中継基盤から媒体へ送る「出口の一つ」です。複数媒体へ同じ成約を配りたい場合、媒体ごとに個別実装するより、sGTMを一度立ててそこから各媒体のAPIへ分配するほうが保守は軽くなります。自社の計測全体をどう再設計するかは、GA4の仕組みと運用体制の判断を解説した記事と併せて検討すると、広告計測とアクセス解析の両輪で筋の通った設計になります。

コンバージョンAPIの4つの導入方式と必要な体制の比較という意思決定

ここが事業会社にとって最も判断が要る部分です。導入方式によって、必要なスキル・コスト・柔軟性が大きく変わります。

ノーコード・sGTM・外部ツール・自社API実装の4方式比較

4つの方式を、必要な体制とデータの自由度で並べます。上から下へ、手軽さと引き換えに柔軟性が増していきます。

方式 必要な体制 向く場面 限界
プラットフォーム標準(Shopify等) 設定操作のみ 対象プラットフォームで完結する単一媒体のEC 送れる項目・媒体が枠内に限られる
GTMサーバーサイド(sGTM) GTM運用+サーバー費用 複数媒体へ配る計測中継を持ちたい sGTMの構築・保守に知見が要る
外部ツール(CAPiCO/Stape等) ツール設定+月額費用 自社開発は避けつつ精度と媒体数を確保したい ツールの対応範囲に依存する
自社サーバーでAPI直接実装 バックエンド開発・保守体制 CRMやPOSと突合し独自のマッチングを設計したい 開発・維持の工数とコストが最も重い

実務でまず押さえるべきは、上の方式で要件を満たせるならそれで止めることです。自社開発は自由度が最大ですが、その自由度を使い切る要件がないなら、保守コストだけが残ります。sGTMの構築や自社API実装まで踏み込む段階では、計測設計とインフラの両面を見られる開発パートナーが前提です。当社ではアクセス解析・計測設計のコンサルティングとsGTM構築の支援を承っており、どの方式が自社の媒体構成と成約データに見合うかの切り分けから相談できます。

コンバージョンAPI導入で媒体共通となる設定の基本手順と注意点

方式が決まったあとの流れは、媒体を問わず概ね共通です。

  1. 送るコンバージョンの定義を決める(購入・リード送信・会員登録など)
  2. 媒体側でAPIのアクセストークンとデータセット(Metaならピクセル)を用意する
  3. ブラウザの既存タグと重複しないよう、送信するイベントと識別子(event_id等)を設計する
  4. ハッシュ化する顧客情報の項目と、同意が取れているデータの範囲を決める
  5. テスト送信で媒体の管理画面に一致率とイベントが届くことを確認し、本番へ切り替える

3番目の重複排除の設計を飛ばすと、ブラウザとサーバーで同じ成約が二重計上され、かえって数字が信用できなくなります。手順の中でも最初にテストすべき箇所です。

自社開発のコンバージョンAPIを採用すべき条件と見送る場面の判断

ここは競合記事が明言を避けがちな部分なので、条件を切って言い切ります。「導入したほうがよい」で終わらせず、踏み込む線引きを示します。

自社サーバーでのAPI直接実装を見送るべき場面は明確です。出稿が単一媒体で、コンバージョンが月に数十件規模、かつShopifyなどのノーコードや外部ツールで対応済みなら、自社開発は過剰です。得られる精度の上積みより、開発と保守の工数が上回ります。この段階で自前実装に走るのは、費用対効果を崩す典型的な失敗パターンです。

逆に、自社開発や本格的なsGTM構築が見合うのは、複数媒体へ同じ成約を配る必要があり、オンラインの申込とオフラインの受注・解約までCRMで突き合わせて広告に返したい場合です。ここまで来ると、ノーコードの枠では送れる項目が足りず、マッチング精度を自社で作り込む価値が出ます。判断の物差しは1つ、「送りたいデータが標準機能の枠に収まるか」です。収まらない要件が具体的に挙がったときが、開発投資に踏み切る合図になります。

プライバシー保護と計測精度を両立させる導入・運用設計の注意点

コンバージョンAPIは顧客データを扱う以上、法務と精度の両方に目配りが要ります。導入後に問題化しやすい2点を先に押さえます。

同意管理とプライバシーポリシーの整備というデータ送信の前提条件

コンバージョンAPIでハッシュ化して送るとはいえ、送っている元は顧客の個人情報です。個人情報保護法や、送信先を含むデータの取り扱いについて、プライバシーポリシーへの明記と、必要な同意取得が前提になります。Cookieに関する同意管理(同意バナー)だけでなく、サーバー経由で送るデータの範囲も同意の対象に含めて設計します。同意を前提に顧客が自ら差し出すデータについては、ゼロパーティデータとは何かと集め方・マーケでの使い方を解説した記事も併せて参考になります。ハッシュ化は個人情報でなくなる魔法ではなく、あくまで送信時のマスキング手段だと捉え、法務の確認を通したうえで送信項目を確定してください。

計測精度を左右するイベントの重複排除とマッチング品質の確保策

精度を決めるのは、送る量ではなく突合の質です。Metaなら、ピクセルとAPIで同一成約を送る際にevent_idを揃えて重複を消し、メールや電話番号のハッシュだけでなく、fbp/fbcといった識別子も併せて送ると一致率が上がります。送る項目が少ないと媒体側が広告接触者と結びつけられず、送っているのに成果として計上されないケースが起きるのです。テスト段階で媒体管理画面の一致率(マッチ品質)の指標を見て、低ければ送信項目を足す調整を行います。数字を伸ばす前に、送ったデータが正しく突合されているかを先に確かめる。この順番を守ることが、計測を投資に見合うものにします。日々の指標の読み方はアクセス解析でGA4の指標を改善につなげる手順の記事も参考になります。

コンバージョンAPIの導入判断でよくある質問と実務からの回答例

導入検討でよく挙がる質問に、実務の観点から簡潔に答えます。

コンバージョンAPIを入れればピクセル(タグ)は不要になりますか?

不要にはなりません。Metaをはじめ主要媒体は、ブラウザのピクセルとサーバーのAPIを併用し、重複を排除する併用構成を推奨しています。ピクセルはブラウザ側の即時イベントを、APIはCookie欠落分を補い、両者で計測を全体化する構成です。片方だけに寄せると、取れていたデータまで落ちる場合があります。

コンバージョンAPIの導入にはエンジニアが必須ですか?

方式によります。Shopifyなどの標準連携やCAPiCO・Stapeといった外部ツールなら、マーケティング担当者の設定操作で完結できる範囲です。一方、sGTMの構築やCRMと突合する自社実装まで踏み込むと、バックエンドとインフラの知見が要ります。まずノーコードやツールで要件を満たせるかを確認し、満たせない項目が出た段階で開発体制を検討する順序が現実的です。

Cookie規制が続く中で、コンバージョンAPIはどこまで有効ですか?

ブラウザのCookieに依存しないため、ITPや広告ブロッカーによる欠落には強い方式です。ただし、送る元データの同意と品質に依存する点は変わりません。Chromeのサードパーティ Cookieの扱いは2020年代半ば時点で方針が流動的なため、特定の廃止時期を前提に設計するより、サーバー間送信を早めに整えておくほうが変化に耐えます。

コンバージョンAPIとサーバーサイドトラッキングは同じものですか?

別の層の話です。サーバーサイドトラッキングは、計測データを自社サーバー(sGTM)でいったん受ける中継基盤を指し、コンバージョンAPIはそこから各媒体へ送る出口の一つです。複数媒体に配るなら、sGTMを土台にして各媒体のAPIへ分配する構成が保守しやすくなります。

導入後、成果はどのくらいで表れますか?

計測の欠落が埋まること自体は、テスト送信で一致率を確認できた時点で表れます。ただし、広告の自動入札が補われたデータで学習し直して獲得単価に反映されるまでには、媒体の学習期間として数週間を見込むのが一般的です。導入直後の数値だけで判断せず、学習後の水準で費用対効果を評価してください。

関連記事

資料請求

RELATED POSTS 関連記事