広告管理画面ではコンバージョンが表示されているのに、ウェブサイトの管理画面では該当する注文が見つからない。あるいは、管理画面には問い合わせが届いているのに、Facebook広告ではゼロと表示される。Facebookのコンバージョン差異が発生しても、すぐにピクセルを再インストールする必要はありません。両方の画面で異なる行動を計測している可能性もあれば、アトリビューション期間や日付の基準が異なる場合もあります。もちろん、実際に計測漏れや重複送信が起きている可能性もあります。
確認の目的は、2つの数値を無理に一致させることではなく、実際のビジネス成果がどれだけ発生したか、イベントが正確に送信されたか、そのうち何件がMetaによって広告にアトリビューションされたかを確認することです。
広告マネージャ、イベントマネージャ、ウェブサイトの管理画面を開き、同じ期間のデータを並べて確認します。注意すべきなのは、イベントマネージャで受信したイベントの総数と、広告マネージャで広告にアトリビューションされたコンバージョン数は同じではないことです。前者には自然検索や直接訪問などの流入元が含まれる場合がありますが、後者には広告のアトリビューション条件を満たした結果のみが表示されます。
海外取引の問い合わせ獲得サイトでは、特に「送信ボタンのクリック」と「問い合わせ情報の登録」を混同しやすい傾向があります。たとえば、銀行のウェルスマネジメント体系の最適化に関する研究のような資料ページをプロモーションする場合、詳細ページの閲覧、資料のダウンロード、問い合わせの送信はそれぞれ異なる行動です。すべてを有効な問い合わせとして集計してはいけません。
ユーザーがFacebook広告を見てもクリックせず、翌日に検索経由でウェブサイトにアクセスして購入したとします。現在のアトリビューション設定などの条件を満たす場合、Metaはこの購入を広告にアトリビューションすることがあります。一方、ウェブサイトの管理画面では検索経由として記録される場合があります。
広告セットを開き、実際に適用されているアトリビューション設定を確認します。また、アカウントで利用可能なレポート機能を使って、クリック経由とビュー経由のアトリビューションを比較してください。すべての広告キャンペーンで同じ期間が適用されていると思い込まないようにしましょう。UTMパラメータはクリック経由の訪問を識別するのに役立ちますが、ビュースルーアトリビューションを完全に説明することはできません。
Meta PixelとコンバージョンAPI(CAPI)を併用している場合、同じビジネスイベントがブラウザーとサーバーからそれぞれ送信されることがあります。プラットフォームが重複を判定できるよう、両方で対応するイベントに同じevent_nameとevent_idを使用してください。
重点的に確認する項目:ブラウザーとサーバーで別々のIDが生成されていないか、注文完了ページの再読み込みで購入イベントが再度発生していないか、プラグイン、タグマネージャー、ウェブサイトのコードが重複して設置されていないか。同じビジネスイベントのIDは一致させ、異なるビジネスイベントは識別できるようにする必要があります。再試行のたびに新しいIDを生成してはいけません。

日ごとの集計値だけに注目しないでください。承認を得た追跡可能なテスト問い合わせまたは注文を1件選び、ページへのアクセスから管理画面への登録までの流れを確認します。その際、時刻、注文番号または問い合わせ番号、イベントIDを記録してください。次に、ブラウザーのデバッグツールとMetaのテストイベント機能を使って、データの流れを確認します。
ブラウザーの制限、広告ブロッカー、ユーザーによるマーケティング追跡の拒否などにより、観測可能なイベントが減少することがあります。クロスドメインの決済、外部決済サービス、ページ遷移の過程で流入元パラメータが失われることも、経路の識別に影響します。CAPIはサーバー側のシグナルを補完できますが、ユーザーの同意要件を回避することはできず、すべてのコンバージョンがアトリビューションされることを保証するものでもありません。
マッチング品質が低い場合は、適法に取得した顧客情報が要件に従って正規化されているか、利用可能なfbp、fbcなどのパラメータが正しく引き渡されているかを確認します。クリック識別子を偽造したり、マッチングスコアを上げるために不要な情報を収集したりしてはいけません。
広告アカウントとウェブサイトの管理画面で異なるタイムゾーンが使用されている場合、夜間に発生した同じ注文が異なる日付に計上されることがあります。一部の広告レポートでは広告とのインタラクションが発生した日付に基づいてアトリビューション結果が表示される一方、業務管理画面では通常、注文、支払い、送信の各日付に基づいて記録されます。現在のレポートの集計基準を確認してください。
発生したばかりのコンバージョンは、処理や反映が完了していない場合もあります。一定の処理時間が経過した期間を使って照合し、毎回同じタイミングでデータをエクスポートしてください。ウェブサイト側では返金、キャンセル、迷惑問い合わせを除外しているのに、広告レポートには元のイベントが残っている場合も、差異が生じます。管理画面でステータスが変わっても、返金が広告コンバージョンから自動的に差し引かれるとは限りません。
最低限の照合表を用意することをおすすめします。項目には、ビジネス識別番号、発生日時とタイムゾーン、ビジネスの状態、イベント名、イベントID、送信方法、流入元パラメータを含めます。複数人で共有する表に、顧客の個人情報を平文で記載しないでください。まず実際のビジネス成果を確認し、次にイベントの送信を確認し、最後に広告のアトリビューションを分析します。複数の設定を同時に変更するより、問題を特定しやすくなります。
易營宝のようなウェブサイト構築・マーケティング一体型サービスを利用する企業は、この記録をもとに、ウェブサイト開発、広告運用、管理画面の担当者が連携できます。フォームの送信成功の基準、注文ステータス、イベントルールを統一し、サイトのリニューアル、プラグインの変更、多言語ページの追加後には、毎回テストを実施してください。
すべてのアカウントに当てはまる「正常な差異の割合」はありません。特に注意すべきなのは、差異が急に拡大する、特定のイベントがゼロになる、1回の送信で複数の購入イベントが発生するといった状況です。Facebookのコンバージョン差異を解消するうえで重要なのは、数値を見栄えよくすることではありません。各段階のデータに根拠を持たせることが、広告予算を適切に判断するための確かな基盤になります。
関連記事
関連製品


