Meta-enabled CAPIと「元々のCAPI」は何が違うのか——理屈と実数値で見る

—

by

uchiumi
in , ,

mareinterno.comの記事では、Meta-enabled Conversions API（2026年4月発表）について「Pixel運用の補強であって、卒業ではない」という結論を書いた。ここでは、その先にある「では本物のCAPI実装は何が違うのか」を、理屈と実際の数値の両方から掘る。

なぜ「複数経路配信」と「元々のCAPI」は別カテゴリなのか

Meta-enabled Conversions APIがやっていることは、Pixelが発火できたイベントを、もう一つの経路で並行して送る——いわば配信の二重化だった。これは「ブラウザが発火できた範囲」に縛られた施策で、ブラウザ側でそもそもイベントが発生しなかったケースは対象外になる。

問題は、「ブラウザ側でそもそもイベントが発生しない」というケースが、想像以上に複数の原因で起きているということだ。少なくとも3つの異なるメカニズムがある。

  1. アプリ内ブラウザでのCookie保持：Instagramなどのアプリ内ブラウザ（in-app browser）は、通常のブラウザと違ってCookieが保持されにくい設計になっている。これは広告ブロッカーやITPとは別の、アプリの実装そのものに起因する問題
  2. ITPによるセッション分断：Safariのトラッキング防止機能により、ファーストパーティCookieであっても保持期間が制限される
  3. 外部ドメイン遷移でのセッション断絶：ShopifyのCheckoutのように、計測対象のサイトから別ドメインに遷移する構成では、参照元情報やセッションIDがそこで途切れる

Meta-enabled CAPIの「複数経路配信」は、この3つのどれも解決しない。なぜなら、これらはすべて「Pixelが発火する前」に起きている断絶だからだ。発火しなかったイベントは、経路をいくら増やしても複製できない。

元々のCAPI実装（サーバーを介してAPIでイベントを送る方式）が違うのは、ここに介入できる点にある。サーバー側でセッションを引き継ぎ、Cookieをファーストパーティとして保持し直し、外部ドメイン遷移後もイベントを紐付け直す——つまり、Pixelが発火するかどうかという前提条件そのものを作り直している。

実例：あるShopify EC事業者でのStape(sGTM)導入結果

理屈だけでは説得力が薄いので、実際の導入結果を見る。対象はInstagram広告主体で集客しているあるShopify EC事業者。導入前の構造的な弱点は、まさに上記の3つに当てはまっていた——Instagram広告経由の流入が大半を占め、ユーザーの大部分がSafari（およびSafari in-app）、ITPとCookie制限によるセッション分断リスクが高い環境だった。

導入前後の変化

ブラウザ構成比（全ユーザーに対する割合）を見ると、最も大きく動いたのは予想に反してSafariではなくChrome mobileだった。

環境導入前導入後変化
Safari mobile65.2%59.5%−5.8pt
Safari (in-app)15.1%16.2%+1.1pt
Chrome mobile8.7%17.6%+8.9pt
Android Webview8.3%5.8%−2.5pt

Safari mobileの構成比低下は、ITPの影響というより「他の環境が増えたことの相対的な結果」で、セッション計測自体はそれまでも機能していたと判断されている。一方Chrome mobileは、Custom TabsやShopify遷移、アプリ間の切り替えでセッションが切れていた可能性が高く、これまで「計測の盲点」になっていた領域だった。Safariの陰に隠れて見落とされがちな構造である。

元々のCAPIにも段階がある

ここで使った実例は、「元々のCAPI」の中でも最高峰にあたる構成——自前のsGTM、しかもStapeで実装したケースの数値だ。季節性・商品投入・施策タイミングなどの影響を含むため、厳密な因果証明ではなく傾向値としての評価にとどまる。ただ、ブラウザ構成比とGA4のチャネル別データはいずれも重複計測の影響を受けにくい生データなので、ある程度の信頼は置ける。

ただ、「元々のCAPI」も一種類ではない。Meta-enabled CAPIという最も簡単な方式と、この実例が示す最も本格的な方式の間には、難易度も精度も異なる複数の選択肢が存在する。

  1. Meta-enabled CAPI：ドメイン設定の概念自体がなく、Pixelのミラーリングのみ。ワンクリックで設定不要
  2. CAPIGデフォルト：MetaのConversions API Gateway。Stape等でホスティングするが、custom domain未設定
  3. CAPIG + custom domain：サブドメインCNAMEで自社ドメイン扱いにする
  4. 自前sGTM：イベント発生源そのものをバックエンドに移せる。今回の実例はここ

（参考：Googleタグの世界には、似た発想の「Google Tag Gateway（GTG）」という選択肢がある。CloudflareやGCPでホストヘッダを書き換えて同一オリジン化する方式で、サブドメインCNAMEよりもさらに強い偽装ができる。ただしGTGはGoogleタグ専用で、Meta Pixelには使えない。）

つまり「CAPIを入れる」という一言で語られる施策は、実際には難易度も効果も大きく異なる4段階を含んでいる。同じ線を二重化するだけのものから、別の堅牢な線を新たに敷くものまで、グラデーションがある。判断軸は、どこまでの精度を必要とし、どこまでコストをかけられるかだ。