260
-
28
58
Facebook広告に携わる方だけでなく、インターネット広告に少しでも関わっている方であれば、サードパーティCookieについて近頃騒がしいのはご存知かと思います。そして、その文脈でコンバージョンAPI（CAPI）という言葉も耳にしたことがある方もいらっしゃるのではないでしょうか？
一方で、聞いたことはあるけどなんとなく分かったつもりで話を合わせている…重要だとは思うけど何となく踏み込めずにいる…という方も少なからずいらっしゃるのではないかと思います。
そこで、この記事では、コンバージョンAPI（CAPI）とは何か？を理解する前に、なぜコンバージョンAPIという概念や計測手段が登場したのか？という背景から実際の設定や導入方法についてまで、理解を深めていただくために説明します。
少々長いどころではないですが、最後まで読んでいただくことで、コンバージョンAPI（CAPI）については自信をもって話せるようになるはず（はず…）です。ぜひ最後までお付き合いください！
目次
Cookieに依存した計測の終わりの始まり
ここ数年、インターネットのWebサイトを閲覧しているときに、色々な情報がいつの間にか取得され、第三者がそれら取得した個人の行動履歴や興味関心といった情報をマーケティング活動に利用していることが問題視されているのはご存じかと思います。
これら行動履歴や興味関心といった情報は、Cookieという技術を使って広告プラットフォームのサーバーに送信され、パーソナライズされた広告が配信されるようになりました。
しかしながら、その結果「いつも同じ広告が表示されてウザい」「知らない間に情報が取得され、広告のパーソナライズに利用されるのが気持ち悪い」などの声も大きくなっていき、パーソナライズ広告に対する批判は日に日に強まって行くことになります。
また、Cookie自体がインターネットに関するテクノロジーの中でもレガシーなものになってきており、クロスサイトスクリプティング（XSS）の脆弱性を突いて、Cookie内の個人情報を盗み見られてしまうというケースも増えてきています。
これらの背景から、このCookieの利用を制限することで、第三者が勝手に個人の情報を利用することを防ぎ、利用者のプライバシーを守ろうというのが世界的な流れになってきています。
後述いたしますが、Cookieはここで挙げたパーソナライズ広告のみならず、広告の成果（コンバージョン）を計測する目的でも利用されており、Cookieが利用できなくなることで広告の成果そのものを評価することができなくなってしまうことになります。
つまり、今やCookieに依存した計測の時代は終わりに向い始めた、と言い表すことができるのです。
次の項からは、Cookieの制限がどのように始まっているかについて、ブラウザやデバイスレベル、世界各国の法律の面から説明します。
ブラウザやデバイスレベルでのCookie制限
ブラウザやデバイスレベルでCookie制限を大手のブラウザの中で最初に開始したのは、Apple社のブラウザであるSafariが最初と記憶しています（間違っていたらすみません）。筆者の記憶では、2012年当時は既にデフォルトでサードパーティCookieをブロックする設定になっていました（当時はまだ設定変更でサードパーティCookieを受け入れることは可能でした）。
Google Chromeでは2023年後半（当初予定であった2021年後半から延長）にサードパーティCookieのサポート廃止、Mozilla FirefoxやMicrosoft EdgeなどでもサードパーティCookieは利用をデフォルトでブロックするよう変更され、サードパーティーCookieを使った計測ができない環境になりつつあります。
また、iPhoneやiPadなどに搭載されているiOS、Mac OSのSafariには2017年からITP（Intelligent Tracking Prevention）が実装され、現在iOSやMac OSのSafariではファーストパーティCookieであっても制限の対象となっています。
詳しくは後述しますが、これまでの広告効果の計測はCookieの利用が前提となっていますので、その利用が制限されてしまうと、計測できるデータに大きな欠損が発生します。ブラウザやデバイスレベルでのCookie制限が広がれば広がるほど、運用型広告の（見た目上の）成果に大きなマイナスインパクトを与えることになりかねません。
世界的に個人情報保護に対する規制が強化
世界に目を向けてみると、GDPRやCCPAといったプライバシー保護に関する法律によってCookieの利用に大幅な制限が行われるようになっています。
GDPRであればWebサイトのアクセス時にポップアップなどにより明示的に同意を求める（オプトインの可否）必要があり、CCPAであればオプトアウト方法を必ず提示することで、Cookieの利用をコントロールする必要があるようになりました。
海外展開する日本の企業であれば、これらを遵守するために対応を行っているケースもあるものの、多くの日本の企業から見れば対岸の火事くらいに捉えていたかもしれません。
日本においても個人情報保護に対する規制が強化
日本においては、運用型広告におけるリターゲティング広告や、コンバージョン計測に使われるCookieは個人情報を含まないデータが使用されることが多かったため、事前の同意取得に関しては対応しなくても良いケースがほとんどでした。
2022年に施行される改正個人情報保護法では、Cookieを使って外部のDMP（データ提供元）に蓄積された情報と、自社（データ提供先）が保持する個人情報とが紐付けられる場合、そのCookieは制限の対象となりCookieの利用について同意を得る（下図のイメージ）必要があることになります。
前述のとおり、リターゲティング広告やコンバージョンの計測によって、Cookieと個人情報が広告主側で紐付かないような運用となっている場合はこれまで通りですが、Cookieを使ってDMP等を使って蓄積した情報と紐付けられる場合は、新たに同意を得るための仕組みなどを導入する必要があります。
日本の改正個人情報保護法の場合、ケースによってCookieの利用に対して事前の同意が必要な場合とそうではない場合が存在するとみられており少々複雑ですが、日本でもサードパーティCookieだけではなく、Cookie利用の同意有無によってCookieの利用が制限される時代に既に突入しています。
Cookieが制限されると何が起こるのか
世界的にCookieが制限されてゆく一方で、広告からの成果（コンバージョン）は計測タグとCookieを用いた計測がまだ主流になっています。
①で計測タグを読み込むと、②でブラウザに計測用のCookieをセット、コンバージョンに至った場合は③でCookieのデータを広告媒体の計測サーバに送信。送信されたデータを使ってコンバージョンとして媒体管理画面に計上される仕組みです。
日本国内で主力となっている広告プラットフォームの多くは、ファーストパーティCookieを利用することで、Webブラウザ上で発生したコンバージョンについては計測ができる状況ではあります。
海外の状況に目を移してみると、前述したGDPRやCCPAといった法の発効により、Webサイトにアクセスした時点でCookie利用に関する同意を取らなければならないケースが増えてきています。
当然ながら同意が得られなければ、Cookieを利用することができないため、Cookieを使った計測は一切出来なくなります。つまり、広告成果として計上されるべきコンバージョンが組み込まれなくなるため、計測データに欠損が発生してしまいます。
コンバージョンが計測できなければ、広告の費用対効果も把握出来ませんし、現在主流になっている広告の自動入札もまともに動かなくなってしまいます。
自動入札はコンバージョンが正確に測定できているという前提をもとにオークションごとの最適化を実現しているため、この前提が狂うと、広告の費用対効果を測れないばかりか、間違った運用を加速させてしまう恐れすらあるのです。
今日の日本ではCookieの利用に際して事前の同意は必須ではありませんが、海外展開を行っている日本企業の場合はCookieの利用に際して同意を取る必要があるケースがあり、既にCookieを利用した計測で測定データの欠損が発生しやすい状況下に置かれています。
時代はこのまま規制を強化していく流れがつづくと思われます。そうなると、日本でもいずれCookieを使った計測が出来なくなる日が到来します。
だからこそ、Cookieに依存しないポストCookie時代の計測の仕組みへの理解、さらにそれらを導入していくためのプロジェクトマネジメントの役割が、インターネットを使ったマーケティング従事者に求められてきているのです。
Facebook広告のコンバージョンAPI（CAPI）とは？
前置きが長くなりましたが、このように広告の計測に利用されるCookieが制限されていく流れの中、Facebook社はCookieに依存しない計測方法であるコンバージョンAPI（CAPI）という仕組みを提供しています。
コンバージョンAPI（CAPI）の仕組みを端的に説明すると、Webサイトに実装されたFacebookピクセルタグの代わりに、広告主が持つクライアントサーバーからFacebook社の広告サーバーにイベントデータを直接送信する仕組みになります。
図3の③’で示すプロセスにおいて、広告主のクライアントサーバーからFacebook社の広告サーバーイベントを送信するための仕組みのことをコンバージョンAPI（CAPI）と呼びます。
コンバージョンAPI（CAPI）を利用すると、イベントの送信にFacebookピクセルを介さないので、デバイスや同意プラットフォームによるCookie利用の制限を受けたとしても、計測の精度を高く保つことができるようになります。
最終的にコンバージョンAPI（CAPI）で送信されたイベントと、Facebookに登録されているユーザー情報を突合させたうえで、広告からのコンバージョンとして計上する処理が行われます。
広告と接触した上でコンバージョンしたかどうかは、Facebook広告のクリックIDなどが用いられます。FacebookピクセルとコンバージョンAPI（CAPI）を併用する場合はピクセルから取得できますが、コンバージョンAPI（CAPI）のみでイベントを送る場合はFacebook広告のクリックIDをはじめ、Facebookピクセルで自動収集される情報がFacebook広告のサーバーに送信できるようになっている必要があります。
FacebookのコンバージョンAPI（CAPI）を導入できない場合は何が起きるのか？
コンバージョンAPI（CAPI）は技術的な開発や実装を伴うケースが多く、コンバージョンAPI（CAPI）を導入できないケースも発生するかもしれません。
その場合、記事の後半にて紹介する手動詳細マッチング（Manually implement Advanced Matching）という方法を採用することで、コンバージョン計測の精度を保つことも可能です。手動詳細マッチングは、既に利用しているFacebookピクセルをカスタマイズするだけで導入が可能なので、コンバージョンAPI（CAPI）と比較しても容易に実装できます。
しかしながらコンバージョンAPI（CAPI）を導入せず、手動詳細マッチングにも対応しなかった場合、Cookieの制限が強化されていくにつれ、コンバージョンの計測漏れ（欠損）の割合が拡大していく事が懸念されます。
コンバージョンの計測漏れが増えると見かけの広告費用対効果が下がるだけではなく、広告配信においても、広告アカウント内で確認できるコンバージョンに至ったというシグナルが弱くなることも意味します。
つまり、自動入札の機能においてコンバージョンをできるだけ多く得る、もしくは目標に近づけるために行われる機械学習に足る情報が得られなくなる事で、さらなる広告費用対効果の悪化を招くことになってしまいかねません。
コンバージョンAPI（CAPI）はどのように導入すればよいのか？を解説
コンバージョンAPI（CAPI）を導入するためには、いくつかの手順を踏む必要があります。
手順.1 どのような情報をコンバージョンAPI（CAPI）で送信するかを検討する
コンバージョンAPIにてFacebookのサーバーに送信が最低限必要になる情報（パラメーター）は下記3つになります。
- event_name：標準イベントまたはカスタムイベントの名前
- event_time：上記のイベントが発生した日時
- user_data：顧客に関する情報（下記の表のうち1つ以上が必要、利用できる項目が多いほどGood）
| Key Type | Key Name | 事前のハッシュ化 |
|---|---|---|
| em | 必要 | |
| Phone | ph | 必要 |
| Gender | ge | 必要 |
| Date of Birth | db | 必要 |
| Last Name | ln | 必要 |
| First Name | fn | 必要 |
| City | ct | 必要 |
| State | st | 必要 |
| Zip | zp | 必要 |
| Country | country | 必要 |
| External ID | external_id | 推奨 |
| Client IP address | client_ip_address | 不要 |
| Client user agent | client_user_agent | 不要 |
| Click ID | fbc | 不要 |
| Browser ID | fbp | 不要 |
| Subscription ID | subscription_id | 不要 |
| Lead ID | lead_id | 不要 |
| FB Login ID | fb_login_id | 不要 |
表1. user_data として送信可能なパラメータ一覧
※上記以外にも様々なパラメータが用意されているので、詳細は下記を参照ください
このうち、必須のパラメーターになっている event_name ではFacebook広告上で計測したい標準イベントやカスタムイベントを指定します。
同じく必須パラメーターとなっている user_data はFacebookアカウントとのマッチングを図るためのパラメータなので、user_data で送信できる情報が多ければ多いほどコンバージョン計測の精度も上がります。可能な限り情報を送信できるようにしましょう。
手順.2 送信するイベントのうちどのイベントをコンバージョンAPI（CAPI）で送信するかを検討する
手順.1で利用するイベント（event_name）で指定する予定の標準イベントまたはカスタムイベント）のうち、コンバージョンAPI（CAPI）で送信するイベントを決めます。
どのイベントをコンバージョンAPI（CAPI）で送信するかによって実装範囲やどのような構造にするかが決まり、大きく分けると次の①～④のいずれかに分類する事ができます。
①すべてのイベントをFacebookピクセルとコンバージョンAPI（CAPI）で送信する
すべてのイベントをFacebookピクセルとコンバージョンAPI（CAPI）で送信する実装です。
FacebookピクセルとコンバージョンAPI（CAPI）で2つのイベントが送信されてしまうため、event_id を使ってコンバージョンが重複計上されないような仕組みにする必要があります。
event_id は広告主側で任意で付与できる文字列のため、event_id の設計や付与ルールなどを広告主側で設計した上で実装する必要があるため、難易度は高めです。
②一部の重要なイベントのみFacebookピクセルとコンバージョンAPI（CAPI）で送信する
Purchase や CompleteRegistration など、コンバージョンとしてカウントしたい重要なイベントのみをコンバージョンAPI（CAPI）で送信するパターンです。
この場合もピクセルとコンバージョンAPI（CAPI）とのイベントの重複を考慮する必要がありますが、コンバージョンページでは注文番号や会員番号など個に紐付く識別子を利用するケースが多いので、①のケースよりは実装が行いやすいのが特徴です。
③重要なイベントはコンバージョンAPI（CAPI）で送信し、それ以外のイベントはFacebookピクセルで送信する
イベントの重複処理が難しい場合は、重要なイベントのページのみコンバージョンAPI（CAPI）だけ実装する方法もとれます。
しかしながらFacebookピクセルが実装されていないページでは、ピクセルで自動収集できていた event_source_url を送信する必要があるほか、 user_data の fbc（フェイスブック広告のクリックID）などの送信も任意ですが、筆者としては計測精度を高めるために送信することを強く推奨します。従って、これら追加のパラメータの送信も行えるような環境を構築する必要があります。
④すべてのイベントをコンバージョンAPI（CAPI）で送信する
Cookieに依存した計測から完全に脱し、コンバージョンAPI（CAPI）のみでまかなうパターンです。
この場合は③と同様に、Facebookピクセルで自動取得されていたパラメータである event_source_url は必須で送信、計測の精度を上げるために利用される user_data の fbc（フェイスブック広告のクリックID）の送信は任意ですが筆者としては強く推奨します。
このパターンで実装する場合は、Facebook社ではまずは①～③で実装して動作を検証した上で徐々に進めることを推奨しています。
手順.3 どのように実装するかを検討する
コンバージョンAPI（CAPI）で送信する情報やイベント、どのような構造で実装するかが決まったら、どのようにシステムとして実装するかを検討します。
実装方法は大きく分けて次の4つがあり、特別な開発を必要とせずに実装する方法も存在します。
- 統合できるパートナー（プラットフォーム）を利用する
- 自社で直接実装する
- Google タグマネージャーのサーバー用コンテナを利用する
- サードパーティの計測ツールを導入する
次からそれぞれの方法について簡単に説明します。
1．統合できるパートナー（プラットフォーム）を利用する
Facebookと統合できるパートナー（下記）と連携することで、複雑なコードを書くことなく導入することが可能です。
下記は2021年9月1日現在のものです。
| カテゴリ | プラットフォーム名 |
|---|---|
| Eコマース | Magento |
| Eコマース | Shopify (オンライン) |
| Eコマース | WooCommerce |
| ウェブサイトプラットフォーム | Cafe24 |
| ウェブサイトプラットフォーム | Makeshop |
| ウェブサイトプラットフォーム | Segment |
| ウェブサイトプラットフォーム | WordPress |
| カスタマーデータプラットフォーム | Tealium |
| データ接続プラットフォーム | Zapier |
| データ接続プラットフォーム | Conversions API Gateway |
| タグ管理 | Googleタグマネージャー(サーバーサイド) |
表2．統合できるパートナー一覧
2．自社で直接実装する
統合できるパートナーを利用していない場合は、コンバージョンAPI（CAPI）を利用してイベントデータがFacebookの広告サーバーに送信できる仕組みを広告主自らが用意する必要があります。
この場合においては、社内のシステム部門またはシステム開発などを委託しているパートナー会社と連携のうえ、仕組みを構築することになります。
システムの開発は利用しているクライアントサーバーやそのシステムよって開発方法が異なってくるため、本記事での詳説は割愛します。
3．Google タグマネージャーのサーバー用コンテナを利用して実装する
コンバージョンAPI（CAPI）を実装できるエンジニアが不在の場合は、Google タグマネージャーのサーバー用コンテナとGoogle アナリティクス 4（GA4）を利用することで、特別な開発が不要でノーコードでの実装も可能です。
こちらも実装方法の詳説は割愛いたしますが、Facebookから設定に関するドキュメント（英語）が提供されているので参考にしてみてください。
参考：Googleタグマネージャ用コンバージョンAPI - マーケティングAPI
Google タグマネージャーのサーバー用コンテナは、Google Cloud Platform の仕組みを利用するため、サーバー用コンテナ上のタグがコールされた回数に応じて料金が発生します。
Google タグマネージャーのサーバー用コンテナについては、下記、アユダンテ畑岡さんの記事を参考にしてみてください。
参考：GTMにサーバーサイドで動作するサーバー用コンテナが登場
4. サードパーティの計測ツールを導入する
SaaSベンダー各社から提供されている広告効果測定ツールやデータハブサービスの中には、コンバージョンAPI（CAPI）に対応しているツールも登場してきています。
毎月一定の費用はかかるものの、簡単に導入する事もできるようになっているので、サードパーティの計測ツールを導入するという方法も選択肢の1つとして検討しても良いでしょう。
手順.4 ファーストパーティデータの利用について、法務部と調整を行う
手順.1～手順.3 は実装に関する技術的な手順でしたが、コンバージョンAPI（CAPI）では顧客情報といったファーストパーティデータをFacebook社のサーバーに送信することから、こういったファーストパーティデータの扱いについて法務部門との調整を行う必要があります。
Facebook社に送信できるファーストパーティデータはハッシュ化（暗号化）が必要になっているものの、企業ポリシーとしてどこまでがFacebook社との共有がOKなのかは事前に決め、承認を得ておきましょう。
手順.5 コンバージョンAPI（CAPI）を使ったデータ送信テストを行う
手順.1～手順.3で技術的な実装が完了し、手順.4で法務部門からのデータ共有に関する承認を得られたら実際にコンバージョンAPI（CAPI）を使ったデータ送信テストを行います。
テストデータ送信したのちに、Facebookのイベントマネージャーでテストデータが受信されていることが確認できれば本番運用へ進むという流れになります。
コンバージョンAPI（CAPI）の実装が難しい場合は手動詳細マッチングの利用を検討する
コンバージョンAPI（CAPI）の実装ではWebサーバーの他にクライアントサーバーを用意したり、Facebook社の広告サーバーへファーストパーティデータを送る仕組みを用意したりすることが必要なため、その実装ハードルの高さからコンバージョンAPI（CAPI）の導入を断念せざるを得ないケースも存在するかと思います。
その場合、コンバージョンAPI（CAPI）の代わりに手動詳細マッチングを利用するという方法もあります。
手動詳細マッチングを利用すると、FacebookやInstagramアプリ上で広告をクリック、後にWebブラウザでコンバージョンするなど、アプリとWebブラウザの間でCookie情報が分断されるような環境下でも、精度高い計測を継続する事ができるようになります。
仕組みとしては、成果地点となるコンバージョンページが実装されているFacebookピクセルに数行のコードを追加するだけです。これによって、Facebookピクセルを通してFacebook社の広告サーバーにファーストパーティーデータを送信することが可能になります。
この手動詳細マッチングでFacebook社に送信できる情報は下記を参考にしてみてください。こちらもコンバージョンAPI（CAPI）と同様、利用できるファーストパーティデータの種類が多ければ多いほど精度が高くなります。
| ユーザーデータ | パラメーター | 書式 | 例 |
|---|---|---|---|
| メール | em | jsmith@example.com | |
| 名 | fn | 小文字 | john |
| 姓 | ln | 小文字 | smith |
| 電話番号 | ph | 国番号と市外局番のみを含む数字 | 16505554444 |
| 外部ID | external_id | 広告主からの一意のID (ロイヤルティメンバーID、ユーザーID、外部Cookie IDなど)。 | a@example.com |
| 性別 | ge | 小文字1文字のfまたはm、不明の場合は空白 | f |
| 生年月日 | db | 数字のみで表した生年月日 | 1991年5月26日の場合は19910526。 |
| 都市 | ct | 小文字、スペースは削除 | menlopark |
| 州 | st | 小文字2文字の州コード | ca |
| 郵便番号 | zp | 文字列 | 94025 |
| 国 | country | 小文字2文字の国コード | us |
表3．手動詳細マッチングで送信できる情報の一覧
コンバージョンAPI（CAPI）、手動詳細マッチングの実装方法ごとの注意点などのまとめ
ここまでコンバージョンAPI（CAPI）や手動詳細マッチングの導入手順について説明してきましたが、これらを表にまとめたものが次です。
※横へスクロールしてご覧ください
| 大種別 | 詳細マッチング | CAPI | |||
|---|---|---|---|---|---|
| 実装方法など | 手動詳細マッチング | 独自に実装する | GTMサーバーサイドタグを利用 | パートナー統合 | Shopifyなどのプラグインを利用 |
| 実装の工数 | 小～中 | 大 | 中 | 小 | 小 |
| エンジニアの工数 | 不要※メールアドレスなどがサイトから取得できる前提 | 大 | 中 | 不要 | 不要 |
| 費用 | 不要 | プログラムの開発や保守、別途サーバーを用意するのであればそちらのコストなど | Google タグマネージャーのサーバー用コンテナでは Google Cloud Platform を利用するため、サーバーの規模に応じてコストがかかる | 統合に利用するパートナーによる | 不要 |
| その他 | 既存のピクセルへ追加実装をするだけなので実装が容易 ただし、メールアドレスがタグマネージャーなどで取得できる前提のため、取得できない場合はすべてのページで取得できるようにHTML内にメールアドレスを取得できるように定義する必要がある |
先方のWEBシステムへ独自にCAPIへアクセスするための機能追加をする必要があるため、期間、費用がかなり掛かることが見込まれる | Google Cloud Platform、DNSの設定がスムーズにできれば、実際の導入作業自体は1週間程度 | 統合パートナーを利用している広告主に限る | Shopifyを利用している広告主に限る（ECサイトのみ） |
| ITP対策 | ○ | ○ | ○ | ○ | ○ |
| 広告ブロッカー、CVタグ未発火時にページを閉じられるなど対応 | ☓ | ○ | ☓※CAPIを利用しているが、ブラウザで発火するタグがベースとなっているため、影響を受けると考えられる | △※統合方法によっては影響を受ける可能性がある | ○ |
| 導入のしやすさ | ○ | ☓ | ○ | ○ ～ ◎※統合に利用するパートナーによる | ◎※ただし、Shopifyユーザーに限る |
表3. コンバージョンAPI（CAPI）、手動詳細マッチングの実装方法ごとの注意点など
コンバージョンAPI（CAPI）や手動詳細マッチングなど、Cookieに依存しないコンバージョン計測方法の導入パターンは複数ありますので、使っているサーバーやシステム（統合できるパートナーの有無）といった現在の環境を踏まえ、どのパターンで導入できるか検討してみましょう。
コンバージョンAPI（CAPI）や手動詳細マッチングは、導入コストを大きく上回るメリットがある
本記事の前半でも触れましたが、コンバージョンAPI（CAPI）や手動詳細マッチングが導入できない場合は、計測できるコンバージョン数が減ったり自動入札に必要なシグナルが弱くなります。
それに伴って、広告の費用対効果の悪化や配信ボリュームの減少などが起きやすくなり、最終的にFacebook広告への投資をやめざるを得なくなるという悪循環へ突入してしまうかもしれません。
言葉はとても悪いのですが、コンバージョンAPI（CAPI）や手動詳細マッチングの導入が進まない広告主が広告費用対効果の悪いFacebook広告への投資を次々とやめてしまう未来があるとすれば、これらCookieに依存しない計測方法を導入した広告主にとってはチャンスしか残りません。
競合となる広告主が減ることは、広告オークションに参加する広告主が減る可能性も示唆されます。つまり、これまでよりも安いCPMで広告配信ができるようになり、広告費用対効果が高まる事も考えられるわけです。
当然ながら、コンバージョンAPI（CAPI）や手動詳細マッチングを導入した広告主同士でこれ以上に競り合うという未来も想定できますが、その状況が訪れるのはコンバージョンAPI（CAPI）や手動詳細マッチングの導入がかなり進んだ状況になるはずですので、まずは早期に導入して先行者利益を享受するという考え方もできます。
他の広告プラットフォームもファーストパーティデータとAPIを使った計測へ
広告成果の計測を未だCookieに頼る広告プラットフォームも存在しますが、Facebookと同様にファーストパーティデータをAPIにて媒体プラットフォームと共有するという方法が今後の主流となる可能性は大いにありえます。
なぜなら、大手の広告プラットフォームの動向に目を向けてみると、Google 広告ではFacebook広告の手動詳細マッチングと同様に計測タグ（グローバルサイトタグ）を通してファーストパーティデータを送信して計測精度を向上させる拡張コンバージョン、およびコンバージョンAPI（CAPI）と同様にAPIを使ってファーストパーティデータ送信する拡張コンバージョンAPIのベータ版を提供し始めているからです。
参考：拡張コンバージョン（ベータ版）について - Google 広告 ヘルプ
参考：Enhance Conversions | Google Ads API | Google Developers
Google 広告の拡張コンバージョンAPIは、今のところ一部の広告主向けのオプションですが、将来的に一般利用が可能になればFacebook広告のコンバージョンAPI（CAPI）と同じ仕組みを使って、Google 広告でも計測精度向上が図れるようになると考えられます。
これからの運用型広告は、いかにして世の潮流を読み取り、テクノロジーを取り入れて運用を行うことができるかが大きなカギになります。
コンバージョンAPI（CAPI）や手動詳細マッチングの導入に関しては、目先の導入コストだけを見るのではなく、計測漏れが発生する点やそこからの広告費用対効果の悪化、広告への投資をやめた事による機会損失など長期的に発生する大きなデメリットも考慮して検討をしてみてください。
- 260
-
28
- 58
アナグラムのクルー
アナグラム株式会社のクルーです。広告運用のコンサルティングを手掛ける傍ら、リスティング広告やMeta広告などの運用型広告ネタの記事を執筆しています。より良い、正しい記事を運用型広告運用者へ素早く届ける！事がモットーです。
最近書いた記事
※本記事の著作権は執筆担当者の氏名の表示の有無にかかわらず当社に帰属しております
