Facebook広告のコンバージョンAPIを導入する前に知っておきたい5つの事

Facebook社は2021年10月20日に、コンバージョンAPIをより簡単に実装できるためのソリューションとして、コンバージョンAPIゲートウェイの提供を開始しました。

参考：Continued Improvements to Ad Performance and Measurement | Facebook for Business

コンバージョンAPIゲートウェイが登場したことで、本格的にコンバージョンAPIの導入を検討される方も多くいらっしゃるかと思います。

※Facebook広告のコンバージョンAPIとは？についてはこちらの記事を参考にしてみてください

Facebook広告のコンバージョンAPI（CAPI）とは何か？を理解する前に知っておきたいこと

コンバージョンAPIゲートウェイという新しいワード、簡単に実装できるようになったというメリットはとてもキャッチーに聞こえるのですが、本当に簡単に実装できるのか、そもそもコンバージョンAPIの導入は早く進めた方が良いのか？など疑問に思われる方も多いかと思います。

本記事では、私がコンバージョンAPIの実装に携わってきた経験の中で、これだけは事前に知っておいて欲しいという事を5つ紹介いたします。

どの項目も公式なドキュメントで公開されている様な情報で秘密裏にされている内容ではないのですが、あまり言及されることもない事柄です。これらの情報がコンバージョンAPI導入を検討される際の参考になれば幸いです。

コンバージョンAPIは、コンバージョン計測の欠損を防ぐためのソリューションではなく、あくまでもデータを送る手段である

コンバージョンAPIを導入すると、同意プラットフォームやデバイスが要因となるCookie制限の影響を受けることがなくなります。

しかしながら、コンバージョンAPIはあくまでも上図の②’と③’で示すように、Facebook Pixelを使わずにデータをFacebook社に送るためのただの手段（仕組み）であることを忘れてはなりません。

物流でトラックが荷物各地に運ぶ例で例えると、Pixelを使うのかコンバージョンAPIを使うのかが「道路」、イベントデータやカスタマーデータ（個人情報）を「荷物」と表せます。

つまり、これまでは目的地に到達するまではPixelという道路1本しかなかったところ、迂回路としてコンバージョンAPIというバイパスが整備されたとイメージいただくのが良いかなと思います。

さらにマニアックな例えをするならば、コンバージョンAPIを直接システム開発して実装を行うのか、Shopifyのようなパートナー統合で実装するのか、Google タグマネージャーを使って実装するのか、コンバージョンAPIゲートウェイを使って実装するのかは手段の差でしかありませんので、荷物をいすゞのトラックで運ぶのか日野の2tトラックで運ぶのか...くらいにイメージしていただけれるとスッキリするかもしれません（スッキリする保証はいたしません）。

つまり、コンバージョンAPIの採用によってCookieの制限を受けることなく計測する事は可能になりますが、ここで重要になってくるのはコンバージョンAPIによってどのようなデータ（荷物）を送るか？です。

せっかくコンバージョンAPIを実装しても、Facebookに送信されるデータがFacebook Pixelのそれと比べてスカスカであれば、計測精度を高めることはできません。

コンバージョンAPIの実装自体がゴールなのではなく、コンバージョンAPIを使って計測に必要なデータを広告主がFacebookに送信できる状態になる事がゴールと言えましょう。

コンバージョンの計測漏れを防ぐのは、コンバージョンAPIではなくカスタマーデータ送信による詳細マッチングの機能

前項のようにコンバージョンAPIの採用だけでは計測精度を高めることはできない事を説明しましたが、計測精度を高める為に必要なのは何でしょうか？

それは、カスタマー情報パラメーター（Customer Information Parameter）で定義されている顧客に関する情報（個人情報）をFacebookに送信することです。

参考：パラメーター - マーケティングAPI

Facebookは広告主から送信された個人情報と、Facebookアカウントの個人情報などとマッチングをさせることでコンバージョン計測の補完を行う詳細マッチングという機能を提供しています。

Facebook広告「詳細マッチング」とは？効果的な使い方や実装方法

コンバージョンAPIと詳細マッチングは混同されがちなのですが、コンバージョンAPIはあくまでもイベントや個人情報を送るための手段であり、詳細マッチングは送られた個人情報を使ってコンバージョンの計測を行うための手段なので、それぞれは別の物として捉える必要があります。

ゆえに、コンバージョンAPIを導入していたとしても、カスタマー情報パラメーターで定義される項目に関する個人情報（道路、トラック、荷物のうち荷物に当たるもの）を送信できていなければ、詳細マッチングが行えないため、コンバージョン計測の欠損は解消されません。

つまり、コンバージョンAPIは、詳細マッチングに必要な個人情報の送信とセットで実装できないと実力は発揮できないと言わざるを得ません。

一方で、コンバージョンAPIを利用していなくとも、Facebook Pixelによる詳細マッチングが実装できていれば、コンバージョンの計測漏れはある程度防げる仕組みになっています。

コンバージョンの計測によって得られるシグナルは、広告運用における自動入札で特に重要なものとなっているので、対応の優先順位はとしては詳細マッチングが最も高く、次いでコンバージョンAPIで対応していくことをおすすめしています。

