本記事では、ChatGPT広告（OpenAI Ads）の計測タグをGoogle タグマネージャー（GTM）で実装する方法と、実装時に注意したいポイントをまとめます。
公式ドキュメント
https://developers.openai.com/ads/measurement-pixel
OpenAI Adsの計測は2系統ある
最初に整理しておきたいのが、OpenAI Adsの計測方式は2つあるという点です。
- JavaScript Pixel — ブラウザ側で動く計測タグ。サイトに設置します。
- Conversions API — サーバー側からイベントを送信する方式。自社サーバーやサーバーサイドGTMから叩きます。
タグを発行する人（広告運用者など）と実装する人が分かれている場合、実装側は発行側から計測コードを受け取ることになります。このとき、呼び方が人によって異なるかもしれません。
ChatGPT広告の管理画面（Ads Manager）では、「セットアップコード」と「コンバージョンイベントのコード」という名前で表示されます。一方、タグを渡す人からは、他の広告媒体と同じように「ベースタグ」「コンバージョンタグ」と呼ばれることも少なくありません。呼び方は違っても、前者はサイト全体に置くPixelの初期化コード、後者はコンバージョンごとに置く計測コードを指しています。名前ではなく役割で捉えておくと混乱しません。
本記事ではブラウザ側のJavaScript Pixelのみを扱います。
実装方法は2択 — カスタムHTMLか公式テンプレートか
GTMでPixelを実装する方法は2つあります。
- カスタムHTMLタグ — 管理画面で発行したコードをそのまま貼る。
- 公式GTMテンプレート — コミュニティテンプレートギャラリーにあるOpenAI公式テンプレートを使う。
筆者としては、公式テンプレートを推奨します。理由は後述しますが、カスタムHTMLには発火順序やタグの囲い方など、いくつかの落とし穴があります。公式テンプレートは各タグが自己完結する設計になっており、これらの問題を回避できます。（CSPを考慮した場合も、カスタムHTMLよりもテンプレートが良いですよね）
以下、公式テンプレートを使う方法で進めます。
その「公式テンプレート」、本当に公式か
公式テンプレートを使う前に、必ず確認したいことがあります。それが本当にOpenAI公式のテンプレートかという点です。
コミュニティテンプレートギャラリーには、OpenAI公式のほかに、第三者が作成した同名・類似名のテンプレートが複数存在します。名前に「OpenAI Ads Measurement Pixel」と付いていても、OpenAI公式とは限りません。
重要なのは、偽装できる部分とできない部分を区別することです。
偽装できる部分（これだけでは公式の証拠になりません）:
- ブランド名（openai と名乗ることは誰でもできます）
- アイコン（OpenAIロゴを貼ることもできます）
- 説明文・テンプレート名
偽装できない部分（これが本物の証拠になります）:
- 作成者バッジ — テンプレート詳細の「作成者: openai」の横にあるチェックマーク。
- リポジトリの所有者 — テンプレート詳細の「リポジトリ」リンク先が github.com/openai/ads-measurement-pixel-gtm-template のように、openai 組織アカウント直下にあること。第三者は自分のアカウント配下にしか置けません。 GitHubページ
- ドメイン検証 — 作成者バッジにマウスオーバーすると「openai は github.com により、次のドメインの管理者であることが確認されました: https://openai.com/」と表示されます。これはドメイン所有権の検証であり、詐称できません。
この3つが揃えば、OpenAI公式テンプレートと判断してよいでしょう。特に3つ目のドメイン検証は決定的な証拠になります。
公式テンプレートの設定
真偽が確認できたら、テンプレートをインポートします。すでにギャラリーに公開されていれば、GTMの「テンプレート」→「タグテンプレート」→「ギャラリーを検索」から追加できます。
このテンプレートは、1つのタグでPixelの読み込み（初期化）とイベント送信の両方を行う設計になっています。カスタムHTMLのように初期化タグと計測タグを分ける必要はありません。（前者は「init」、後者は「measure」の部分）
設定する項目は少ないです。
- Pixel ID — 発行されたPixel IDを入力します。
- Send a measurement event when this tag fires — このタグでイベントを送るかのチェック。計測タグはオンにします。
- Enable setup diagnostics in the browser console — Pixelの動作状況をブラウザの開発者コンソールにログ出力する診断オプション。後述します。
- Event Name — 送信するイベントを選びます。標準イベントのドロップダウン、または custom。
- Custom Event Name — custom を選んだときだけ入力する固有のイベント名。
- トリガー — そのイベントを発火させる条件。
type（customer_action など）を設定する欄がないことに気づくかもしれません。これはイベント名ごとにtypeが固定で決まっているため、テンプレートが自動で補完してくれるからです。ユーザーが選ぶ必要はありません。
「Enable setup diagnostics in the browser console」は、設定・検証中だけオンにして使う診断オプションです。オンにすると、初期化やイベント送信の状況がブラウザのコンソールに出力され、正しく動いているかを確認できます。本番ではオフにするのが基本です。オンのままでも計測は動きますが、コンソールにログが出続けるため、GTMのプレビューモードで動作確認をしたら、公開前に外しておきます。
全ページ計測とコンバージョンタグ
基本の構成は次のようになります。
- 全ページ計測 — Event Name を page_viewed にして、トリガーは「All Pages」や「指定したドメインのトリガー」に設定します。これがサイト全体の基本計測になります。
- コンバージョンタグ — 計測したいCVごとにタグを1つ作り、Event Name を適切なイベント（または custom）にして、そのCVが完了したタイミングでのみ発火するトリガーを設定します。
コンバージョンタグを全ページで発火させると、CVしていないユーザーまで計上されてしまいます。トリガーは必ず完了ページや完了イベントに絞ってください。
つまずきポイント① 管理画面発行の計測タグをそのままカスタムHTMLに貼る
公式テンプレートを使わず、コンバージョン計測タグをGTMのカスタムHTMLタグに貼る場合、最初に引っかかりやすいのがこれです。
ChatGPT広告の管理画面（Ads Manager）でコンバージョン用の計測タグを発行すると、次のような形式で出力されます。
oaiq(“measure”, “purchase_completed”, { type: “customer_action” });
これは <script> タグで囲まれていない、JavaScriptの生のコードです。実際、公式ドキュメントでも oaiq(“measure”, …) の例は <script> で囲まずに記載されています（<script> で囲われているのは<head>に置く初期化スニペットだけです）。
GTMのカスタムHTMLタグはHTMLを書く場所なので、この生のJavaScriptをそのまま貼っても、ブラウザはただのテキストとして扱い、実行されません。発行されたコードをコピーして貼るだけで動くと思い込むと、ここで取りこぼします。
カスタムHTMLで実装するなら、必ず <script> で囲う必要があります。
<script>
oaiq(“measure”, “purchase_completed”, { type: “customer_action” });
</script>
公式テンプレートを使えばコードを直接書かないため、この問題自体が発生しません。
つまずきポイント② 発火順序（カスタムHTMLの場合）
これもカスタムHTML特有の落とし穴です。
Pixelの実装は、初期化コード（Pixelを読み込む部分）とCV計測コード（oaiq(“measure”, …)）に分かれます。発行側から受け取るときも、この2つが別々に渡されることが多いです。CV計測コードは「すでにPixelが読み込まれている」前提で動くため、初期化コードより先に発火するとoaiqが未定義でエラーになり、イベントを取りこぼします。
つまりカスタムHTMLでは、初期化コードがCV計測コードより先に実行されることを保証しないといけません。GTMの「初期化」トリガーを使う、タグの順序付けを設定する、といった対応が必要になります。
公式テンプレートは各タグが自分で初期化から行うため、この順序を気にする必要がありません。これがテンプレートを推奨する大きな理由のひとつです。
つまずきポイント③ イベント名の選び方
ここからはテンプレート・カスタムHTMLに共通する、イベント設計の話になります。
標準イベントには、それぞれ想定された意味とtypeがあります。主なものは次のとおりです。
| type | 該当イベント（一部） | 用途 |
| customer_action | lead_created, appointment_scheduled, registration_completed | 問い合わせ・予約・登録などのアクション |
| contents | order_created, checkout_started, page_viewed, contents_viewed | 購入・カート・閲覧などEC系 |
| plan_enrollment | subscription_created, trial_started | サブスクリプション系 |
ここで、計測したいCVと意味の合ったイベントを選ぶことが重要になります。発行側から受け取ったコードでも、次のようなミスマッチが起きていることがあります。
- BtoBのお問い合わせに order_created（購入完了）を使っている
- お問い合わせに page_viewed（ページ閲覧）を使っている
- 予約完了に trial_started（サブスクのトライアル開始）を使っている
たとえばBtoBサイトのお問い合わせはlead_created、ECサイトの購入完了はorder_created、というように、CVの実態に合ったイベントを選びます。
つまずきポイント④ 同じイベント名は合算される
複数のCVを計測するときに知っておきたい仕様があります。
OpenAI Adsはイベント名（標準イベント名、またはcustomのcustom_event_name）ごとにコンバージョンを集計・最適化します。つまり、同じ標準イベント名を複数の異なるCVに使うと、それらは別々に分けられず1つのバケツに合算されます。
たとえば「来店予約」と「イベント予約」の両方にappointment_scheduledを使うと、レポート上は合算された「予約」1本になり、それぞれの件数を分けて見ることができません。広告の学習も、この合算されたバケツに対して回ります。
CVを分けて計測・最適化したい場合は、custom イベントにして固有のcustom_event_nameを付けます。
<script>
oaiq(“measure”, “custom”, { type: “custom” }, { custom_event_name: “store_visit_reservation” });
</script>
custom_event_name は小文字・数字・アンダースコア・ハイフンで、1〜64文字というルールがあります。
すべてをcustomにする必要はありません。意味の合う主要なCVは標準イベントを使い、細かく分けたいものだけcustomにする、というハイブリッドが現実的です。ポイントは、同じ標準イベント名を重複させないことです。
なおcustomイベントは、GTMで設定したあとにAds Manager側でコンバージョン目標として登録する操作が別途必要になります。運用担当者と連携しておくとよいでしょう。
まとめ
公式GTMテンプレートを使えば、Pixelの実装自体はPixel IDとイベント名を設定するだけでシンプルに済みます。
- 使うテンプレートがOpenAI公式か確認する
- CVの実態に合った標準イベントを選ぶ
- 分けて計測したいCVはcustomイベントで固有名を付ける
以上となります。
同じように計測タグの実装を担当する方のお役に立てれば幸いです。
コメント