AWSを利用したFacebook コンバージョンAPI Gateway

久しぶりにFacebook/Instagramの話です。
今回はいきなり本題入っちゃいましょう。

FacebookはコンバージョンAPIの設定をより簡潔にするため
コンバージョンAPI Gateway を活用した方法をリリースしました。

一部界隈で話題になっていますね。

今回はこちらの方法について解説していこうと思います。

コンバージョンAPI Gateway（CAPIG）について

コンバージョンAPI Gatewayは、イベントマネージャーから利用できる、
コンバージョンAPIを設定するためのFacebookの最新アプローチになります。

機能を簡単に書くと以下のとおりです

コンバージョンAPI Gateway (CAPIG)は、Pixelタグを通してブラウザからイベントを受け取ります。そのイベントを処理して、コンバージョンAPIに送信します

利点としてはCAPIGを使用すると
イベントの重複除外を設定したり、
サーバーからユーザーパラメータやイベントを送信する必要がありません。

特にイベントの重複除外を設定しなくていいのは嬉しいですね。
event_id 重複除外キーは自動的に生成され、両方のチャネル（ブラウザとサーバー）間で重複除外が勝手に行われます。

なお、コンバージョンAPI Gatewayの現在のバージョンは
AWS(Amazon Web Service)のみをサポートしているので
AWSのアカウントがないと始まりません。
（※GCPと同様にAWSも基本有料です）

つまり、データをFacebookに共有するAWSのクラウドベースのサーバーインスタンスに、自社のウェブサイトを接続することになります。

CAPIGを急いで導入するべきか？

後ほど、詳しい設定を書きますが
おそらくコンバージョンAPIを設定するだけならば
最も簡単で最速な方法になっていると思います。

「じゃあサーバーサイドGTMとGoogle Cloud Platform (GCP)を使った方法よりラクなんだ！こっちで設定しよう」

と思うかもしれません。
（サーバーサイドGTMのコンバージョンAPI設定はこちら参照）

FacebookのコンバージョンAPIを設定するだけならば
確かに今回のAWSを活用した方法はサーバーサイドGTMの方法より簡単かと思います。

ただ、将来的なことを考えると、
Google広告やGoogle AnalyticsはサーバーサイドGTMで色々と対応できるようにしてくるでしょう。(他の媒体も追随すると思われる)

つまり、（ほぼ）GCPは必須です。

となると、現在GCPに対応していない
コンバージョンAPI Gatewayを急いで使うべきか？
というとそれは少し考える余地があると思います。

※サーバーサイドGTMの設定でGCPが「ほぼ」必須と書きました。なぜ「ほぼ」かというと、実はGCPではなく、AWSにデプロイすることも可能といえば可能です。。。
が、めちゃくちゃ面倒くさいので、素直にGCPを使うのが今のところ正解だと思います。※

CAPIGのメリットとデメリット

メリットとデメリットを簡単にまとめます。
これまでの話の中で述べている部分もありますが。

メリット

1. 簡単&早い
これに尽きます

CAPIGはFacebookのコンバージョンAPIを設定するだけであれば、
最も簡単で、最も早い方法かと思います。

イベントの重複処理やユーザーパラメータを送る設定を別途行う必要もありません。

CAPIGは、Facebook/Instagram広告のみを実施しているクライアントには最適でしょう。

2. オフラインのデータ活用に対応予定
そもそも『コンバージョンAPI自体』のメリットの1つとして
WEB上では取得出来ないイベントやシグナルもFacebookへ送信することで
データ最適化を行えることがあります。

以下の図を見て下さい