コンバージョンAPIに関しては、今後も多くのCMSやASPカートなどで順次対応されていくのではないか？と考えると、本当に今すぐお金をかけて実装すべきか？は再考の余地があります。

それに比べて少ない投資で実装できて、コンバージョンの計測漏れを防ぎ、広告成果の最大化を目指すことができる詳細マッチングに対応するべきというのが筆者の考えです。

詳細マッチングの仕組みは、その後のコンバージョンAPI実装時でも大きな変更を加えることなく使えるケースもある（特にGoogle タグマネージャーを利用して実装する場合）ので、先だって対応しておいて損はありません。

Facebook PixelとコンバージョンAPIで送られたイベントが重複する場合は、Pixelのイベントが優先される

ドキュメントとして仕様が公開されている内容ではあるのですが、ひとつ悲しい事実をお伝えいたします。

Facebook社は、Facebook PixelとコンバージョンAPIの併用かつ、event_id と event_name を使った重複処理を行うことを推奨としています。

重複処理を行った結果、Facebook PixelかコンバージョンAPIのどちらかのイベントが破棄されるのですが、2021年10月現在におけるコンバージョンAPIの仕様では、Facebook Pixelから送られたイベントとコンバージョンAPIによって送られたデータがほぼ同着（どちらかが先に受信されてから5分以内）の場合は、Facebook Pixelによるイベントが優先される仕様になっています。

また、どちらかのイベントが受信されて5分超えてから48時間以内に順された場合は後続のイベントが破棄される仕様です。

よって、Facebook PixelとコンバージョンAPIを併用する環境下においては、コンバージョンAPIから送られるイベントが利用されるケースとしては下記の条件の両方を満たした場合となります。

• Facebook Pixelよりも先にサーバーイベントが受信された
• サーバーイベントの受信から5分以上が経過してFacebook Pixelのイベントが受信された

つまり、Facebook PixelとコンバージョンAPIを併用する場合で、コンバージョンAPIから送信されたイベントやデータが生かされるのは、Facebook Pixelが正しく読み込まれなかった場合になります。なので、サーバーから送られたイベントが破棄されずに受信される可能性は非常に低いといえます。

よって、コンバージョンAPIは欠落したFacebook Pixelデータの補完を行う程度の役割になるくらいに考えておくのが良さそうです。

図：テスト環境で実験したときのイベントレポート

筆者個人のテスト環境で、Facebook PixelとコンバージョンAPIを併用し、event_id と event_name を使って重複処理をさせてみたところ、仕様通りの動作となりました。

現在は重複処理によってどちらかのイベントが破棄されてしまう仕様となっていますが、一部の広告主に対してはFacebook PixelとコンバージョンAPIによるイベントのマージ機能も提供されているようです。

参考：ピクセルイベントとサーバーサイドイベントの重複除外 - マーケティングAPI

イベントのマージ機能が利用できるようになれば、Facebook PixelとコンバージョンAPIからのイベントを結合させることができるようになり、Facebook PixelとコンバージョンAPIから送信されたデータのうち不足しているデータを補完し合えるようになるので、コンバージョンAPIからの送信が無駄になることもなくなるでしょう。

余談ですが、Facebook PixelとコンバージョンAPIから送られるイベントが重複処理された結果、Facebook Pixelのイベントが優先されるということは、コンバージョンAPIでイベントと共に送信できるデータよりもFacebook Pixelから得られるデータの方がその種類が多いからという理由なのだろうなと考えます。

コンバージョンAPIでも用意されている全てのサーバーイベントパラメーター（Server Event Parameters）で各種データをしっかり送信できれば、Facebook Pixelで送信されるデータの質に並ぶものと考えられますが、恐らくそのような実装を全ての広告主ができるわけではないので、Facebook Pixelが利用できるうちは確実に多くのデータを送ることができるFacebook Pixelが優先される仕様になっているのでしょうね。

参考：サーバーイベントパラメーター - マーケティングAPI

コンバージョンAPIゲートウェイはノーコードだけれども、導入難易度が低いわけではない

冒頭でもお伝えしたとおり、Facebook社は2021年10月20日にコンバージョンAPIの導入をより簡単に行うことができるよう、コンバージョンAPIゲートウェイの提供を開始したと発表しました。

参考：Continued Improvements to Ad Performance and Measurement | Facebook for Business

このコンバージョンAPIゲートウェイの特徴について、Facebook Businessヘルプセンターの中では次のように述べられています。

引用元：コンバージョンAPIゲートウェイについて | Facebook Businessヘルプセンター

ITチームや開発者チームのリソースが不足している中でもコンバージョンAPIの実装が簡単にできるようになり、長期的なメンテナンスコストも削減できるとあります。

一方で、コンバージョンAPIゲートウェイ設定ガイドを確認してみると、別途AWS（Amazon Web Service）サーバー契約が必要だったり、ドメインに関する知識が必要だったり、「デプロイ」や「プロビジョニング」といった聞き慣れない言葉が並びます。

