アドエビス、CATS、GTM、gclid、YCLID、ポストバック――日本のWeb広告は「広告を出す」より計測の方がややこしい
Webマーケティングというと、
Google広告。
Yahoo!広告。
Meta広告。
LINE広告。
TikTok広告。
などを想像する人が多いと思います。
そして、
「CPAを見て広告を止める」
「ROASを比較する」
「クリエイティブをABテストする」
みたいな話になる。
しかし、広告運用を実際にやっていくと、その手前にかなり面倒な問題があります。
そもそも、そのCVは本当にその広告から発生したのか。
です。
Google広告の管理画面では100件。
GA4では82件。
アドエビスでは91件。
広告主の受注DBでは76件。
ASPでは88件。
なぜか全部違う。
広告を運用している人間にとっては、別に珍しい話ではありません。
この辺から、
GTM
GA4
アドエビス
CATS
gclid
YCLID
UTM
1st Party Cookie
ITP
ポストバック
コンバージョンAPI
Enhanced Conversions
オフラインCVインポート
といった言葉が急に大量に出てきます。
マーケティングというより、
広告配信システムとWebサイトと顧客DBをどう接続するか
というシステム実務です。
そもそも広告媒体は「その客が誰だったのか」をどう覚えているのか
Googleで広告をクリックしたとします。
そのとき、Google広告の自動タグ設定が有効なら、遷移先URLに、
gclid
という値が付きます。
Google自身、GCLIDをGoogle Click Identifierと説明しており、自動タグ設定によって広告クリック後のURLへ追加されます。
例えばイメージとしては、
example.com/?gclid=ABC123XYZ
みたいになります。
この、
ABC123XYZ
が「どの広告クリックだったか」を後でつなぐ鍵になる。
LINEヤフーの検索広告でも似た仕組みがあります。
こちらは、
YCLID
です。
LINEヤフーの公式ヘルプでも、広告クリック時に最初の遷移URLへYCLIDを付与し、オフラインコンバージョンのインポートなどで利用する仕組みが案内されています。
つまり広告実務では、
広告をクリック
↓
LPへ遷移
↓
その人に付いてきたクリックIDを保存
↓
フォーム送信
↓
CRMや顧客DBへクリックIDも一緒に保存
↓
後日契約
↓
「この契約は、あのクリックだった」と広告媒体へ返す
ということをやります。
ここをちゃんと作らないと、
広告はクリックまでは分かる。
問い合わせまでも分かる。
しかし、
その問い合わせが本当に売上になったのか
が分からなくなる。
BtoB広告では「問い合わせ」をCVにすると事故る
例えば、
Google広告を100万円使った。
問い合わせ100件。
CPA 1万円。
一見、優秀です。
でも営業結果を見ると、
A広告：
問い合わせ50件
契約1件
売上100万円
B広告：
問い合わせ20件
契約5件
売上2000万円
だったとします。
広告管理画面で問い合わせCVだけ見れば、
Aの方が安く取れているかもしれない。
しかし会社にとって価値があるのはBです。
だから本来、
広告クリック → 問い合わせ → 商談 → 契約 → 売上
までつなぎたい。
そこで、
Salesforce。
HubSpot。
kintone。
自社CRM。
SFA。
などの営業データと広告データを接続する。
この瞬間、マーケティング担当者の仕事はかなりシステム寄りになります。
gclidをSalesforceまで運ぶ
例えばGoogle広告なら、
広告クリック時のgclidをWeb側で保持する。
フォーム送信時にhidden fieldへ入れる。
Salesforceのリード項目に、
GCLID
というカスタム項目を作る。
問い合わせが入ったとき、
氏名
メール
電話番号
会社名
問い合わせ内容
gclid
をSalesforceへ送る。
営業が追客。
数週間後に受注。
Salesforce側で商談ステージが、
Closed Won
になった。
その情報をGoogle広告へ返す。
するとGoogle広告側も、
単なる「問い合わせ」ではなく、
本当に契約したクリック
を学習できる。
この辺がオフラインコンバージョンの世界です。
LINEヤフー広告でも、YCLIDを使ったコンバージョンデータのインポート機能が提供されています。
広告運用が高度になると、
「どの広告のCPAが安いか」
ではなく、
どの広告が、最終的に良い顧客を連れてきたか
へ学習対象を変えていきます。
しかしgclidが消える
ここから面倒になります。
クリック時、
gclid=xxxxx
が付いていた。
ところが、
LP
↓
商品ページ
↓
別ドメインのフォーム
↓
外部決済システム
と遷移した。
その途中でgclidが消えた。
あるいは、
LP側では取得したのに、
フォームシステムへ渡していない。
Salesforceにも保存していない。
すると後から受注しても、
広告クリックまで戻れません。
だから広告代理店とWeb制作会社との会話で、
「gclid持てていますか」
「hiddenに入っていますか」
「クロスドメインで落ちていませんか」
「リダイレクトでクエリ消していませんか」
という話になります。
マーケティングの本には、あまり出てきません。
しかし実務では結構重要です。
GTMは「タグを入れる箱」ではない
そこで頻繁に出てくるのが、
Google Tag Manager、GTM
です。
マーケターには、
「タグを簡単に入れられるツール」
くらいに理解されていることがあります。
実務ではもっと細かい。
例えば、
問い合わせ完了ページに来たら、
Google広告CVタグ。
Meta Pixel。
Yahoo!広告コンバージョンタグ。
LINE関連タグ。
アドエビス成果タグ。
をそれぞれ発火させる。
商品価格をData Layerから取得する。
transaction_idを取る。
メールアドレスをEnhanced Conversions用に処理する。
ページURLによって発火条件を変える。
フォーム送信イベントだけ拾う。
同じユーザーがリロードしても二重計測させない。
ということをやります。
つまりGTMは、
Webサイト上のユーザー行動を各マーケティングシステムへ配る中継装置
として使われます。
ここで「CVが二重計測されている」という事故が起こる
例えばサンクスページ、
/thanks/
にCVタグを置いた。
ユーザーがフォーム送信。
1CV。
そのあとユーザーがブックマークからもう一度/thanks/を開く。
また1CV。
実際の問い合わせは1件なのに、
広告管理画面では2件。
あるいは、
Google広告タグをHTMLへ直書き。
さらにGTMからも同じタグを発火。
1回の注文で2CV。
こういう事故があります。
ECなら、
transaction_id
などを使って重複排除する設計が重要になります。
だから広告計測をちゃんとやる会社では、
「タグが発火した」
だけではテスト終了にならない。
一回注文する。
管理画面を見る。
DBを見る。
リロードする。
別ブラウザでやる。
スマホでやる。
広告クリック経由でやる。
自然検索経由でやる。
など、かなり地味な確認をします。
アドエビスにも、テスト用URLからクリック・CVまで確認するための公式手順があります。
日本ではアドエビスを間に挟む会社がある
ここで出てくるのが、
AD EBiS、アドエビス
です。
Google広告。
Yahoo!広告。
Meta広告。
アフィリエイト。
メール。
自然検索。
などを媒体横断で評価したい。
媒体管理画面だけを見ると、それぞれが、
「このCVは自分の広告のおかげです」
と計上することがあります。
Google広告で1CV。
Metaで1CV。
Yahoo!で1CV。
でも実際の購入は1件。
すると、
各媒体CVの合計と、
実際の注文数が合わない。
そこで第三者の広告効果測定システムを使う。
アドエビスは現在も、広告クリック計測用の独自パラメータ、コンバージョン計測、Cookie規制に対応した1st Party Cookieベースの計測などを提供しています。
広告入稿URLも、
Google広告へ直接LP URLを入れるのではなく、
アドエビスで発行した計測用URL
を使うケースがあります。
アドエビス側で、
どの広告からクリックされたかを保持。
ユーザーが後でCV。
アドエビス側で成果を判定する。
という仕組みです。
「媒体CV」と「第三者計測CV」は一致しなくて当たり前
例えば、
月曜日にMeta広告を見る。
クリックしない。
火曜日にGoogle検索広告をクリック。
水曜日に直接サイトへ戻る。
購入。
Meta側ではView Through Conversionとして自分の成果にすることがある。
Google側では広告クリック後のCVとして成果にすることがある。
アドエビスでは設定されたアトリビューションルールによって別の判定をする。
GA4も独自のアトリビューションをする。
だから、
どれが正しいか
という問い自体が少し危ない。
正確には、
何の目的で、どのルールで評価している数字か
を見る必要があります。
媒体数字は入札最適化には重要。
経営側の予算配分では第三者計測を使いたい場合がある。
実売上は基幹DBを見る。
用途が違います。
アフィリエイト系になるとCATSが出てくる
さらにアフィリエイトや成果報酬型広告をやると、
CATS
という名前を聞くことがあります。
CATSは広告効果測定ツールで、複数媒体やASP、SNSなどと成果データを連携する機能を提供しています。
ここで特徴的なのが、
ポストバック
です。
CATSの公式説明では、クリック時にCATS発行のセッションIDを広告主側へ渡し、成果発生時にそのIDを使ってCATSへ成果情報を返す仕組みが案内されています。
例えば、
ASP
↓
CATS
↓
広告主LP
↓
購入
という流れ。
クリック時に、
sid=XXXXXXXX
のような識別子を持たせる。
広告主側はそれを保存。
購入したら、
広告主システムからCATSへ、
「sid=XXXXXXXXが購入しました」
とサーバー間通信で返す。
これがポストバック。
ブラウザ上でタグを発火させるだけではありません。
サーバーからサーバーへ成果を返す。
だから、
ソケット連携、
S2S、
Server to Server、
Postback
などの言葉が出てきます。
ポストバックは一箇所切れるだけで全部消える
この仕組みが厄介なのは、
媒体
↓
計測システム
↓
広告主
↓
計測システム
↓
媒体
というバケツリレーになっているところです。
どこか一つでも、
パラメータ名を間違える。
セッションIDを保存し忘れる。
文字数が足りず途中で切れる。
URLエンコードがおかしい。
成果時ポストバックURLが間違っている。
と、
広告はクリックされている。
商品も売れている。
しかし媒体上では、
CVゼロ
になります。
CATSの公式サポートでも、クリックURLのパラメータ設定、ポストバックURL、セッションIDなどを成果連携エラーの主な確認項目として挙げています。
この場合、
運用担当：
「広告が悪い」
広告主：
「売れてますけど」
計測担当：
「ポストバック落ちてます」
という会話になります。
広告運用は数字を見る仕事ですが、
その数字が本当に生成されているのか
を疑わないといけない。
ITP以降、「Cookieに入れておけばいい」が通用しにくくなった
昔の広告計測は比較的シンプルでした。
広告クリック。
Cookieに記録。
数日後購入。
Cookieを見て成果判定。
しかしSafariのITPなど、ブラウザ側のトラッキング制限が強くなりました。
すると、
ブラウザCookieだけに頼った計測は不安定になります。
そこで、
1st Party Cookie
Server-side measurement
Conversions API
などが重要になってきます。
アドエビスも現在、ITP等のCookie規制に対応するため、サーバー側で発行する1st Party Cookieによる計測を案内しています。
Meta広告ではConversions APIが出てくる
Meta広告でも、
ブラウザ上のPixelだけではなく、
サーバー側からイベントを送る、
Conversions API、CAPI
が使われます。
例えばECなら、
ブラウザ側Pixel：
Purchase発火
サーバー側CAPI：
Purchase送信
という二系統を使う。
ただし両方送れば、
購入1件が2件になる可能性があります。
そこで、
event_id
などを使ってdeduplicationする。
マーケティング担当者の会話が、
「このクリエイティブ刺さるね」
ではなく、
「browserとserverのevent_id合わせていますか」
になってくる。
ここまで来ると完全に別の世界です。
GoogleではEnhanced Conversions
Googleにも、
Enhanced Conversions
があります。
Googleは、メールアドレスや電話番号などの1st-party customer dataをSHA-256でハッシュ化して送り、既存のコンバージョン測定を補完する仕組みとして提供しています。
例えば購入時、
というメールアドレスがある。
そのままGoogleへ送るのではなく、
正規化。
ハッシュ化。
Google側でGoogleアカウント情報との照合に使う。
これによって広告とのマッチング精度を補完する。
2026年4月以降、Google AdsではWeb向けとリード向けのEnhanced Conversions設定が統合され、website tags、Data Manager、API connectionsなどからuser-provided dataを受ける形に整理されています。
この辺は数年前と仕様が変わっているので、広告運用者でも昔の知識のままだと危ないところです。
Yahoo!広告にもコンバージョンAPIがある
サーバーサイド計測はMetaやGoogleだけではありません。
LINEヤフー広告でも、検索広告・ディスプレイ広告向けにコンバージョンAPIが提供されています。
さらに、
コンバージョン詳細マッチング
もあります。
つまり2026年現在、
Google。
Yahoo!。
Meta。
各媒体が、
ブラウザCookieだけではない、
1st Party Data + Server-side Conversion
の方向へ寄っている。
広告運用をやるなら、クリエイティブや入札だけでなく、
データ基盤まで理解する必要が出てきています。
実務では「広告代理店」「制作会社」「システム会社」の境界で事故る
例えば代理店が、
「Enhanced Conversionsを入れたいです」
と言う。
制作会社：
「GTMは触れます」
システム会社：
「顧客メールはサーバー側にあります」
広告主：
「個人情報なので勝手に使わないでください」
法務：
「同意取得は？」
となる。
広告計測という一見マーケティングの仕事が、
制作。
システム。
CRM。
法務。
個人情報。
セキュリティ。
まで横断する。
ここで担当領域が曖昧だと、
誰も実装しない。
あるいは逆に、
全員がタグを入れて二重計測する。
かなり現場っぽい事故です。
「CVが増えました」は信用してはいけない
広告代理店から、
「今月CVが30%増えました」
という報告が来たとします。
ここで見るべきは、
本当に顧客が30%増えたのか。
それとも、
アトリビューション設定を変えたのか。
CV windowを変えたのか。
View Throughが増えたのか。
Enhanced Conversions導入で拾えるCVが増えたのか。
タグの二重発火なのか。
Micro Conversionを含めたのか。
GA4からAdsタグへ測定方法を変えたのか。
です。
計測方法が変われば、事業が何も変わっていなくてもCV数は変わります。
だからマーケティングで本当に危ないのは、
数字を見ないことだけではありません。
数字がどう作られたかを知らずに見ること
です。
日本の広告運用実務は、実は巨大な配管工事である
表から見ると、
Google広告。
Yahoo!広告。
Meta広告。
LINE広告。
広告代理店。
LP。
という華やかな世界です。
しかし裏側には、
GTM
GA4
gclid
YCLID
UTM
アドエビス
CATS
1st Party Cookie
ITP
ポストバック
S2S
Meta Conversions API
Yahoo!広告コンバージョンAPI
Google Enhanced Conversions
Salesforce
HubSpot
kintone
transaction_id
event_id
といった配管があります。
広告費が月10万円なら、そこまで考えなくてもいい。
しかし月1000万円、1億円と使い始めると、
計測が5%狂うだけで、
予算配分を数百万円、数千万円間違える可能性があります。
その段階になると、
マーケティングは、
「良い広告を作る」
だけの仕事ではなくなります。
広告媒体、Web、計測ツール、CRM、受注DB、決済システムを接続して、顧客がどこから来て、最終的にいくら金を払ったのかを一本につなぐ仕事
になります。
そして実務をやった人ほど、
最終的には広告管理画面のCPAより、
その数字がどう生成されたのか
を気にするようになります。
マーケティングの教科書にはあまり書かれていませんが、現場ではこの配管の出来が広告運用の精度をかなり左右しています。
＝＝＝
 |
 |
 |
"make you feel, make you think."
SGT&BD
(Saionji General Trading & Business Development)
説明しよう！西園寺貴文とは、常識と大衆に反逆する「社会不適合者」である！平日の昼間っからスタバでゴロゴロするかと思えば、そのまま軽いノリでソー◯をお風呂代わりに利用。挙句の果てには気分で空港に向かい、当日券でそのままどこかへ飛んでしまうという自由を履き違えたピーターパンである！「働かざること山の如し」。彼がただのニートと違う点はたった１つだけ！そう。それは「圧倒的な書く力」である。ペンは剣よりも強し。ペンを握った男の「逆転」ヒップホッパー的反逆人生。そして「ここ」は、そんな西園寺貴文の生き方を後続の者たちへと伝承する、極めてアンダーグラウンドな世界である。 U-18、厳禁。低脳、厳禁。情弱、厳禁。