X広告のコンバージョンAPI｜GTM設定と重複計測の確認
X広告のコンバージョンAPIは、購入や問い合わせなどのサイトの成果を、サーバー経由でXへ送る仕組みです。導入時は送信に成功することだけでなく、ブラウザーのX Pixelと同じ成果を二重に数えないことも確認します。XのWebコンバージョン資料
Xは2026年9月17日の更新履歴で、Googleタグマネージャー（GTM）のサーバーコンテナ向け公式テンプレートを案内しました。コンバージョンAPIそのものの新設ではなく、GTMで導入するための選択肢の更新です。Xの更新履歴
この記事では、導入を依頼する前に決める内容と、重複計測の確認表を紹介します。公式案内に基づく準備手順であり、実際の広告アカウントへ設定を適用した記録ではありません。
Webコンテナだけでは導入できない
使うテンプレート名は「X Ads Conversion API (Official)」です。サーバーコンテナ専用で、イベントの受信、Xへの送信を設定します。認証にはイベントマネージャーで発行するPixelアクセストークンを使います。XのGTM設定ガイド
GTMのサーバーコンテナには、イベントを受けるタグ配信サーバーが必要です。すでにWebコンテナをサイトに入れていても、それだけでサーバー側の環境が用意できたことにはなりません。GoogleのサーバーサイドGTM概要
そのため、担当者は「タグを追加してほしい」という依頼に加え、サーバーの管理者、運用費の確認先、エラー時の連絡先まで決めておくと、導入後も確認を続けられます。
先に、何を成果として送るかを決める
以下は、架空の問い合わせサイトで導入準備に使う表です。数値や計測結果は置いていません。
| 決めること | 問い合わせサイトの例 | 確認する相手 |
|---|---|---|
| 成果が発生する瞬間 | フォームの送信処理が成功したとき | サイトの実装担当者 |
| 成果に含めない操作 | 入力エラー、ボタンのクリックだけ | 広告・サイト担当者 |
| 送信するイベント | 問い合わせ完了 | 広告担当者 |
| 同じ成果を見分ける値 | 送信完了ごとに発行する識別子 | 実装担当者 |
| 計測を許可しない状態 | 自社で定めた利用者の選択に応じる状態 | 計測設定の責任者 |
| 検証用のデータ | テストと分かる問い合わせ | 問い合わせ対応者 |
フォームを送信する前のボタンクリックを成果にすると、送信エラーも混ざります。APIを使うかどうかとは別に、成果の定義を広告とサイトの担当者で合わせてください。
Event IDとConversion IDを混同しない
X PixelとコンバージョンAPIで同じ成果を送る場合は、同じイベントのEvent IDと、共通のconversion_idを使って重複を排除します。API用だからと別イベントを作ってしまうと、同じ成果として合わせる設計になりません。既存イベントと重複排除の説明
| 識別子 | 意味 | 架空の値の使い分け |
|---|---|---|
| Pixel ID | X側のイベントソース | 対象アカウントのイベントソースを選ぶ |
| Event ID | イベントマネージャーで用意した成果のイベント | 問い合わせ完了のイベントを指定する |
| Conversion ID | 個々の成果を見分ける重複排除用の値 | 送信Aはlead-example-a、送信Bはlead-example-b |
表の値は説明用です。Aをブラウザーとサーバーから送るなら、両方にAの値を渡します。新しい問い合わせBには別の値を使います。経路ごとに独立して値を発行すると、同じ問い合わせか判別できなくなります。
メールアドレスのように人を見分ける値と、問い合わせの発生を見分ける値も分けて考えます。同じ人が別の問い合わせをする場合まで、同じ成果としてまとめないためです。
GTM設定を依頼するときの流れ
サイトからサーバーコンテナへイベントを送ると、Clientがリクエストを受けてイベントに変換します。GA4の経路を使う場合も、まずサーバー側で受信できるかを確認します。Googleのイベント送信手順
公式テンプレートはサーバーコンテナのテンプレートギャラリーから追加します。Pixel ID、トークン、対象イベントを設定し、Web側とサーバー側のプレビューで確認する流れです。GA4の送信先をサーバーへ変更する場合は、GA4へ送り続けるタグも必要です。Xの設定・検証手順
作業依頼には、設定項目だけでなく次の確認も添えてください。
- 既存のX PixelとGA4が、現在どの操作を成果として扱っているかを書き出す。
- 今回送るイベントを決め、別の成果やページ閲覧を混ぜない。
- 同じ成果の識別子を、ブラウザーとサーバーで共有する設計を確認する。
- テスト結果と、公開前に戻す方法を用意する。
- 公開後の確認担当者を決め、設定変更を記録する。
この順番は、担当者が実装内容を確認するための筆者の提案です。アカウントに合う具体的な設定値は、公式手順と現在の構成を見ながら決めます。
重複計測のテスト表
問い合わせを一度送った後、複数の画面に送信記録があること自体は異常ではありません。PixelとAPIの両方から送った記録と、広告の成果として最終的に集計される件数を分けて確認します。
| 試す操作 | 確かめること | 不一致なら見直す箇所 |
|---|---|---|
| テスト問い合わせAを正常に送る | 同じAが両経路へ渡る | 成果の発生条件と識別子の受け渡し |
| Aの完了画面を再表示する | 新しい成果として誤送信しない | ページ表示に依存した発火条件 |
| 別のテスト問い合わせBを送る | BがAと区別される | 固定値になっていないか |
| 入力エラーで送信に失敗する | 完了として送らない | ボタンクリックと送信成功の区別 |
| 計測を許可しない選択をする | 自社で定めた送信方針と一致する | Web側とサーバー側の条件 |
| GA4の対象イベントを見る | 既存の分析経路も維持されている | サーバーからGA4へ送る設定 |
APIの成功応答は、広告に成果が帰属してレポートへ計上されたことと同じではありません。送信、受信、重複排除、広告レポートを順に確認し、期待した結果と違う段階を特定します。
AIは確認表の整理に使う
計測がそろったら、AIへ渡す広告データの範囲も決めます。管理画面の結果をAIと連携する方法は、MCPでマーケティングデータを扱う際の確認事項を参照してください。
生成AIには、トークンや顧客のデータを渡さず、匿名化した設計を読ませます。次は筆者作成の確認用プロンプトです。
次のX広告の計測設計を読み、未確認の項目を整理してください。
設定変更や公開操作は実行しないでください。
成果の定義：[いつ成功とするか]
既存の計測：[X PixelとGA4の概要]
追加する経路：[サーバーからXへ送る概要]
識別子の共有方法：[個人情報を含まない説明]
検証結果：[匿名化した確認表]
成果の定義、重複、再送、GA4の継続、利用者の選択について、
確認済み／未確認／担当者へ質問が必要、に分けてください。
記載がない設定値や結果は推測しないでください。
明日は、現在の成果の定義と、同じ成果を見分ける値を実装担当者に確認してください。商略AIのチャットでは、事業情報と依頼内容を踏まえた文章案を作れます。GTMの設定は担当者が行い、確認表や作業依頼文の整理に活用できます。