参考：コンバージョンAPIゲートウェイ - 設定ガイド - マーケティングAPI

また、コンバージョンAPIゲートウェイで利用するAWSサーバーは広告主側で事前に契約する必要があり、AWSの利用に際して発生する費用は広告主が支払うことになる事も分かります。

さらに設定ガイドを読み進めていくと、確かに開発に関わるエンジニアリソースはほぼ不要になるのですが、サーバーサイドエンジニアリングに関する知識が多少なりともないと進めにくいなという印象は強く残りました。

筆者の経験上、AWSやGoogle Cloud Platform（以下、GCP）を利用している、これらに知見をもつ広告主はあまり多い印象がなく、ほとんどのケースで導入に際して簡単ではないと感じられてしまいそうです。

AWSのサーバーを契約するにせよ、サーバーのリージョンをどうするか、スペックをどうするかを契約時にある程度決めておく必要があります。つまり、ある程度AWSやサーバーに関する知識が無いと、契約も頓挫しやすい印象があります。

なお、指定したAWSのサーバー構成に対してどのくらい月額費用がかかるかのお見積もり計算ツールも用意されていますが、AWSの概念を知っておかないとお見積もりもどうして良いか分からないという状況に陥ります。

参考：AWS Pricing Calculator 

確かに画面ポチポチで設定できるという意味ではすごく簡単なのですが、これら設定を完了できるようにするためには少なくともAWSに関する知見が必要になってくるので、別の意味で難易度が高くなった感じは否めません。

コンバージョンAPIゲートウェイで利用できるのは現時点でAWSのみ

コンバージョンAPIゲートウェイに関して知っておきたいことがもうひとつ。それは、コンバージョンAPIで利用できるサーバーは、2021年10月現在ではAWSのみになっていることです。

AWSと同様のサービスとしてGCPも存在しますが、実は現時点ではコンバージョンAPIゲートウェイのホスト先としてGCPを利用することができません。2021年10月現在では上記キャプチャの通り、AWSを利用することが前提となっています。

短期的に考えて、今すぐコンバージョンAPIゲートウェイによるコンバージョンAPI実装を行いたいのであれば特に問題はありません。

ただし、中長期的に考えたときに、AWSを利用することが将来的に足かせになってこないか？と言う観点でコンバージョンAPIゲートウェイの導入判断をしても良いはずです。

なぜならば、Google 広告が提供するCookieレスのコンバージョン計測である拡張コンバージョンに関しても、Facebook広告のコンバージョンAPIのように、イベントを広告主のサーバーから送るという仕組みを一般開放する可能性があるためです。これを実装するためにはGoogle タグマネージャーのサーバーサイドコンテナを利用すると考えられるのですが、その際にはGCPのサーバーが必要になります。

また、Google アナリティクス系のプロダクトも、Google タグマネージャーのサーバーサイドコンテナを利用できるようになるなどの動きもあります。

つまり、Google系のプロダクトはGCP、FacebookのコンバージョンAPIゲートウェイはAWSといったように、プラットフォームごとに異なるサーバーを利用しなければならないという事態にもなりかねません。

幸いなことに、Facebook広告のコンバージョンAPI実装に際しては、Google タグマネージャーのサーバーサイドコンテナ＋GCPといった構成でも対応できるので、Google系プロダクトでのGCP利用を加味したうえで検討するでも良いでしょう。

参考：Googleタグマネージャ用コンバージョンAPI - マーケティングAPI

先にコンバージョンAPIゲートウェイでAWSサーバを構築し、もしも将来的にコンバージョンAPIゲートウェイがGCPに対応したら乗り換えるという方法もありますが、乗り換え時のリソースやそれにまつわるスイッチングコストが発生してくることが容易に想像できますので、それらと天秤にかけたうえで検討されるのがおすすめです。

新しいソリューションが登場した場合は一歩引いて考えてみる

コンバージョンAPIやコンバージョンAPIゲートウェイという新しいソリューションを見聞きすると、すぐに導入すべき、導入する事がゴールと捉えられがちなのですが、それらの仕様や仕組みを理解していないまま導入を進めてしまうと、後々にそれが足かせとなってしまう可能性もあります。

ただし、ここで声を大にして伝えたいのは、中長期よりも短期で考えて導入する事が決して悪いことではないということです。ビジネス規模が大きなナショナルクライアントと呼ばれる企業の場合は、短期的にみていち早く導入する事が必要という場面もあるでしょう。

一方で中小規模のビジネスでは、コンバージョンAPI実装に対する投資額とリターン、それに人的リソースとのバランスを考慮したときに、本当にコンバージョンAPIの実装が早急に必要かどうかはフラットに考えても良いはずです。

これらの新しいソリューションが盛り上がってきたら、世に出ている情報を鵜呑みにせず、一旦は一歩引いて考えてみると良いでしょう。

アナグラムではFacebook広告のコンバージョンAPIゲートウェイの利用も含め、Facebook 広告のコンバージョンAPIをはじめとするCookieレス計測の導入を支援するサービスを提供しています。ご興味ある方は下記のバナーからサービスページをご覧ください。