オンラインストアで注文が完了したのに、Metaでは確認できない。かと思えば、別のときには同じ注文を2回認識している。チームは信頼できない数字を使ってキャンペーンを調整し、最初に「CAPIを実装すればすべて解決する」と考えます。
Conversions APIは、マーケティングイベントの一部をサーバー、CRM、またはプラットフォームからMetaのシステムへ直接送信することで、計測の精度を高められます。ただし、会社がそもそも生成していないデータを復元したり、名前の付け方が不適切なコンバージョンを修正したりすることはできません。まず計測計画が必要です。データ転送はその後です。
CAPIはPixelや同意の代替ではありません
MetaはConversions APIについて説明しています。これは、広告の計測と最適化に使う企業のマーケティングデータとシステムを、より直接的に接続する仕組みです。ウェブイベントでは、Meta PixelとCAPIを併用することが推奨されています。ブラウザ側とサーバー側の経路は、互いを補完できます。
だからといって、ブラウザが送信しなかったすべての情報をサーバーから送ってよいわけではありません。Metaは、CAPIがプライバシー規則、欧州の規制、プラットフォームの制限を回避するためのものではないと明確に示しています。具体的なデータ、地域、法的評価に基づき、同意と処理の適法性を扱ってください。ハッシュ化したメールアドレスも、個人に由来するデータであり、目くらましではありません。
まず、ビジネス価値のあるイベントを決める
オンラインストアでは通常、商品の閲覧からカート、チェックアウト、購入までの流れを計測する意味があります。リード獲得サイトでは、フォーム送信や有望なリードの発生のほうが重要かもしれません。送信できるからという理由だけで、すべてのクリックをコンバージョンとして送るべきではありません。
すべてのイベントについて、次の点を書き出してください。
- 現実の世界で何が起きなければならないのか、
- ビジネス上の主要な成果なのか、それとも単なる診断用シグナルなのか、
- どのシステムを正とするのか、
- どの一意識別子を使うのか、
- 広告とレポートに必要なパラメーターは何か、
- どの条件下でデータを送信できるのか。
購入の場合、正とする情報は、サンクスページを開いたことではなく、オンラインストアやバックエンドで確認された注文であることが多いです。リードの場合、フォームは最初のシグナルかもしれませんが、その連絡先の質を確認できるのはCRMだけです。
重複排除によって、二重計測が役立つかどうかが決まる
同じイベントをPixelとサーバーの両方から送る場合、Metaはそれを1件のイベントとして認識する必要があります。そのためには、両方の経路で同じイベント名と同じevent_idを使う必要があります。
購入であれば、安定した注文IDを基礎にできます。固有のビジネスIDを持たないイベントでは、アクションが発生した時点で一意識別子を作成し、ブラウザ層とサーバー層の両方に渡してください。双方で別々に生成したランダムな識別子では、値が一致しないため役に立ちません。
重複排除は開発者だけの細かな問題ではありません。失敗すると、キャンペーンに二重のシグナルが送られ、レポートが誤った情報を示し始めます。
4つの実装方法には、それぞれ異なるコストがある
パートナーまたはeコマースプラットフォームの機能
一般的なオンラインストアでは、これが最初の選択肢になることが多いです。プラットフォームが連携を継続的に管理するため、会社がAPIコードを保守する必要はありません。それでも、どのイベントを送信するのか、重複排除と同意に対応しているのか、パラメーターを確認できるのかをチェックしてください。
マネージドサービスまたはゲートウェイ
プロバイダーがインフラの一部と更新を引き受けます。運用費用と依存関係を負担する代わりに、自社での技術的な保守を減らせます。サービスが自社の技術スタックに対応し、診断情報へ明確にアクセスできるなら、合理的な選択です。
サーバーサイドGoogle Tag Manager
サーバーコンテナを使えば、複数のマーケティングデータ転送を統合し、会社の管理性を高められます。一方で、ホスティング、テンプレート、権限、そしてテストが必要な新たな場所が増えます。見栄えのよいアーキテクチャ図だけを理由に選ぶべきではありません。
カスタムの直接連携
柔軟性が最も高い一方で、責任も最大になります。安全なトークン管理、入力検証、機密データを漏らさないロギング、エラーからの復旧、APIバージョン管理、そして連携を保守する担当者が必要です。
元の記事では、短いPHPスクリプトと一般公開されたエンドポイントを紹介していました。しかし現在は、一般的なガイドとしてその方法を推奨していません。古いAPIバージョンに依存し、安全性と運用面で多くの仮定が含まれていたためです。コピーしたコードが今日動いていても、明日にはイベントをひそかに取りこぼす可能性があります。直接連携では、Metaの最新ドキュメントを基に通常の開発を行ってください。コピー＆ペーストのマーケティングでは不十分です。
パラメーターの数よりもイベントの品質が重要
サーバーサイドイベントには通常、イベント名、時刻、アクションの発生元、そして発生元に応じたURLやその他のコンテキストが必要です。ビジネスイベントには、関連する価値、通貨、商品、安定したIDを追加します。ユーザー識別子は、保有する正当な権利があり、正規化され、必要な形式になっている場合にのみ送信してください。
識別子を増やすとマッチングの精度が向上することがありますが、限度を考えなければ「多いほどよい」というわけではありません。空の値、作り物の値、古い値は送らないでください。もちろん、ユーザーの選択を回避するためにフィンガープリントを作成してはいけません。
テストではユーザーの全行程を確認する必要がある
- Meta Events Managerでテストモードを開始します。
- ウェブサイトへの訪問から注文またはリードの発生まで、実際のシナリオを完了します。
- ブラウザ側とサーバー側のイベント、それらのパラメーター、マッチングIDを確認します。
- Metaがその組み合わせを重複排除し、診断エラーを表示しないことを確認します。
- 価値、通貨、IDをバックエンドまたはCRMと比較します。
- 採用したソリューションに応じて、同意する場合と拒否する場合の両方をテストします。
- 導入後は、1回のテストが成功したかだけでなく、診断情報と時間経過による欠落を監視します。
Test Eventsは、技術的なメッセージが到着したことを確認します。しかし、正しいコンバージョンを選択したことや、連携が法令に準拠していることまでは確認しません。
CAPIとGA4は異なるレイヤーです
CAPIは、計測と広告の最適化のためにイベントをMetaへ送信します。GA4は、複数のソースにまたがってウェブサイトとアプリを分析します。アトリビューション、同意、ID、処理方法の違いにより、数字は異なる場合があります。私はそれらを無理に完全一致させようとはしません。まず各システムが技術的に正しいデータを受け取り、それを正しい意思決定に使っていることを確認します。
費用とウェブサイトの成果を共通の概要で確認したい場合は、Meta AdsとGA4を連携する方法もお読みください。Google Tag Managerのガイドではタグの実装自体を扱い、GA4のガイドではイベントの意味を説明しています。
まだCAPIを実装しないほうがよい場合
会社がコンバージョンを定義していない、どの注文が有効なのか分からない、または現在のPixelすら維持できない状態でサーバー側の経路を追加すると、混乱が増すだけです。まず元データと計測計画を修正してください。どのシグナルを届けたいのか、なぜMetaに必要なのか、誰が連携を管理するのかが分かっているときに、CAPIは意味を持ちます。
オンラインストアやリード獲得サイトに適した、最小限で合理的なソリューションを選びたい場合は、プラットフォーム、現在の計測設定、そしてビジネスにとって最も重要なイベントをお問い合わせフォームからお送りください。