Google Ads と Meta の成果を足すと注文数を超える。どう集計する？

Google Ads の購入件数と Meta の購入件数を足したら、受注システムの注文数より多くなった。月次報告でよく困る場面ですが、まずタグの不具合を疑うだけでは原因を見落とします。二つの媒体が、同じ注文をそれぞれ自分の広告成果として計上している可能性があるためです。

目指すのは、すべての数字を無理に一致させることではありません。事業として受けた注文、各媒体が報告する成果、根拠をもって照合できた範囲を分けると、経営会議でも説明できるレポートになります。

同じ注文が、なぜ両方の成果になるのでしょうか？

購入までに Google の広告をクリックし、別の日に Meta の広告を見る人もいます。それぞれの計測期間やアトリビューションのルールを満たせば、一つの注文が両方の報告値に入ることがあります。これは独立したルールで成果を割り当てる仕組みから生じるもので、差があるだけで不正や計測障害とは判断できません。

一方、同じ購入イベントをブラウザーとサーバーから送る際の二重送信は、別の確認項目です。各実装の文書に従って重複排除を点検します。Google の transaction_id は、同じコンバージョン アクション内の重複防止に使えますが、Google と Meta の間で注文を重複排除する機能ではありません。ID は注文ごとに一意で安定したものとし、個人情報を含めないようにします。

照合を始める前に、何をそろえる？

まず両媒体と受注システムの元データを保存し、取得日時を残します。比較する期間だけでなく、タイムゾーン、日付の基準、対象イベント、コンバージョン アクション、実際の計測期間とモデルまで確認してください。通貨、税金、送料、キャンセル、返金をどう扱うかも先に決めます。

Google Ads の通常のコンバージョン列は、広告との接点があった日を基準に集計されます。注文日ベースの台帳と比べる場合は、コンバージョン発生時刻に基づく列も確認します。ただし、日付を合わせても成果の割り当て方の違いは残ります。処理や推計によって報告値が更新されることもあるため、取得日時の記録が必要です。

Meta は2026年にクリック経由とエンゲージメント経由の計測に関する変更を発表しています。適用時期は広告主によって異なるため、一律の初期設定を前提にせず、その時点のエクスポートでクリック、表示、エンゲージメントの定義と期間を確かめます。

6件の注文から、7件の広告成果が出る例

以下は仕組みを説明するための架空のデータです。注文日はすべて2026年9月1日、タイムゾーンは UTC、通貨はユーロ。6件とも支払い済みの対象注文で、金額は税金と送料を含まず、返金はありません。注文ごとの媒体別の根拠も説明用に用意しています。通常の媒体エクスポートで、このような完全な対応表が得られるという意味ではありません。

受注台帳は6件・700ユーロ。Google の成果は4件・570ユーロ、Meta は3件・300ユーロなので、単純に足すと7件・870ユーロです。A100 と A103 が両方に含まれ、重複は2件・220ユーロあります。

少なくとも一方の媒体に対応する注文は、4 + 3 − 2 = 5件、金額は650ユーロです。どちらにも対応する記録のない A104 の1件・50ユーロを加えると、受注台帳の6件・700ユーロになります。金額でも 570 + 300 − 220 + 50 = 700 と確認できます。

ここで大事なのは、7件と6件の差である1件が、重複件数ではないことです。実際の重複は2件あります。また、この計算は同じ条件の注文単位の記録がそろっている場合に限ります。小数の成果配分やモデルによる推計を含む媒体の合計値だけから、注文の重なりを求めることはできません。

照合できない注文を、ゼロ扱いしない

事業実績は、受注台帳や顧客管理システムから、合意した支払い・キャンセル・返金の条件に合う注文を抽出して作ります。注文IDで一意に数えた件数と金額は事業側の基準になりますが、どの広告が購入を引き起こしたかを証明するものではありません。アトリビューションと増分効果は分けて評価します。

利用が認められた自社データに照合の手掛かりがあれば、その範囲で確認し、根拠を記録します。Google Ads の標準レポートに注文単位の完全な成果対応があるとは限らず、transaction_id も通常の注文別レポートとして取得できる項目ではありません。証拠が見つからないことは、広告の影響がなかった証明にはなりません。

ダウンロード用の表では、1 は確認済みの成果対応、0 は確認した記録の範囲でその媒体への成果計上がないと確認できたことを表します。実務用テンプレートの空欄は不明、または根拠不足です。ファイルは手元で編集し、顧客名やメールアドレスを入れたり、顧客データを公開したりしないでください。

AIには下準備と説明を任せ、計算は検証できる形にする

AI は、列名の対応付け、必須項目の抜けの確認、検証済みの結果からの報告文作成に役立ちます。ただし、「売上」と「購入額」の列名が似ていても、片方だけ送料を含んでいるかもしれません。提案された対応関係は担当者が確認します。

件数、合計金額、重複の計算には、同じ入力なら同じ結果になる数式やコードを使います。AI に渡すのは必要最小限の匿名データにとどめます。取得できない顧客のつながりを復元したり、集計値から架空の対応行を作ったり、真の因果的な貢献を決めたりする用途には使いません。

翌月も説明できるレポートにするための確認事項

最終レポートには事業の対象注文数・金額、Google の報告値、Meta の報告値を並べます。注文単位の根拠がある場合だけ、確認できた重複と照合範囲を追加します。対応しない部分、推計の部分、集計値しかない部分は、前提とともに明記してください。

1. 対象期間、タイムゾーン、日付の基準、取得日時を記録する。
2. 対象注文の条件、通貨、税金・送料・返金の扱いをそろえる。
3. 媒体別のイベント、計測期間、モデル、現在の定義を残す。Google のコンバージョン アクションがメインかサブかも確認する。
4. 二重送信の確認結果と、媒体間で照合できた重複を分ける。
5. 不明な項目、次に確認すること、確認者を記録する。

この集計を毎月続けるなら、対象を一つに絞って業務の流れを整える方法があります。MindVerve の AI 業務導入支援（AI Workflow Launch）では、合意したデータ源とルールをもとに例外もテストし、レビューと引き継ぎまで含めて進めます。